[personal profile] mjg59
There's a post here describing SUSE's approach to implementing Secure Boot support. In summary, it's pretty similar to the approach we're taking in Fedora - a first stage shim loader is signed with a key in db, it loads a second stage bootloader (grub 2) that's signed with a key that's in shim, the second stage bootloader loads a signed kernel. The main difference between the approaches is the use of a separate key database in shim, whereas we are currently planning on using a built-in key and the contents of the firmware key database.

The main concern about using a separate key database is that applications are able to modify variable content at runtime. The Secure Boot databases are protected by requiring that any updates be signed, but this is less practical for scenarios where you want the user to be able to modify the database themselves while still protecting them from untrusted applications installing their own keys. SUSE have solved this problem by not setting the runtime access flag on the variable, meaning that it's inaccessible once ExitBootServices() has been called early in the init sequence. Since we only start running any untrusted code after ExitBootServices(), the variable can only be accessed by trusted code.

It's a wonderfully elegant solution. We've been planning on supporting user keys by trusting the contents of db, and the Windows 8 requirements specify that it must be possible for a physically present user to add keys to it. The problem there has been that different vendors offer different UI for this, in some cases even requiring that the keys be in different formats. Using an entirely separate database and offering support for enrolment in the early boot phase means that the UI and formats can be kept consistent, which makes it much easier for users to manage their own keys.

I suspect that we'll adopt this approach in Fedora as well - it doesn't allow anything that our solution wouldn't have, but it does make some of them easier. Full marks to SUSE on this.

I partly disagree

Date: 2012-08-11 10:53 pm (UTC)
From: (Anonymous)
In then end you conclude that
[Error: Irreparable invalid markup ('<it [...] doesn't>') in entry. Owner must fix manually. Raw contents below.]

In then end you conclude that <it doesn't allow anything that our solution wouldn't have>.
I disagree with this. Having the user press a key during the boot process requires that pre-boot services enumerate input devices. This goes against Microsoft recommendations that USB input devices and media not required for boot not be enumerated in order to save valuable time. I can't quite remember if this is a requirement for certification, but it could pose a problem for current generation desktop computers that do not feature PS/2 or dedicated hardware buttons for this.
Using 'db' keys, as initially proposed, would offer users a single path of access to settings(which can be navigated as per the computer's manual, reducing complexity for the user) that would not hurt the bootup speed.
If I properly understood the plugfest presentations, there is a middle ground to this. I believe you could offer an EFI extensions(as option ROMs do) for this, and could make it show up in the normal UEFI configuration interface. This should maintain a consistent user interface and allow for more flexibility, while still keeping the user away from the global key store.

Re: I partly disagree

Date: 2012-08-11 10:55 pm (UTC)
From: (Anonymous)
terribly sorry for that. I didn't use the preview..

Re: I partly disagree

Date: 2012-08-14 12:20 am (UTC)
From: (Anonymous)
That's ridiculous. We already use a boot loader (GRUB 2) that requires use of input devices. Using input in a shim boot loader is effectively the same thing. I could care less about Microsoft's recommendations. This method of booting has and will continue to work just fine.

Re: I partly disagree

Date: 2012-08-14 06:52 pm (UTC)
From: [personal profile] mwsealey
If Boot Services doesn't enumerate input devices then it won't be able to let you hit a key to enter the UEFI configuration.

Microsoft's recommendations in this case are directed at Windows 8 Tablets and suchlike, and places where enumeration of input devices would take an inordinate amount of time mostly because they won't exist and you face running into the maximum defined timeouts for absolutely no benefit. Most tablets do not attach anything worth using at UEFI time to a USB bus anyway, and if they do, it's usually a PC via OTG or HID because your tablet is in some kind of recovery mode.

Yes, booting fast is important, but it's actually going to take fairly long to bring the rest of the system up anyway to get to a bootable system than any looking for a USB Boot Protocol Keyboard or Mouse device will take - especially if you have the option of booting from a USB hard drive, USB CD-ROM or similar, you're going to be looking for these anyway (otherwise how else would you install Windows from "DVD" to make a fresh system for retail copies?)

What I'd like to see is taking GRUB out of the equation and just using UEFI to select your kernel. You can provide a list of suitable boot sources to UEFI fairly easily. The shim should use UEFI Boot and/or Runtime Services to load configuration and simply go. GRUB, here, is just a legacy for distros who must continue to use GRUB for compatibility with non-UEFI systems, but given grub-legacy and grub2 work differently anyway, someone already dealt with the compatibility issues of changing the way the bootloader worked, and UEFI boxes are going to have to deal with a FAT partition to boot from anyway which is another layer of *argh* compared to just having a single ext4 or btrfs partition for /.

Date: 2012-12-06 04:09 pm (UTC)
From: (Anonymous)
If SUSE have done a good job, what is the rationale for Fedora doing their own thing?

Linux distributions suffer from enough Not Invented Here as it is. Every iota of effort you waste competing with each-other is effort not spent competing with Windows or OS X (or just making a better product with all the bugfixes in one place).

Profile

Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Nebula. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Page Summary

Expand Cut Tags

No cut tags