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
--
coreboot mailing list: [email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
