New subject: [SPAM] Re: Feedback On Coreboot: the Solution to the SecureBoot Fiasco

7 Jan 2013


      I've read the whole thread and I agree with Ron and Gary.
Devices that won't boot the software that the user chooses are traps and should
never be bought. Even devices that let the user control the keys they trust are 
regrettable. The only solution would be a massive rejection of the whole scheme.
On one hand I doubt the security of rejecting unsigned code is worth turning a gerneral purpose  
computer in a machine that will only run a finite set of software or will run untrusted software
with restrictions. It's like havign less of the general machine you meant to buy.
On the other even if we keep our freedom to run what we want we have already lost
the freedom of running what we want without others being able to know what we run
(in fact being able to tell we don't run what they trust).
For now secure boot only restricts what we boot (and the booted OS restricts the rest
of what we run). But in the end the purpuse is to stablish a DRM scheme so that 
if a server can't prove that we're running software trusted by them (not us) then we won't 
be able to access content or even we'll be refused connection to the internet or whatever
has to do with equipment controlled by someone else.
So yes, the only solution is, as Ron suggested to plainly reject the scheme, to avoid 
buying, running, working around these sort of restrictions. And still this is only useful 
if the majority of people does it. Then the providers of internet access, connectivity or
whatever we want of others won't find interesting to restrict their business to the few
secure booters. I'm not so optimistic about how feasible this is now
and how feasible it gets each day.
Intel CPUs are sold in equipment with intel GPUs. Intel GPUS have free software
drivers, but Intel did not provide code or documentation to boot their CPUs 
(does it now ? at least Google paid for some free code so it's better than it was, right?).
Modern Intel CPUs need to run signed, propietary code before they can even access RAM.
AMD contributes code to coreboot and documents their processors well. But then 
their GPUs (wih computing power and acces to main memory, etc.) 
run some form of propietary code (even with the free software drivers). And I 
heard their lates GPUs don't even have good support in this kind of free drivers
with propietary AtomBIOS. And the tools to implement secure boot are there too, so once everybody runs
secure booted platforms people may be able to tell we're not.
Likiwise new ARM processors are getting TrustZone and similar technology (and often
require propietary drivers for GPUs).
I haven't heard so much for MIPS, but I haven't heard of similarly powerful MIPS 
processors either.
So our choices are not very nice, even if some choices are nicer than others.
My impression is that we're headed to a world were there'll be open hardware plataforms, 
running free software and accessing more or less free content, and mainstream 
closed hardware running nonfre software and accessing DRMized content. With little 
or no bidges between these worlds.  And 
hardware does not have the same economics of software, so being a niche market
can be harder than when free software and propietary software could run on the 
same hardware.
It's a pity, but people aren't protesting enough.

Re: [coreboot] [SPAM] Re: Feedback On Coreboot: the Solution to the SecureBoot Fiasco