Are all BSDs created equally? A survey of BSD kernel vulnerabilities [video](media.ccc.de)
media.ccc.de
Are all BSDs created equally? A survey of BSD kernel vulnerabilities [video]
https://media.ccc.de/v/34c3-8968-are_all_bsds_created_equally
78 comments
Every time that you've posted this, people have repetitively re-hashed the same old big corporations ... no they don't ... yes in fact they do arguments.
Have you considered improving your boilerplate spiel?
* https://news.ycombinator.com/item?id=16011478
* https://news.ycombinator.com/item?id=14854387
* https://news.ycombinator.com/item?id=14701854
Have you considered improving your boilerplate spiel?
* https://news.ycombinator.com/item?id=16011478
* https://news.ycombinator.com/item?id=14854387
* https://news.ycombinator.com/item?id=14701854
And is it really cool to copy paste the same comment on every article about BSD? Seems like a form of spam to me..
Surely there are better reasons to donate to these projects other than funding development for massive corporations like Netflix, Sony, and Facebook. The idea that my donation money will be primarily used to cut costs for these corporations isn't exactly appealing to me.
You might one day want to run a startup or a project and then you could just do it on FreeBSD in any way you like, given the permissive license and this is exactly the reason why you need BSD, not only because Netflix, Sony or WhatsApp uses them to serve you their service.
Does it really bother you that much if your $10 of donation will benefit yourself, myself, other ordinary people and some companies at the same time, enough to stop you from donating?
I personally can't understand that, because when I donate my money or my code, it's yours then and you're free to do with it as you please, and wether you make $1000000 off it or not, it's not my concern anymore.
Does it really bother you that much if your $10 of donation will benefit yourself, myself, other ordinary people and some companies at the same time, enough to stop you from donating?
I personally can't understand that, because when I donate my money or my code, it's yours then and you're free to do with it as you please, and wether you make $1000000 off it or not, it's not my concern anymore.
No it doesn't bother me if others (including big corporations) benefit as well, if I'm doing the donation anyway. I'll probably view it as a bonus! It's just that the benefit to big corporations alone isn't a motivator for me to donate in the first place.
The idea that at some point in the future I might want to use FreeBSD is definitely a better motivator. However this same argument applies to a million other projects that are in need of donations. My donation fund is limited, and so arguments that apply to pretty much every project don't make these BSD projects stand out.
In practice there are projects which I'm already actively using, and they get the majority of my donations. However I do occasionally donate to projects with future potential that I haven't benefited from yet.
I'm not against donating, even to projects which I don't directly use. I'm just saying that the fund raising pitch here is very weak. Not to belittle the BSD projects, but to point out that the situation can be greatly improved. Although yes I also understand that most open source project people want to work on their personal pet features and not deal with things like marketing, sales, image building.
The idea that at some point in the future I might want to use FreeBSD is definitely a better motivator. However this same argument applies to a million other projects that are in need of donations. My donation fund is limited, and so arguments that apply to pretty much every project don't make these BSD projects stand out.
In practice there are projects which I'm already actively using, and they get the majority of my donations. However I do occasionally donate to projects with future potential that I haven't benefited from yet.
I'm not against donating, even to projects which I don't directly use. I'm just saying that the fund raising pitch here is very weak. Not to belittle the BSD projects, but to point out that the situation can be greatly improved. Although yes I also understand that most open source project people want to work on their personal pet features and not deal with things like marketing, sales, image building.
The reason why Netflix/Sony/WhatsApp are mentioned is not because they're best reasons to donate to FreeBSD but instead because there's much higher chance for the reader to know them rather than DTrace, ZFS, Jails, performant TCP/IP stack and many other things where FreeBSD benefits the users.
It's much simpler to get a connection this way and some interest from the end user, who otherwise wouldn't have heard about FreeBSD and wouldn't ever thought on donating the money to a project that he wouldn't have know is running so many things he enjoys and or relies on.
We're aware everyone has limited funds and lots of people have better use for their resources than to donate, but this is exactly why we are asking kindly, we are not demanding nor trying to impose our point of view in such donation request and most importantly, we're not judging regardless of the donation decision :)
We are grateful even for discussion such as this one, that may spread out the knowledge and familiarity of the FreeBSD project and in result perhaps drive even more donations or - better yet - new project members!
It's much simpler to get a connection this way and some interest from the end user, who otherwise wouldn't have heard about FreeBSD and wouldn't ever thought on donating the money to a project that he wouldn't have know is running so many things he enjoys and or relies on.
We're aware everyone has limited funds and lots of people have better use for their resources than to donate, but this is exactly why we are asking kindly, we are not demanding nor trying to impose our point of view in such donation request and most importantly, we're not judging regardless of the donation decision :)
We are grateful even for discussion such as this one, that may spread out the knowledge and familiarity of the FreeBSD project and in result perhaps drive even more donations or - better yet - new project members!
>DTrace, ZFS, Jails, performant TCP/IP stack and many other things where FreeBSD benefits the users.
Just to point out, that DTrace and ZFS are (were) not BSD features, and were not invented by a Open Source BSD.
It just happened that they were open sourced by a GPL incompatible license (CDDL) which makes it impossible to directly merge it into the mainline Linux kernel.
EDIT
Just also to point out that had ZFS been a BSD licensed tech, it's very likely that ZoL would have been just as good an option as ZFS on FreeBSD.
Just to point out, that DTrace and ZFS are (were) not BSD features, and were not invented by a Open Source BSD.
It just happened that they were open sourced by a GPL incompatible license (CDDL) which makes it impossible to directly merge it into the mainline Linux kernel.
EDIT
Just also to point out that had ZFS been a BSD licensed tech, it's very likely that ZoL would have been just as good an option as ZFS on FreeBSD.
We got into a bit of a discussion last time you posted this, but I really don't understand your angle here.
Reminding me that these huge corporations are donating so little that you still need to ask for donations on HN makes me want to donate less, not more.
I already give Netflix money, and I think Facebook (and thus by extension WhatsApp) are total scum.
Again, why should I give you money so that they can leech off my donation?
Why aren't these companies that allegedly rely so heavily on FreeBSD making you financially stable?
Reminding me that these huge corporations are donating so little that you still need to ask for donations on HN makes me want to donate less, not more.
I already give Netflix money, and I think Facebook (and thus by extension WhatsApp) are total scum.
Again, why should I give you money so that they can leech off my donation?
Why aren't these companies that allegedly rely so heavily on FreeBSD making you financially stable?
Because they are scum and don’t contribute.
Meh, I think they do in fact contribute. It's just that they don't contribute to an acceptable degree. If FreeBSD is as indispensable to these corps as OP implies, they should be contributing to a level enough to make FreeBSD financially secure.
What's scummy about Facebook is the way Zuckerberg pushes the message that privacy is dead while using the money he made selling my privacy to buy all the mansions around his so that he can protect his own privacy.
But that's for another thread: I'm interested in why FreeBSD isn't receiving the financial support it seems to require from the corps that are leeching off volunteers to pad their profit margins.
What's scummy about Facebook is the way Zuckerberg pushes the message that privacy is dead while using the money he made selling my privacy to buy all the mansions around his so that he can protect his own privacy.
But that's for another thread: I'm interested in why FreeBSD isn't receiving the financial support it seems to require from the corps that are leeching off volunteers to pad their profit margins.
Well. To be sure, it would be awful messaging for the organizations to run that message. If they alienate FB or Netflix then they could lose much more than they realize (as apparently some donations are done anonymously).
I want kernel modules back in openbsd. Of course they gonna ignore it for reason, but you know... easy come, easy go.
Netflix uses Linux too and Sony heavily dumbed the kernel, to decrease the attack surface. It's practically pointless to call it as an os.
ZFS is also available for Linux and of course it's better to use it on Illumos. I wonder why Netflix chose FreeBSD and not Solaris or Illumos.
> You may or may not be aware, but FreeBSD runs your movies on Netflix, your games on PlayStation, your files on FreeNAS and ZFS, your friends on WhatsApp and OpenBSD runs everywhere else as OpenSSH. ;)
so... let us get that straight.
* Netflix had a revenue of 8.83 billion dollars USD last year.
* Sony had a revenue of 68 fucking billion dollars.
* WhatsApp is owned by facebook which will have around 40 billion dollar revenue this year it seems
and all these guys put together aren't arsed to contribute enough for paying for a few full-time devs, in addition to keeping a part of their modifications to the BSD source closed, but us, the users, should additionnally roll out some bucks to help these companies make even more money ? What's wrong with you people ?
What next ? Should we also donate to tanenbaum to help Intel (59 billion $ revenue) conceal its next iteration of the management engine better ?
so... let us get that straight.
* Netflix had a revenue of 8.83 billion dollars USD last year.
* Sony had a revenue of 68 fucking billion dollars.
* WhatsApp is owned by facebook which will have around 40 billion dollar revenue this year it seems
and all these guys put together aren't arsed to contribute enough for paying for a few full-time devs, in addition to keeping a part of their modifications to the BSD source closed, but us, the users, should additionnally roll out some bucks to help these companies make even more money ? What's wrong with you people ?
What next ? Should we also donate to tanenbaum to help Intel (59 billion $ revenue) conceal its next iteration of the management engine better ?
I don't think there's anything wrong with us. First of all, no one says you should do anything. We're asking kindly because we can, and you can do all range of things from ignoring us completely to donating $1M like WhatsApp founder. Because you can too.
Second thing is that's its much easier to ask open source aware HN reader for $50 than a huge megacorp hive mind for 50c. Not to mention every 'end user dollar' is worth much more for the foundation given the regulations, where to keep the tax status we need to show up numbers supporting in people, rather than businesses.
And finally, many of these companies do give us money and code, some in the open, some anonymously due to the reasons known only to them.
Just a food for thought for you when you'll be thinking about these donations :)
Second thing is that's its much easier to ask open source aware HN reader for $50 than a huge megacorp hive mind for 50c. Not to mention every 'end user dollar' is worth much more for the foundation given the regulations, where to keep the tax status we need to show up numbers supporting in people, rather than businesses.
And finally, many of these companies do give us money and code, some in the open, some anonymously due to the reasons known only to them.
Just a food for thought for you when you'll be thinking about these donations :)
I think it's not so much about donating in and of itself, as it is about this "it runs Netflix!" argument.
I do donate to FreeBSD regularly - in fact, I have a matching paycheck donation set up. But that's because I personally use it in my projects. When it comes to Netflix, I already pay for Netflix, so the notion that I should also pay to FreeBSD because it makes Netflix possible is kinda ridiculous.
I do donate to FreeBSD regularly - in fact, I have a matching paycheck donation set up. But that's because I personally use it in my projects. When it comes to Netflix, I already pay for Netflix, so the notion that I should also pay to FreeBSD because it makes Netflix possible is kinda ridiculous.
There’s also the argument regarding existence. Without the BSDs there would be much fewer ways for people and companies to use great, legitimately industry standard software/hardware technologies. Where would people cut their teeth programming and administrating the same tech that will land them work? Sure, Microsoft’s OSes exist, they’re not economically available for everybody. To say nothing about the realities of which OS offers a better developer/admin experience.
Netflix contributes code back to FreeBSD including kernel contributions via Netflix own in-house FreeBSD committers that have greatly improved streaming and other improvements. Netflix also contributes monetarily.
https://openconnect.netflix.com/en/software/ "All code improvements, feature additions, and bug fixes are contributed directly back to the open source community via the FreeBSD committers on our team. We also strive to stay at the front of the FreeBSD development process, allowing us to have a tight feedback loop with other community and partner developers."
WhatsApp has also contributed monetarily and with software. You need to know that Facebook only recently bought WhatsApp.
https://openconnect.netflix.com/en/software/ "All code improvements, feature additions, and bug fixes are contributed directly back to the open source community via the FreeBSD committers on our team. We also strive to stay at the front of the FreeBSD development process, allowing us to have a tight feedback loop with other community and partner developers."
WhatsApp has also contributed monetarily and with software. You need to know that Facebook only recently bought WhatsApp.
> WhatsApp has also contributed monetarily and with software. You need to know that Facebook only recently bought WhatsApp.
Coming up on almost 4 years now since the WhatsApp acquisition was announced (Feb 2014) and over 3 years since the acquisition closed (Oct 2014). [1] [2]
I wouldn't call either date "recently"
[1] http://money.cnn.com/2014/02/19/technology/social/facebook-w...
[2] https://www.bloomberg.com/news/articles/2014-10-28/facebook-...
Coming up on almost 4 years now since the WhatsApp acquisition was announced (Feb 2014) and over 3 years since the acquisition closed (Oct 2014). [1] [2]
I wouldn't call either date "recently"
[1] http://money.cnn.com/2014/02/19/technology/social/facebook-w...
[2] https://www.bloomberg.com/news/articles/2014-10-28/facebook-...
FWIW, Netflix and Facebook each donated gold-tier (25-50k USD) this year[1]. I would be very surprised if none of those companies employ engineers submitting patches upstream -- obviously for some things it doesn't make sense (proprietary drivers for PS4 hardware, etc). A cursory search turned up this[2], for example.
[1] https://www.freebsdfoundation.org/donors/
[2] https://people.freebsd.org/~rrs/asiabsd_tls_improved.pdf
[1] https://www.freebsdfoundation.org/donors/
[2] https://people.freebsd.org/~rrs/asiabsd_tls_improved.pdf
Plus, US tax law has some requirements around nonprofits and number of contributors. The single or few large donors is great, but the org needs to show wide support. So a twenty $5 donations is better than a single $100 donation.
I have no ties to the FreeBSD project or its foundation, but it seems very cheap for companies that profit billions of dollars yearly to only donate $25k to projects and foundations that support part of the software backbone of their infrastructure... Regardless of regulatory barriers, if this got a bit more exposure it could actually be a PR liability, IMO...
>but it seems very cheap for companies that profit billions of dollars yearly to only donate $25k to projects and foundations that support part of the software backbone of their infrastructure..
That's the free rider problem, one that the GPL (and the AGPL) was designed to avoid.
It's true that many of those companies which use FreeBSD wouldn't touch a GPL codebase (and all the more so an AGPL codebase), but that't the point - while some chose FreeBSD because it's fast/stable (NF and WhatsApp), others chose it because they don't have to contribute back.
That's the free rider problem, one that the GPL (and the AGPL) was designed to avoid.
It's true that many of those companies which use FreeBSD wouldn't touch a GPL codebase (and all the more so an AGPL codebase), but that't the point - while some chose FreeBSD because it's fast/stable (NF and WhatsApp), others chose it because they don't have to contribute back.
At some point we have to acknowledge that our modern technological society relies on having a common, free foundation of tools available to everyone. Sometimes really big companies will get more value out than they put in, but so does everyone else and that's kind of the point of a foundational tool.
All of this free, open, etc. software works in part because of a "pay it forward" approach to the community. If people shame big users for not "paying back" enough, rather than finding more productive means of encouragement, the whole system of free tools becomes less tenable because future users will pick other tools that don't have PR risk attached.
All of this free, open, etc. software works in part because of a "pay it forward" approach to the community. If people shame big users for not "paying back" enough, rather than finding more productive means of encouragement, the whole system of free tools becomes less tenable because future users will pick other tools that don't have PR risk attached.
This is BSD at work my friend. And this is why every serious opensource fan should prefer GPL and similar licenses. The thing who shocked me the most, was to learn that Sony uses FreeBSD on the PS4 and yet no Radeon driver has been given back to the community. Obviously they have a bad ass device driver in the PS4 with some serious 3D performance ( after all it is a gaming console ). Yet the only thing you have in mainline FreeBSD is a hacked driver ported from Linux! BSD at work!
Orbis doesn't work the way you think it does. The kernel is based on FreeBSD, but the entire gfx stack (and everything else above the kernel) is custom. It's not even OpenGL compatible, instead running their custom GNM library (Metal/Vulkan/Mantle equivalent) and GNMX (OpenGL/DirectX equivalent).
Nothing they've built in their stack would translate to an Xorg driver, beyond the kernel shim (the smallest and simplest portion of the code, in most video drivers).
Nothing they've built in their stack would translate to an Xorg driver, beyond the kernel shim (the smallest and simplest portion of the code, in most video drivers).
"hacked" driver, yeah, no.
There is nothing wrong with porting from Linux.
We have a compatibility layer for Linux drivers in the kernel (LinuxKPI), so the GPU drivers are not modified that much. A lot of work on LinuxKPI has been sponsored by Mellanox, by the way :) since it's also used for their network drivers (mlx4/5).
And it works fine, I'm currently writing this from a PC with an RX 480 running FreeBSD 12-CURRENT. DRI3, Wayland, Vulkan — everything works.
Also, the Sony driver would've been completely irrelevant to desktop systems. It supports one specific GPU model, Sony proprietary APIs, probably nothing in terms of KMS/DRM/GBM/EGL!
There is nothing wrong with porting from Linux.
We have a compatibility layer for Linux drivers in the kernel (LinuxKPI), so the GPU drivers are not modified that much. A lot of work on LinuxKPI has been sponsored by Mellanox, by the way :) since it's also used for their network drivers (mlx4/5).
And it works fine, I'm currently writing this from a PC with an RX 480 running FreeBSD 12-CURRENT. DRI3, Wayland, Vulkan — everything works.
Also, the Sony driver would've been completely irrelevant to desktop systems. It supports one specific GPU model, Sony proprietary APIs, probably nothing in terms of KMS/DRM/GBM/EGL!
These are entirely different arguments.
One is that the users of *BSD's aren't donating to the development, despite enjoying its fruits. GPL will never help here.
The other is about not having to give your changes to the project itself back (bug fixes or features). GPL helps here. However, your examples do not apply to this bucket: Sony's fancy graphics driver can just be a closed-source out-of-tree driver, which would be perfectly compliant with GPL. This is why we have closed-source graphics drivers on Linux.
I personally love open source, and greatly dislike GPL. I prefer the Apache licenses (open but legally explicit), but am completely okay with BSD/MIT.
One is that the users of *BSD's aren't donating to the development, despite enjoying its fruits. GPL will never help here.
The other is about not having to give your changes to the project itself back (bug fixes or features). GPL helps here. However, your examples do not apply to this bucket: Sony's fancy graphics driver can just be a closed-source out-of-tree driver, which would be perfectly compliant with GPL. This is why we have closed-source graphics drivers on Linux.
I personally love open source, and greatly dislike GPL. I prefer the Apache licenses (open but legally explicit), but am completely okay with BSD/MIT.
> Sony's fancy graphics driver can just be a closed-source out-of-tree driver, which would be perfectly compliant with GPL.
This is a loophole with the GPL, not the way it is intended to be used. It is far from clear if this is even legal. The Linux developers are split on the issue, but no one seems to care enough to press charges.
This is a loophole with the GPL, not the way it is intended to be used. It is far from clear if this is even legal. The Linux developers are split on the issue, but no one seems to care enough to press charges.
It isn't a loophole of GPL, it's a feature of the project in question.
If having GPL-licensed code execute non-GPL binary components violates the license, then it would be a license violation to execute any binary that is not GPL-licensed on such an operating system running a GPL-licensed kernel. Such a limitation would be absurd.
From a high-level, project-agnostic perspective, there is no difference between a kernel module and an application binary—they are both external binary blobs with the intention to extend the functionality of the initial project (in this case the Linux kernel). The differences are low-level and kernel-specific (kernel- vs. user-mode, API availability, intended functionality). The GPL does not distinguish between a printer driver or a calculator application.
Another aspect would be the use of a GPL-licensed header file. However, coming to the conclusion that using an untouched header-file (which usually only contains an API surface) from a GPL-licensed project taint code to require GPL-license for compliance would have huge consequences. Many projects would be rendered in violation overnight. This would likely hurt GPL.
If having GPL-licensed code execute non-GPL binary components violates the license, then it would be a license violation to execute any binary that is not GPL-licensed on such an operating system running a GPL-licensed kernel. Such a limitation would be absurd.
From a high-level, project-agnostic perspective, there is no difference between a kernel module and an application binary—they are both external binary blobs with the intention to extend the functionality of the initial project (in this case the Linux kernel). The differences are low-level and kernel-specific (kernel- vs. user-mode, API availability, intended functionality). The GPL does not distinguish between a printer driver or a calculator application.
Another aspect would be the use of a GPL-licensed header file. However, coming to the conclusion that using an untouched header-file (which usually only contains an API surface) from a GPL-licensed project taint code to require GPL-license for compliance would have huge consequences. Many projects would be rendered in violation overnight. This would likely hurt GPL.
> This is why we have closed-source graphics drivers on Linux.
And yet, having Linux being GPL must have given incentive at some point to give code back since nowadays both Intel and AMD have very good GPL'ed drivers.
And yet, having Linux being GPL must have given incentive at some point to give code back since nowadays both Intel and AMD have very good GPL'ed drivers.
I would argue that you're drawing a false connection between being GPL and the benefits of open source code. GPL provides legal protections, but does not directly or indirectly incentivize writing open source code.
Having open source drivers grant Intel and AMD at least the following:
1. Free work on their drivers. Who wouldn't benefit from bug fixes and improvements to the graphics drivers of extremely popular graphics cards? In other words, it reduces cost.
2. Good marketing. There is only a very small group of people who are twisted enough to think that open source is a bad thing. There is a much larger group that see it as a positive thing (and then there's the group that doesn't care at all). In other words, it increases sales.
3. Greater ability to mold the Linux kernel to better accommodate their drivers and needs. Even though a company can send patches to the kernel that would help their closed-source drivers, if they only help closed-source drivers, they are very unlikely to be accepted. On the other hand, any sane change that would help an in-tree driver would be accepted without question. In other words, it increases flexibility.
None of this relates to GPL (the drivers are probably only GPL because GPL forces the in-tree drivers to be GPL), and the same logic applies to *BSD's. The reason we don't have good graphics drivers on BSD is likely because it takes a lot of effort to write one. If it isn't going to affect revenue, Intel and AMD are unlikely to care.
Having open source drivers grant Intel and AMD at least the following:
1. Free work on their drivers. Who wouldn't benefit from bug fixes and improvements to the graphics drivers of extremely popular graphics cards? In other words, it reduces cost.
2. Good marketing. There is only a very small group of people who are twisted enough to think that open source is a bad thing. There is a much larger group that see it as a positive thing (and then there's the group that doesn't care at all). In other words, it increases sales.
3. Greater ability to mold the Linux kernel to better accommodate their drivers and needs. Even though a company can send patches to the kernel that would help their closed-source drivers, if they only help closed-source drivers, they are very unlikely to be accepted. On the other hand, any sane change that would help an in-tree driver would be accepted without question. In other words, it increases flexibility.
None of this relates to GPL (the drivers are probably only GPL because GPL forces the in-tree drivers to be GPL), and the same logic applies to *BSD's. The reason we don't have good graphics drivers on BSD is likely because it takes a lot of effort to write one. If it isn't going to affect revenue, Intel and AMD are unlikely to care.
I find it far more likely that Linux has better drivers made by companies because it has much better marketshare, not because it's GPL.
Both of which will soon be available on FreeBSD. Yay free software!
By the way, amdgpu does not appear to be GPL, just GPL compatible. https://github.com/wkennington/linux-firmware/blob/master/LI...
By the way, amdgpu does not appear to be GPL, just GPL compatible. https://github.com/wkennington/linux-firmware/blob/master/LI...
It's a difference in perspective, I rather prefer situation where no one isn't forced to anything, and that's why I think BSD license is 'better'. I want you, me and everyone else, including companies like Sony, to be free to take the code and benefit from it in every possible way, and if they choose not to share back, it's again their freedom to make this decision. I will use my freedom to make the decision of sharing back, despite all other decisions made in that regard, because this is what I consider a truly free software, unlike the GPL.
GPL is about enabling freedom for end-users. An end-user could be anything from an individual to a corporate entity. Your definition of freedom appears to be just "permissive licensing". Unfortunately, permissive licensing like BSD, could mean that one's code ends up being wielded by a corporation to remove end-user freedoms, typically to lock them in as paying customers.
I am a Free Software Foundation (FSF) member because I believe that end-user freedoms are becoming increasingly under threat as of late and they appear to be among the few that are taking the problem seriously.
I am a Free Software Foundation (FSF) member because I believe that end-user freedoms are becoming increasingly under threat as of late and they appear to be among the few that are taking the problem seriously.
Corporations can't 'wield the code' because by copying it and using it it doesn't take it away from other people and as such this argument against BSD license doesn't really make sense. Corporation can copy the code and improve it so that it would have people willing to pay for their improved code version and I am OK with that, in the end they made the work to generate the profit, that's their goal. I don't have one like such, so I can and I do release my code BSD licenses so that others could do anything (literally) they want with it.
> Corporations can't 'wield the code' because by copying it and using it it doesn't take it away from other people.
The relevance of the original code can be taken away, for example by hijacking a standard or through control of APIs and/or hardware. Will anyone be able to buy hardware in 10 years time that will not be under the full control of a corporation?
The relevance of the original code can be taken away, for example by hijacking a standard or through control of APIs and/or hardware. Will anyone be able to buy hardware in 10 years time that will not be under the full control of a corporation?
The decision to donate to a BSD project shouldn't have anything to do with what other users are donating but with how useful you personally find it to be. Your whole comment is sad.
Please can someone give a brief summary of the conclusions of this talk for those of use that don't have the time and/or bandwidth to watch this? Thanks.
Linux has more CVEs than the BSDs. Ilja wanted to know if that's because they have less bugs/better code or because more people have read the Linux code.
Turns out the BSDs have just as many bugs as Linux. (He found dozens over the course of 3 months.) OpenBSD has less bugs than FreeBSD (presumably because they have removed a lot of old code) and FreeBSD has less bugs than NetBSD.
After reporting the bugs he noticed that OpenBSD handles bugs really well, NetBSD less well and FreeBSD in many cases not at all. (By handling the bugs I mean fixing them in current and providing patches/advisories for the latest release.)
Turns out the BSDs have just as many bugs as Linux. (He found dozens over the course of 3 months.) OpenBSD has less bugs than FreeBSD (presumably because they have removed a lot of old code) and FreeBSD has less bugs than NetBSD.
After reporting the bugs he noticed that OpenBSD handles bugs really well, NetBSD less well and FreeBSD in many cases not at all. (By handling the bugs I mean fixing them in current and providing patches/advisories for the latest release.)
Thanks for taking the time. Happy New Year!
Toward the end he suggests NetBSD "dropped the ball" by not issuing patches and reports.
I am not sure about others but I have never considered what is reported at http://www.netbsd.org/support/security/ as comprehensive.
I like to think the majority of NetBSD users either track -current, compile their own custom kernels or can learn to do as much. The project certainly makes it easy enough.
The flipside of the "many eyes" argument is that the Linux kernel has substantial financial backing and teams of paid developers behind it. NetBSD is relatively small and most contributors are not paid. I think they do an admirable job considering the number of active contributors and maintainers they have. (That is really an understatement but I do not want to appear too biased.) This is not the first time I have seen them immediately fix stuff when it is reported1.
1 http://bulk.fefe.de/scalability/
Unfortunately, even though the presenter mentioned loc several times, he did not try to calculate a bugs:loc ratio. Having a highly educational "history of BSD UNIX" and a large quantity of source code that allows hobbyists to run old hardware in their tree makes NetBSD not only unique and useful but also an easy target for any contemporary security researcher.
I only wish more would take on the challenge. Because sometimes things get fixed fast when this happens.
But comparing one project that has SVR4 compatibilty code to another project that has no such compat code, is that really an apt comparison? The old code is there for a reason. IMO, it does not imply many users will ever need it, that every user is actively using it, or that any user should have it in their kernel if they do not need it.
It is very easy for NetBSD users to compile kernels without code that will not be used, e.g., compatibility code. Easier than in any other OS I have tried. IMO, by making custom kernels so effortless to create (incl. best cross-compilation experience, IMO), it encourages users to compile smaller kernels without the drivers, compat code and other stuff they do not need.
But the presenter here was focused only on the assumption of a "default" kernel config. Not the potential to create small custom kernels with minimal attack surface.
Also: When the presenter was discussing filesystems, I wondered if he knew about rump. I think NetBSD was the first to have a such an innovative, safe way to mount filesystems using kernel drivers in userspace, without risk of crashing the kernel.
I am not sure about others but I have never considered what is reported at http://www.netbsd.org/support/security/ as comprehensive.
I like to think the majority of NetBSD users either track -current, compile their own custom kernels or can learn to do as much. The project certainly makes it easy enough.
The flipside of the "many eyes" argument is that the Linux kernel has substantial financial backing and teams of paid developers behind it. NetBSD is relatively small and most contributors are not paid. I think they do an admirable job considering the number of active contributors and maintainers they have. (That is really an understatement but I do not want to appear too biased.) This is not the first time I have seen them immediately fix stuff when it is reported1.
1 http://bulk.fefe.de/scalability/
Unfortunately, even though the presenter mentioned loc several times, he did not try to calculate a bugs:loc ratio. Having a highly educational "history of BSD UNIX" and a large quantity of source code that allows hobbyists to run old hardware in their tree makes NetBSD not only unique and useful but also an easy target for any contemporary security researcher.
I only wish more would take on the challenge. Because sometimes things get fixed fast when this happens.
But comparing one project that has SVR4 compatibilty code to another project that has no such compat code, is that really an apt comparison? The old code is there for a reason. IMO, it does not imply many users will ever need it, that every user is actively using it, or that any user should have it in their kernel if they do not need it.
It is very easy for NetBSD users to compile kernels without code that will not be used, e.g., compatibility code. Easier than in any other OS I have tried. IMO, by making custom kernels so effortless to create (incl. best cross-compilation experience, IMO), it encourages users to compile smaller kernels without the drivers, compat code and other stuff they do not need.
But the presenter here was focused only on the assumption of a "default" kernel config. Not the potential to create small custom kernels with minimal attack surface.
Also: When the presenter was discussing filesystems, I wondered if he knew about rump. I think NetBSD was the first to have a such an innovative, safe way to mount filesystems using kernel drivers in userspace, without risk of crashing the kernel.
Defaults matter immensely for two reasons:
very few people ever bother to change them unless a specific, user visible problem is occuring
due to the first point, non-defaults receive little or no testing, and are highly likely to be broken, and stay broken because the catch 22 of nobody cares so its broken, and because its broken nobody cares.
Off by default is very much the status of mitigation technologies in FreeBSD atm, its a shame that the author did not touch on this as its one area OpenBSD is miles ahead of FreeBSD in particular (mitigations on by default, breakage exposed and fixed due to it, they remain mostly unusable on FreeBSD due to them).
very few people ever bother to change them unless a specific, user visible problem is occuring
due to the first point, non-defaults receive little or no testing, and are highly likely to be broken, and stay broken because the catch 22 of nobody cares so its broken, and because its broken nobody cares.
Off by default is very much the status of mitigation technologies in FreeBSD atm, its a shame that the author did not touch on this as its one area OpenBSD is miles ahead of FreeBSD in particular (mitigations on by default, breakage exposed and fixed due to it, they remain mostly unusable on FreeBSD due to them).
To the "X86BSD" user who commented here: you are shadow banned so your comments are showing up as dead by default so most users can't see or reply to them. Just thought you should know.
For the record, if you see a shadow banned comment that shouldn't be shadowbanned, you can click on the timestamp and then click "vouch". I don't know if there are karma restrictions to this, though.
Sorry for OT, are there docs for what karma requirements are for what actions?
Unless something changed since 2015, you need karma ≥ 30 to vouch or flag things, and > 500 to downvote:
https://news.ycombinator.com/item?id=10298512
(Not quite "docs", but hopefully better than nothing!)
https://news.ycombinator.com/item?id=10298512
(Not quite "docs", but hopefully better than nothing!)
[deleted]
> Defaults matter immensely
I would bet that this is not the case for NetBSD users. I'm pretty sure most of them change the defaults and have a pretty good of what's running where. I'm not insinuating that all of them are security researchers, but to the very least are above-average UNIX users.
I would bet that this is not the case for NetBSD users. I'm pretty sure most of them change the defaults and have a pretty good of what's running where. I'm not insinuating that all of them are security researchers, but to the very least are above-average UNIX users.
It’s worth also mentioning that as far as I am aware the OpenBSD folks also almost universally eat their own dog food. Most of not all the developers run -current. The bleeding edge. So they can find and fix any issues. I’m not sure how many of the other developers for FreeBSD or NetBSD do that.
I'm a netbsd developer and run netbsd. I think most active netbsd developers do.
a lot of former netbsd developers are still hanging around and contributing to pkgsrc while using it on OS X or linux, I don't think that's a thing to be ashamed of.
a lot of former netbsd developers are still hanging around and contributing to pkgsrc while using it on OS X or linux, I don't think that's a thing to be ashamed of.
The "many eyes" theory needs to go away, it is completely false when egregious bugs exist into their teenage years. That doesn't mean closed source fairs any better, but "many eyes" are largely blind to sophisticated bugs
I have a modification to many eyes that makes it relevant, which is many eyes make bugs shallow when the code is simple enough. I think over-complexity is at the heart of the issue here, and the path forward in the future will be in reducing complexity of codebases and increasing readability.
The comparison I like to use, though not completely fair, is that the linux kernel is now at what... 14mil+ loc, while minix is at more like 14k loc. As we have seen with the intel ME debacle... minix is production ready. This is also why I still think a microkernel is going to be the future.
GNU+HURD and half-life 3 release on the same day I think though.
The comparison I like to use, though not completely fair, is that the linux kernel is now at what... 14mil+ loc, while minix is at more like 14k loc. As we have seen with the intel ME debacle... minix is production ready. This is also why I still think a microkernel is going to be the future.
GNU+HURD and half-life 3 release on the same day I think though.
> I have a modification to many eyes that makes it relevant, which is many eyes make bugs shallow when the code is simple enough.
Many eyes would make many bugs shallow if there only were said eyes.
The problem is that very few people lift a pinky to help audit & secure the software they use. Nobody reads the code. And then when disaster strikes a particular well known & widely used project and people start paying attention, they notice the code is full of low-hanging fruit that anyone could've fixed (nobody did).
Even when people read code and find bugs (as I often do), they're too busy to actually report let alone fix them.
It's so comfortable to pretend that someone else must've audited the code for you because it's open sauce. So you don't have to :-)
Many eyes would make many bugs shallow if there only were said eyes.
The problem is that very few people lift a pinky to help audit & secure the software they use. Nobody reads the code. And then when disaster strikes a particular well known & widely used project and people start paying attention, they notice the code is full of low-hanging fruit that anyone could've fixed (nobody did).
Even when people read code and find bugs (as I often do), they're too busy to actually report let alone fix them.
It's so comfortable to pretend that someone else must've audited the code for you because it's open sauce. So you don't have to :-)
The debian random number bug was a result of many eyes trying to help, but not knowing what they were doing.
http://taint.org/2008/05/13/153959a.html
http://taint.org/2008/05/13/153959a.html
These sayings are unfalsifiable though.
They can be protected after the fact with "You thought there were enough eyes, but there actually weren't." and "You thought the code was simple, but it actually wasn't."
They can be protected after the fact with "You thought there were enough eyes, but there actually weren't." and "You thought the code was simple, but it actually wasn't."
Fully agree. I work on a large open source project and in 8 years I have encountered one person who found a bug by actually reading the code.
Many projects are stable only because the massive numbers of users that find bugs by running the software.
On the other hand there are virtually zero-fault small projects that no one is interested in because they are finished, bug-free and the author/maintainer would like to keep it that way.
Many projects are stable only because the massive numbers of users that find bugs by running the software.
On the other hand there are virtually zero-fault small projects that no one is interested in because they are finished, bug-free and the author/maintainer would like to keep it that way.
"On the other hand there are virtually zero-fault small projects that no one is interested in because they are finished, bug-free and the author/maintainer would like to keep it that way."
Interesting that this statement did not trigger the usual mindless, meme-like HN syllogisms:
"Software is never finished."
"All software has bugs."
They try to discredit the truth that such small projects exist and might have something to offer.
Interesting that this statement did not trigger the usual mindless, meme-like HN syllogisms:
"Software is never finished."
"All software has bugs."
They try to discredit the truth that such small projects exist and might have something to offer.
[deleted]
The criticism seemed to be mostly about not issuing security advisories. Letting users know when there's something they need to upgrade is generally good practice
> I like to think the majority of NetBSD users either track -current, compile their own custom kernels or can learn to do as much.
I generally run the newest snapshot of the current NetBSD release (currently 7.1.1). I've had really good luck with the snapshots.
I generally run the newest snapshot of the current NetBSD release (currently 7.1.1). I've had really good luck with the snapshots.
netbsd hasn't dropped the ball wrt backporting the changes, they are all in there, even for netbsd-6. here's one of the requests for the old stable netbsd-6 branches: http://releng.netbsd.org/cgi-bin/req-6.cgi?show=1482
it does have an issue with making advisories, though.
it does have an issue with making advisories, though.
Anyone have a text mode summary?
It is the same presentation he gave earlier in the year
https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20pre...
https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20pre...
The server times out for me:
$ wget --timeout=60 https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/DEFCON-25-Ilja-van-Sprundel-BSD-Kern-Vulns.pdf
--2017-12-31 17:15:23-- https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/DEFCON-25-Ilja-van-Sprundel-BSD-Kern-Vulns.pdf
Resolving media.defcon.org (media.defcon.org)... 162.222.171.207
Connecting to media.defcon.org (media.defcon.org)|162.222.171.207|:443... connected.
Unable to establish SSL connection.Link to the current slides: https://fahrplan.events.ccc.de/congress/2017/Fahrplan/system...
Thanks!
Pity they havent included HardenedBSD into the list ...
Apparently no amount of coding standards, reviewing or number of contributors make up for the huge deficiencies of using C.
Wondering what the state of open source operating systems would be if they didn’t have to fight the programming language.
Writing in another language doesn't come close to solving the problem - a modern OS sits between lots of differently-privileged processes and thousands of devices, most of which have DMA access to host memory (and which are thus "memory-unsafe" in any language). On the other hand, C does give you good low-level access, an enormous ecosystem, and a large number of potential contributors.
HN is fond of blaming C, but seldom has any awareness of why almost everything does use C. This is not to say that C is perfect, but replacing it needs deep expertise in the fields in which C is still dominant.
HN is fond of blaming C, but seldom has any awareness of why almost everything does use C. This is not to say that C is perfect, but replacing it needs deep expertise in the fields in which C is still dominant.
Which tells me that 1) the deficiencies are minor or 2) the benefits outweigh the deficiencies, or a combination.
Consider that virtually all well-known operating systems, device drivers, embedded systems all over the world use C for some reason, what are you saying would be a better choice?
rust
I looked into rust when it first came out. I dissed it but then found it to be quite interesting. However, compared to C, it is used relatively nowhere by anyone. I don't believe rust has proved to be a non-hesitant replacement for C.
You may or may not be aware, but FreeBSD runs your movies on Netflix, your games on PlayStation, your files on FreeNAS and ZFS, your friends on WhatsApp and OpenBSD runs everywhere else as OpenSSH. ;)
So, you may or may not know that, but you need FreeBSD and OpenBSD and they also need you! Every cent counts and so does every contributor, that helps the foundations keep their non-profit status.
Also, you CAN be the change, if you specify what you'd like your donation to be used for (like more secure defaults for the OS or towards code review and bugs fixing).
[0]https://www.freebsdfoundation.org/donate/
[1]https://www.openbsd.org/donations.html