3 ms·

This coming from a BSD distribution that ships binary blob device drivers.

by ris 13y ago

tachion 13y ago
Yes, and?
- opendomain 13y ago
  I think he is saying, that FreeBSD ships binary device drivers - how can we trust that those do not compromise the system? If FreeBSD is open source - why are not the device drivers? If we can not trust FreeBSD for these device drivers, then why should we trust their opinion on using intel for a crypto source?
- matthewmacleod 13y ago
  The point was obviously that it's surprising to see that they are happy to ship binary drivers (which could contain arbitrary compromises from a user's point of view) but are not willing to trust the HWRNG (to which the same caveat applies). Of course, I don't agree with this comparison; running the output of the HWRNG through Yarrow is good practice in any case.
  - AnthonyMouse 13y ago
    What's the problem with the comparison? The only real advantage of the binary blob over the hardware is that you can theoretically verify what it's doing more easily. But actually doing that verification has a difficulty on the same order as reverse engineering the driver to release an open source version, so all the existence of the binary driver does is to imply that such verification hasn't occurred -- because if it had then those doing the verification would have been in a good position to release source code (or at least complete hardware documentation) for an open source driver. Binary blob software also has the distinct disadvantage that even if you were to verify it, you would have to verify each release again whenever there is an update.
    - tachion 13y ago
      In my perspective, binary drives are a matter of choice, you can use them, but you dont have to, if you dont want to, whereas the random numbers generation is used everywhere in the OS, and you cant just decide to not to use it - that's a huge difference, what makes this comparison bad.
      - AnthonyMouse 13y ago
        Can't you though? We're really talking about defaults here. If you don't want to use the hardware RNG, you can always disable it in either the BIOS or the OS. Or use hardware that doesn't have one. The trouble is for the common user who doesn't know anything about any of this and is just going to take the defaults for everything, who is exactly the sort of person who is going to take the binary driver to "just make it work" and then be exposed to any vulnerabilities it may contain. You have to make the defaults secure because they're what most people will use. It doesn't matter that you can change it if most people never do.
    - matthewmacleod 13y ago
      Sorry, I was unclear. It's an apt comparison in that sense (it's unverified). However, there's a zero-impact workaround for this (using the CSPRNG on top of the HWRNG) so it has no user impact, whereas eliminating binary blobs does.
    - pbsd 13y ago
      The comparison is ludicrous. Non-obfuscated binaries, often with debug symbols, are much easier to reverse-engineer and analyze than hardware. Additionally, you can analyze binary diffs, much like source code. You would not start from scratch at each new version. Let's also not forget how hard it is to verify source code, and how very rarely it is done.
    - nucleardog 13y ago
      You're right in an academic sense - they're completely comparable. In reality, the difference is that we can guarantee 100% of systems to work without the hardware RNG. Every binary blob we remove removes support for hardware and 'breaks' the OS for a subset of the users. No one* is going to fire up an OS and go "Hey, this OS doesn't use my hardware RNG! This OS is broken!" They will, however, fire it up and go "Hey, this OS doesn't support my network adapter! This OS is broken!" Security versus functionality. It's always a trade-off. The most secure system is the one that does nothing - everything past there is adding functionality at the expense of an increased attack surface. * To within a margin of error.
  - ori_b 13y ago
    The difference between HW RNG and binary blobs is that the computer loses no functionality without an HW RNG, although it might suffer slightly in performance. Pragmatically, this is a huge difference.
acdha 13y ago
You seem surprised that they acted where they had the ability to do so but don't where the only option involves losing users. This is the difference between engineering and idealism.
- ris 13y ago
  Ah so all of a sudden running a verifiable system is considered idealism.
  - acdha 13y ago
    > Ah so all of a sudden running a verifiable system is considered idealism. Did you build your own CPU? Write your own firmware? Audit hardware and firmware for device with access to system memory[1]? Write your own kernel? Verify your compiler[2]? Audit every line of code for everything you run? If not, you're deciding the particular areas where you choose to harbor the illusion that you're seriously verifying something. Fundamentally at some point you have to trust your hardware vendors unless you have unlimited resources to audit everything. Open source is just part of that picture and, like everything else in security, doing it professionally requires you to be pragmatic by balancing absolute security in a particular area against your users’ ability to actually do what they care about. If FreeBSD did not ship a binary driver the overwhelmingly more likely outcome would be fewer people using FreeBSD. If you care about FreeBSD, as the developers presumably do, you want as many users as possible to improve the odds of being taken seriously when you try to negotiate better support with a vendor. Consider how much trouble OLPC had with WiFi firmware – that gives you a bottom range estimate for the number of units sold which has to be on the line before a hesitant vendor will consider opening something. 1. http://md.hudora.de/presentations/#firewire-pacsec http://md.hudora.de/presentations/#firewire-pacsec 2. http://cm.bell-labs.com/who/ken/trust.html http://cm.bell-labs.com/who/ken/trust.html
    - ris 13y ago
      > Did you build your own CPU? We're playing the let's jump to absurd extremes game, are we? Ok, there's no point in any of it - nothing can be trusted - I'll go and install windows.

This coming from a BSD distribution that ships binary blob device drivers.

by ris 13y ago

This coming from a BSD distribution that ships binary blob device drivers.

tachion 13y ago

Yes, and?

opendomain 13y ago
I think he is saying, that FreeBSD ships binary device drivers - how can we trust that those do not compromise the system? If FreeBSD is open source - why are not the device drivers? If we can not trust FreeBSD for these device drivers, then why should we trust their opinion on using intel for a crypto source?
matthewmacleod 13y ago
The point was obviously that it's surprising to see that they are happy to ship binary drivers (which could contain arbitrary compromises from a user's point of view) but are not willing to trust the HWRNG (to which the same caveat applies). Of course, I don't agree with this comparison; running the output of the HWRNG through Yarrow is good practice in any case.
- AnthonyMouse 13y ago
  What's the problem with the comparison? The only real advantage of the binary blob over the hardware is that you can theoretically verify what it's doing more easily. But actually doing that verification has a difficulty on the same order as reverse engineering the driver to release an open source version, so all the existence of the binary driver does is to imply that such verification hasn't occurred -- because if it had then those doing the verification would have been in a good position to release source code (or at least complete hardware documentation) for an open source driver. Binary blob software also has the distinct disadvantage that even if you were to verify it, you would have to verify each release again whenever there is an update.
  - tachion 13y ago
    In my perspective, binary drives are a matter of choice, you can use them, but you dont have to, if you dont want to, whereas the random numbers generation is used everywhere in the OS, and you cant just decide to not to use it - that's a huge difference, what makes this comparison bad.
    - AnthonyMouse 13y ago
      Can't you though? We're really talking about defaults here. If you don't want to use the hardware RNG, you can always disable it in either the BIOS or the OS. Or use hardware that doesn't have one. The trouble is for the common user who doesn't know anything about any of this and is just going to take the defaults for everything, who is exactly the sort of person who is going to take the binary driver to "just make it work" and then be exposed to any vulnerabilities it may contain. You have to make the defaults secure because they're what most people will use. It doesn't matter that you can change it if most people never do.
  - matthewmacleod 13y ago
    Sorry, I was unclear. It's an apt comparison in that sense (it's unverified). However, there's a zero-impact workaround for this (using the CSPRNG on top of the HWRNG) so it has no user impact, whereas eliminating binary blobs does.
  - pbsd 13y ago
    The comparison is ludicrous. Non-obfuscated binaries, often with debug symbols, are much easier to reverse-engineer and analyze than hardware. Additionally, you can analyze binary diffs, much like source code. You would not start from scratch at each new version. Let's also not forget how hard it is to verify source code, and how very rarely it is done.
  - nucleardog 13y ago
    You're right in an academic sense - they're completely comparable. In reality, the difference is that we can guarantee 100% of systems to work without the hardware RNG. Every binary blob we remove removes support for hardware and 'breaks' the OS for a subset of the users. No one* is going to fire up an OS and go "Hey, this OS doesn't use my hardware RNG! This OS is broken!" They will, however, fire it up and go "Hey, this OS doesn't support my network adapter! This OS is broken!" Security versus functionality. It's always a trade-off. The most secure system is the one that does nothing - everything past there is adding functionality at the expense of an increased attack surface. * To within a margin of error.
- ori_b 13y ago
  The difference between HW RNG and binary blobs is that the computer loses no functionality without an HW RNG, although it might suffer slightly in performance. Pragmatically, this is a huge difference.

acdha 13y ago

You seem surprised that they acted where they had the ability to do so but don't where the only option involves losing users. This is the difference between engineering and idealism.

ris 13y ago
Ah so all of a sudden running a verifiable system is considered idealism.
- acdha 13y ago
  > Ah so all of a sudden running a verifiable system is considered idealism. Did you build your own CPU? Write your own firmware? Audit hardware and firmware for device with access to system memory[1]? Write your own kernel? Verify your compiler[2]? Audit every line of code for everything you run? If not, you're deciding the particular areas where you choose to harbor the illusion that you're seriously verifying something. Fundamentally at some point you have to trust your hardware vendors unless you have unlimited resources to audit everything. Open source is just part of that picture and, like everything else in security, doing it professionally requires you to be pragmatic by balancing absolute security in a particular area against your users’ ability to actually do what they care about. If FreeBSD did not ship a binary driver the overwhelmingly more likely outcome would be fewer people using FreeBSD. If you care about FreeBSD, as the developers presumably do, you want as many users as possible to improve the odds of being taken seriously when you try to negotiate better support with a vendor. Consider how much trouble OLPC had with WiFi firmware – that gives you a bottom range estimate for the number of units sold which has to be on the line before a hesitant vendor will consider opening something. 1. http://md.hudora.de/presentations/#firewire-pacsec http://md.hudora.de/presentations/#firewire-pacsec 2. http://cm.bell-labs.com/who/ken/trust.html http://cm.bell-labs.com/who/ken/trust.html
  - ris 13y ago
    > Did you build your own CPU? We're playing the let's jump to absurd extremes game, are we? Ok, there's no point in any of it - nothing can be trusted - I'll go and install windows.