> 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.
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.
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.
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.
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.
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.
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.
I don't know if they're that much different. If you turn off the hardware RNG then generating random numbers becomes significantly slower. Maybe most people don't care, but I expect most people also don't care if their network card doesn't do TOE as a result of you shipping an open source driver that isn't feature complete rather than a binary blob driver that is.
The flaw in your argument is the assumption that the drawback of using a software RNG instead of a hardware RNG is inherently less than the drawback of using an open source driver instead of a proprietary binary blob driver. There may exist specific circumstances where this actually the case (as is obvious if there is no open source driver whatsoever), but that isn't the immutable state of the world. If you take this kind of security to be a Serious Issue then it demands for engineering effort (or community pressure) to be directed toward the goal of having published source code for all hardware drivers. One of the ways you can do that is by refusing to ship binary blobs (as Debian does), which creates some trouble for Debian, but also creates some trouble for the hardware vendors who now have customers avoiding their hardware because it involves more trouble than a competitor's hardware.
The typical response to this is the argument that not enough people run these operating systems to make the hardware manufacturers care, so you do more harm to yourself than you do to them. But that's ignoring the demographics. The primary constituency of Unix-like operating systems is the likes of IT professionals, systems administrators and software developers. These are the people who buy computer hardware by the pallet. Hardware manufacturers do not want those people to notice them in a bad way.
This is incidentally why the state of open source GPU drivers is so much worse than the state of e.g. open source network drivers. When the local BOFH goes to buy a thousand rack units of Debian servers, he generally cares a lot more about the NIC than whether it will do 3D hardware acceleration. But that's going to change soon enough as GPGPU gets popular in the datacenter.
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.
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.
