[Discuss] Disabling UEFI and dual booting Linux and Windows

[richard.pieri at gmail.com (Rich Pieri)]

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.