[Discuss] Disabling UEFI and dual booting Linux and Windows

[willrico at gmail.com (Will Rico)]

I've been trying to following the UEFI / "Secure Boot" conversation on 
this list and can't say I'm successfully following it.  Here are a 
couple of observations / questions:

1.  If very smart and experienced people on this list are saying things 
like "What follows is my understanding of Secure Boot and it may not be 
entirely accurate," then how are typical end users supposed to deal with 
this?

2.  I've seen discussion of the shim method from the perspective of the 
GNU/Linux distribution provider.  How does this work from the end-user 
perspective?  If I hand out a GNU/Linux DVD, what instructions do I need 
to provide them with beyond what I would say when giving a DVD to 
someone on a non-"Secure Boot" system?

3.  If the purpose is to prevent a malicious kernel from installing 
itself (i.e. a kernel that the end-user didn't authorize), why use a 
method based on keys?  Why not simply have the BIOS prompt the user with 
a message like:

"Warning: A new kernel (operating system) has been detected.  If you are 
installing a new operating system or if you purposefully updated your 
operating system, then this may be OK.  Otherwise, your system may have 
been attacked with a virus or malware.  Are you sure you want to boot 
the new operating system? (y/N)"

Will

On 12/08/2012 10:52 PM, Rich Pieri wrote:
> 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.
>