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

Olliver Schinagl oliver+list at schinagl.nl
Mon Dec 23 06:45:01 CET 2013

On 21-12-13 00:37, David Hendricks wrote:
> On Fri, Dec 20, 2013 at 3:12 PM, ron minnich <rminnich at gmail.com
> <mailto: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.
>     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. 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 the Allwinner based SoC's (A10, A10s, A13, A20 and A23) there is 1 
blob (split into two parts) in the ROM. Blob 1 is the bootloader that 
tries to boot various media (MMC, NAND, SPI-NOR flash) and which is 
partially dissasembled (asm -> C) so we know pretty much what it does. 
It is 9k and has no RAM access and as far as we can tell not invoked 
after u-boot (sorry no coreboot (yet?) :p) takes over. The second bit in 
the BROM is the 10k so called 'FEL' mode, emergency recovery mode where 
it has an USB driver for the OTG controller and allows you to upload and 
execute code via USB.

These blobs are burned into the SoC's rom and unchangable, but we have 
extract them and it is inspectable what it does [1].

As for the rest of the SoC, we have drivers for almost every bit of IP, 
except the GPS unit, which actually has been removed from the latest 
versions of the SoC, the GPU, but with Luc's LIMA that's not a big issue 
for long and finalyl the VPU, which has been largely reverse engineerd 
and some working Proof of concept code exists.

With the Olimex boards that are opensource-hardware, It's hard to find a 
more open deal then that.


[1] https://github.com/hno/Allwinner-Info/tree/master/BROM

> 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...
>     At this point it's harder and harder to escape the Blob. It eats you
>     alive! http://www.youtube.com/watch?v=TdUsyXQ8Wrs
>     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.
>     ron
>     --
>     coreboot mailing list: coreboot at coreboot.org
>     <mailto:coreboot at coreboot.org>
>     http://www.coreboot.org/mailman/listinfo/coreboot
> --
> David Hendricks (dhendrix)
> Systems Software Engineer, Google Inc.

More information about the coreboot mailing list