
Are all BSDs created equally? A survey of BSD kernel vulnerabilities [video] - teamhappy
https://media.ccc.de/v/34c3-8968-are_all_bsds_created_equally
======
tachion
While you're here, have you donated[0][1] yet? :)

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/](https://www.freebsdfoundation.org/donate/)

[1][https://www.openbsd.org/donations.html](https://www.openbsd.org/donations.html)

~~~
jcelerier
> 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 ?

~~~
pabloski
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!

~~~
arghwhat
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.

~~~
jcelerier
> 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.

~~~
arghwhat
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.

------
subsubsub
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.

~~~
teamhappy
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.)

~~~
ianai
Why doesn’t FreeBSD address them?

~~~
teamhappy
No idea. He didn't mention anything during the talk (I haven't seen the QA at
the end).

He said he reported them a few months back and checked if they were fixed a
few days before congress. 3 were fixed, the other ~20 weren't.

------
feelin_googley
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/](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/](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.

~~~
throwaway2048
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).

~~~
foodstances
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.

~~~
fao_
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.

~~~
andrewjw
Sorry for OT, are there docs for what karma requirements are for what actions?

~~~
jwilk
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](https://news.ycombinator.com/item?id=10298512)

(Not quite "docs", but hopefully better than nothing!)

------
na85
Anyone have a text mode summary?

~~~
throwaway2048
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%20presentations/DEFCON-25-Ilja-
van-Sprundel-BSD-Kern-Vulns.pdf)

~~~
jwilk
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.

------
vermaden
Pity they havent included HardenedBSD into the list ...

------
Polyisoprene
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.

~~~
sureaboutthis
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?

~~~
mrd999
rust

~~~
sureaboutthis
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.

