Image of XSLT 2.0 and XPath 2.0 Programmer's Reference (Programmer to Programmer)
Image of Modern Operating Systems (3rd Edition)
Image of Advanced Programming in the UNIX Environment, Second Edition (Addison-Wesley Professional Computing Series)
Image of RHCE Red Hat Certified Engineer Linux Study Guide (Exam RH302) (Certification Press)

UEFI Secure Boot

A few days ago, Red Hat developer Matthew Garrett blogged about the possibility that Linux could be locked out of the next generation of UEFI-enabled PCs. The technical press picked up the story and it spread like wildfire as if it were new news.

The truth, however, is that this issue has been publicly known about in the Linux world since at least May 2011. For example, Jake Edge wrote a long and detailed article about this very issue in the June 15th issue of Linux Weekly News. Moreover, by their own admission, Red Hat actively participates in the UEFI specification process and even attends some of the plug-fests. If Red Hat are now just waking up and realizing what they signed off to in this revision of the UEFI specification then somebody in Red Hat badly missed the ball and maybe should be shown the door.

All Microsoft is saying is that if a PC vendor wants ship systems with Windows 8 pre-installed they must have secure boot enabled by default, that firmware not allow programmatic control of secure boot (to prevent malware from disabling security policies in firmware), and that PC vendor prevent unauthorized attempts at updating firmware that could compromise system integrity. That is all goodness from a security point of view.

Low end PCs will probably end up without a means to add keys. That is simply the nature of low end low margin manufacturing. High end server-type systems will almost certainly have the right tools to add the appropriate public KEKs (Key Exchange Key) into the platform firmware. See Section 27.5 of Version 2.3.1 of the UEFI Specification for all the gory details.

Frankly, this is all a storm in a teacup.

Comments are closed.