Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On Sat, 08 Dec 2012 19:14:31 -0500 Tom Metro <tmetro+blu at gmail.com> wrote: > But I had my doubts that Microsoft would permit such a loader to get > signed, knowing it could easily be repurposed by malware developers. It doesn't work that way. What follows is my understanding of Secure Boot and it may not be entirely accurate. At the top is the PK (Platform Key) variable. This variable has at most one public key. If the machine ships with Windows 8 then this will contain Microsoft's PK. The PK controls access to the KEK database. The PK can be modified only by payload signed by the PK itself or switching the machine to Setup Mode and clearing the PK variable. The machine may then be left without a PK, rendering Secure Boot impossible, or the user may install his own PK. The KEK (Key Exchange Key) database is the collection of keys used to control access to the signature databases and to verify the signatures of UEFI executables. A KEK signed by Microsoft's PK is what you get when you pay the $99 fee to Microsoft. A KEK public key can be shipped with the hardware. Examples include Microsoft's KEK on Windows 8 machines, and (perhaps) Red Hat's KEK on Dell machines that ship with RHEL. A KEK public key can also be installed by a user by switching the machine into Setup Mode and running an appropriately signed executable. The KEK can be modified only by payload signed by the PK or switching the machine to Setup Mode. The forbidden signature database is where signatures for bad or invalid EFI executables are stored. The signature database is where signatures for valid executables are stored. These two databases can be modified only by payload signed by an available KEK or switching the machine to Setup Mode. The biggest problem up to this point isn't Secure Boot. It's GRUB 2. The GPL v3's "fuck Tivo" clause prohibits enforcement of digital signatures on distributed executables. It is a GPL violation to sign GRUB 2 with a KEK and distribute it in that state. Thus the scramble by Linux vendors to devise their own boot loaders or figure out ways of chain-loading GRUB 2. Red Hat is taking the first route with their loader shim. Canonical is following the second path with a replacement for GRUB 2 that isn't encumbered by the GPL. Garrett's shim works around this in a rather clever manner. While it is illegal for a Linux vendor to ship a KEK-signed GRUB 2 it is perfectly legal for me to sign it myself for my own use. shim does this by maintaining its own key and signature storage independent of the PK and KEK variables yet secured in the same manner. > OK, so I'm assuming the "Boot Services Only" variable is stored in > some Flash memory managed by the UEFI hardware, and the UEFI system > only allows its contents to be altered by code it has validated. This is correct. See above note about the PK and KEK. > If that's the case, then it makes sense. Though there are still > details missing. Presumably the "Boot Services Only" variable is > accessed via some API (software IRQ?). EFI is an execution environment. Programs compiled and stored on a file system accessible to EFI can be executed within this environment. This is where shim lives. > What is it that makes it accessible only during the boot phase and > not later? Does the shim call some API to tell UEFI that the boot > phase is over, which locks down access? Yes: the "ExitBootServices()" call. Once called the boot services variables are locked out. > No mention if this could had off to a Windows kernel in a dial-boot > setup. Or *BSD or anything else that you can install. -- Rich P.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |