Am 21.12.2013 00:37 schrieb David Hendricks:
On Fri, Dec 20, 2013 at 3:12 PM, ron minnich rminnich@gmail.com wrote:
To expand on this answer, it's going to be just about impossible, going forward, to become blob-free on any popular platform. I can go into more detail if you want to know the particulars, but there's so many places in our systems containing blobs, far more than in 2000, and as fast as we seem to stamp them out, new blobs crop up.
Indeed. A few years ago nobody could have predicted that all USB 3.0 controllers require firmware (arguably because the silicon is too crappy to work well in the real world).
Not possible on any popular ARM products of which I am aware (e.g. most of chips have a ROM in the CPU mask which is closed and not replaceable); definitely not an option on anything new from Intel. And it's really a matter of a tradeoff. The Chromebooks come with blobs, it is true; but the EC is blob-free.
This may be a dumb question, but is the Chromebook EC present in all Chromebooks, and is that particular EC also available for non-Chromebook production? I see some vendors offering both Chromebooks and AMD-based laptops. It would be interesting to check whether there is a possible synergy or cross-device pollination.
You can get AMD-based laptops, maybe with coreboot, and they'll come with a closed EC with blobs. The wonderful work on the X60 and X201 has gone very far, but the EC blob remains. It's a really hard problem!
I think it's important to keep the scope of these blobs in mind. The BL1 blob used on the Exynos5xxx chips (like on the Samsung XE303C12 Chromebook), for example, is small (~8K) and mostly exists to just load the next phase. Contrast that with the multi-megabyte management engine blob on Intel platforms that runs on its own microcontroller and has unfettered access to DRAM and networking resources.
For ECs, the attack vector to worry about is key logging but at least that can be mitigated if you can read the EC firmware and verify its contents like we do on Chromebooks. But of course simply reading the EC firmware on a typical laptop can be a challenge...
The big question is why someone doesn't want to have blobs in the system: 1. Freedom: The FSF/Stallman say that ROMs are hardware and thus the "software" aspect of free software does not apply, i.e. closed source ROMs are OK. Some people only care about freedom if the code runs on the main CPU, others want all software to be free, including Wifi adapter firmware and DVD drive firmware. 2. Fixability: The ability to fix software and the ability to work around hardware bugs in software. 3. Information Security: Any blob is an undefined hole in the threat model / attack surface. Those undefined holes should be in places where they have the least impact on your security targets.
I used to think that reasons 1+2 are key, but nowadays I know that reason 3 is where the big money is. The defense sector does not care about free software or fixability, but they do care very much about availability, confidentiality and integrity of the systems used in critical environments.
Short summary of the impact of evil blobs from an information security perspective: For USB3/Wifi/DVD/graphics firmware on devices with DMA capability, an IOMMU is a reasonably simple, safe and sane way to lock them in. The remaining impact of an attack via those devices is mostly on availability. For CPU microcode, the usual argument is that it is very limited in size, making it very difficult to mess with things. Crypto-related instructions come to mind as possible target, and for that reason some certification bodies don't trust AES intrinsincs and certify only manually coded crypto. For EC firmware, it depends very much on whether the EC has access to system resources. An EC without DMA capability and without data access to any device can compromise availability (let the battery explode, switch off the machine or components). An EC managing keyboard/touchpad/mouse has the additional option of compromising integrity of keyboard/mouse input and (via a side channel) confidentiality of keyboard/mouse input. For devices with unrestricted DMA access to memory and/or control of the main CPU (Raspberry Pi graphics, Intel Management Engine), all bets are off. For the main CPU, running an evil blob at a high privilege level (e.g. as part of the firmware) compromises everything.
I think the idea of creating blob-free systems continues to be a wonderful idea, one that I'd love to see happen some day.
Quoting from another thread:
Am 20.11.2013 16:23 schrieb ron minnich:
To do a laptop port you really need to interact with an EC. The EC has been a problem for years. If you want a sane EC (i.e. 32-bit, not some 8-bit POS emulating an 8051) and you want open source software for that EC and you want coreboot ... you're going to get a chromebook. And those three things, as we have learned many times, are pretty essential to a port, unless you want to spend 3 or more years on the port.
I've got a student coming in January and he's going to work on ChromeOS on AMD CPUs, starting with the Gizmo. If, at that time, someone has a suggestion for an AMD laptop which might be suitable, let me know.
Is that offer still valid? I hope to have an AMD-based laptop model with long shelf life to recommend by early January.
Regards, Carl-Daniel