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

[Patrick Georgi]

Am 02.01.2014 21:31, schrieb Sam Kuper:
> I see that coming within case 2. The Intel CPU microcode I gave as an
> example has this problem, IIUC. Perhaps I'm wrong, but I see it as
> being like the Content Scramble System (CSS), AACS, etc, and we're
> waiting for someone to create the equivalent of DeCSS, etc, so that
> libre (or at least open source) alternative microcode can be made to
> exist that would actually work on the CPU.

For CSS and AACS, the organizing body has to provide keys to vendors, 
and keep all of them compatible with pretty much every disc out there.

Here we have one vendor, and the files are typically not transferrable 
across chip versions, so they can create a new key for every version, 
limiting the impact.

If I remember things correctly, Intel uses RSA-2048 signatures on a 
SHA256 hash. The capability to crack such a scheme probably provides 
more lucrative opportunities than firmware freedom and that makes me 
guess people would routinely do it, if possible.

How about simply refusing to pay for malfeatures like these instead of 
increasing the platform's value for vendors that absolutely don't want 
you to do it for them (as expressed by both their conduct and their 
signature scheme)?

Patrick

Are any Chromebooks able to run fully libre?

[Sam Kuper]

On 02/01/2014, Patrick Georgi  wrote:
> Am 02.01.2014 21:31, schrieb Sam Kuper:
> Here we have one vendor, and the files are typically not transferrable
> across chip versions, so they can create a new key for every version,
> limiting the impact.
>
> If I remember things correctly, Intel uses RSA-2048 signatures on a
> SHA256 hash. The capability to crack such a scheme probably provides
> more lucrative opportunities than firmware freedom and that makes me
> guess people would routinely do it, if possible.

Agreed, although the work by Molina and Arbaugh, and by Ben Hawkes,
has started some little inroads towards perhaps eventually unpicking
the microcode.
> How about simply refusing to pay for malfeatures like these instead of
> increasing the platform's value for vendors that absolutely don't want
> you to do it for them (as expressed by both their conduct and their
> signature scheme)?

I'm actively researching alternatives, but because there's no perfect
solution, I have to strike a balance between the freedom I want and
the features/compatibility I want.

My earlier question about the Acer C7/C710 and HP Pavilion 14 was
motivated by the following consideration: if they have not been found
to have CPU errata warranting uploading of CPU microcode, then they
might be (at least in this respect) preferable to the X60 which forces
the user to choose between uploading microcode or running with known
vulnerabilities.*

Regards,

Sam

* Yes, there's debate about the seriousness of some of these
vulnerabilities[1][2]; and yes, Linus did downplay them[3], but I
think he downplayed them on the assumption that users *would* use the
microcode patches to handle those needing microcode patches[4] and
that kernels and compilers would be checked, and updated if necessary,
to handle the rest.

[1] http://hardware.slashdot.org/story/07/06/28/1124256/theo-de-raadt-details-in...
[2] http://www.cs.dartmouth.edu/~sergey/cs258/2010/D2T1%20-%20Kris%20Kaspersky%2...
[3] http://www.realworldtech.com/forum/?threadid=78455&curpostid=78469
[4] http://www.realworldtech.com/forum/?threadid=78455&curpostid=78477