[coreboot] Are any Chromebooks able to run fully libre?

[Carl-Daniel Hailfinger]

Am 21.12.2013 00:37 schrieb David Hendricks:
> On Fri, Dec 20, 2013 at 3:12 PM, ron minnich <rminnich at 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

-- 
http://www.hailfinger.org/