*countable infinities only

Przemek Klosowski przemek.klosowski at nist.gov
Tue Jun 5 15:20:48 UTC 2012


On 06/02/2012 06:27 PM, drago01 wrote:

> No one is preventing anyone from providing instructions on how to
> disable secure boot. We should definitely do that.
> But those are not mutually exclusive ... i.e we can have both
> documentation *and* an OS that just works.

Everyone, including Microsoft, agrees that the secure boot system can be 
disabled. Currently the only envisioned mechanism is via a firmware 
(UEFI) setup, therefore subject to vagaries of different firmware 
implementations. The firmware is beyond our control: we can't give 
reliable and meaningful instructions to the user on how to set it, and 
AFAIK there is no API that would allow the bootloader, or other software 
layers we control, to reach back and set it for future boots.

Therefore(*), it is reasonable and fair to implement an equivalent 
facility in the signed bootloader, by offering the end user a choice to 
leave the signed environment. The bootloader might enumerate 
signed/secure kernels (Windows and official Fedora), but also offer an 
extra choice, educating the end user by warning that it not only results 
in booting into a non-secure environment but also opens the possibility 
of subverting one of the signed/secure environments.

I believe(*) this is a defensible position---the choice is left to the 
end user, and the security implications are almost identical to doing it 
in firmware. A residual risk of exploits needs to be dealt with, just 
like vulnerabilities in the rest of the secure boot process; the only 
downside being that firmware implementations are diverse, and this 
option would present a single target for exploit attempts, so it would 
need a heightened level of review.

                  Greetings
                              przemek


(*) These are my personal opinions based solely on my own judgement and 
experience as the technology user. As such, they express only my own 
personal preferences and are not to be construed in any broader sense.


More information about the devel mailing list