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+...@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.
_______________________________________________
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss
