[coreboot] Proposal: "Freedom level" field for boards supported by coreboot

Timothy Pearson tpearson at raptorengineering.com
Sun Feb 5 22:31:17 CET 2017


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/04/2017 07:50 PM, KOLANICH wrote:
>> No amount of reverse engineering or hacking will ever allow a fully libre firmware to execute on these boards.
> 
> It's false, hardware can be vulnerable to fault injection attacks allowing to bypass vendor lockin mechanisms.

How exactly does this fault injection mechanism work when the CPU won't
execute a single instruction if an invalid signature is computed?  Every
exploit I am aware of requires one of two things:

* The ability to run arbitrary code in a lower privilege level, then
escalate privilege via bugs in the proprietary software

* The ability to directly control the main CPU through hardware means
(JTAG, DMA attack, etc.)  The needed parts of the hardware are typically
fused off on consumer-bound silicon these days.

Unfortunately for the libre software community, attacking a modern x86
platform in this manner is not only illegal, but has become an arms race
similar to smartphone jailbreaking.  To make matters worse, the x86
manufacturers have already won this arms race at the firmware level;
even if you could find a fault in the firmware and somehow exploit it,
you still have to run that initial signed firmware blob to even get the
system to start executing instructions.

>> Boards in this class require absolutely no proprietary (closed and/or signed) firmware to operate.
> imho contradicts to
>>> Microcode may be required by the host CPU, and is closed source and/or unable to be modified without vendor intervention.
> 
> because microcode is run on main CPU and IMHO is also a firmware

As soon as we can feasibly drop the microcode exemption I will support
its removal.  That being said, only having low-power ARM systems
available is *not* the way to make people care about freedom level;
horizontal microcode has been traditionally exempted for a couple of
decades now, and I see no reason to change this until POWER becomes
somewhat more affordable / common.

>> Boards in this class require proprietary, closed firmware executing on the main CPU to operate.
> 
> ME is not main CPU, right?
> 
> And I think we need 2 more categories: "explicitly malicious" ("shrinkwrap eula", "DRM", "business aggreement" etc) and "wannabe free" (gold + some hardware is open (firmwares + schematics)  + building open platform is a one of the goals of project).

I disagree.  Any system requiring vendor signing keys at the hardware
level is explicitly malicious, and it does no good whatsoever to make
believe that having open schematics for such a machine is any benefit
whatsoever; it's rather like being able to look at the infrastructure
feeding a factory but still having no idea what's going on inside the
factory.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYl5mjAAoJEK+E3vEXDOFbjIQH/3sIsXKG1GORtGZEPdOsb2eq
kg3D1rmVtKV96qqlSaSDdT3YXwxZ5kP9oH7TRUS7UKiKXygAOjfG9Y36QFZ6PQ1E
c5Pc7cst+0DyRwLTfDcB3Iiv2t16p/gnEPZ455f+J9uuYDLn22CsPO7vZ9k4mNE4
e4fTyGV+okjqLLDNTy0o6VsZogWoWcL7Rf13zffMdnS2nKdy5ShVMke6EJXKkKJA
Gp7/FUdEanVLreT7scyMl2H5d/aS2bSQVkm2X/zTaingM1P6p//Z2oqVLFu32yLv
RpQyLl0Tsj3L//ROU2SRzsc7BN7h3o5JVUI3CVsPPiR7N2/Ang8r6qCLSiVw1Ec=
=h6t7
-----END PGP SIGNATURE-----



More information about the coreboot mailing list