Home Business IT Open Source Garrett releases first-stage bootloader to facilitate secure boot

Linux developer Matthew Garrett has completed work on a first-stage bootloader, called Shim, for supporting secure boot, and put it online for use by anyone who wishes to do so.

Microsoft has implemented a process of using cryptographic key exchanges at boot-times for machines running Windows 8; this is possible due to the new firmware for PCs which is called UEFI or Unified Extensible Hardware Interface.

All machines pre-loaded with Windows 8 come with secure boot turned on; this means that other operating systems cannot boot on these machines unless they also support the process.

Three GNU/Linux distributions - Red Hat, Ubuntu and SUSE - have been working towards enabling booting on hardware certified for Windows 8; the Linux Foundation has been doing so as well, but Garrett appears to have beaten everyone to the post.

In a post on his blog, Garrett said he had done this on his own, even though he had been working on this solution while an employee of Red Hat, a company he has now left.

His work has involved developing the code, in association with others, buying a key from Verisign for $US99, and then submitting the code for signing by Microsoft which controls the certificate-signing authority.

Garrett has provided detailed instructions for those who wish to use his first-stage bootloader.

A response in the comments to his post, from Vojtech Pavlik, director of SUSE Labs and head of kernel development at SUSE, said the company would be using the same code for its first-stage bootloader, but doing the signing process itself.

Garrett's code is under a BSD licence and can thus be redistributed by anyone who wishes to do so.

No GNU/Linux distribution supports secure boot as yet, not even the recently released beta of Fedora 18.

Update, Dec 4: There are reports that the 64-bit version of Ubuntu 12.10 will boot on machines where secure boot is enabled. This has to be verified.

FREE WHITEPAPER - RISKS OF MOVING DATABASES TO VMWARE

VMware changed the rules about the server resources required to keep a database responding

It's now more difficult for DBAs to see interaction between the database and server resources

This whitepaper highlights the key differences between performance management between physical and virtual servers, and maps out the five most common trouble spots when moving production databases to VMware

1. Innacurate metrics
2. Dynamic resource allocation
3. No control over Host Resources
4. Limited DBA visibility
5. Mutual ignorance

Don't move your database to VMware before learning about these potential risks, download this FREE Whitepaper now!

DOWNLOAD!

Sam Varghese

website statistics

A professional journalist with decades of experience, Sam for nine years used DOS and then Windows, which led him to start experimenting with GNU/Linux in 1998. Since then he has written widely about the use of both free and open source software, and the people behind the code. His personal blog is titled Irregular Expression.

Connect