[uefi-secure-boot-guide] master: Add changes from fweimer (41e0a77)
sparks at fedoraproject.org
sparks at fedoraproject.org
Sat Feb 9 01:28:23 UTC 2013
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit 41e0a77521b69b009060af08e4f763d48a31f7f2
Author: Josh Bressers <josh at bress.net>
Date: Fri Feb 8 13:45:18 2013 -0600
Add changes from fweimer
Signed-off-by: Eric Christensen <sparks at fedoraproject.org>
>---------------------------------------------------------------
en-US/Author_Group.xml | 9 ++
en-US/Implementation_of_Secure_Boot.xml | 19 +++-
en-US/What_is_Secure_Boot.xml | 148 ++++++++++++++++++++++++++++---
3 files changed, 159 insertions(+), 17 deletions(-)
diff --git a/en-US/Author_Group.xml b/en-US/Author_Group.xml
index d653683..0296563 100644
--- a/en-US/Author_Group.xml
+++ b/en-US/Author_Group.xml
@@ -40,6 +40,15 @@
</affiliation>
<email>bressers at redhat.com</email>
</author>
+ <author>
+ <firstname>Florian</firstname>
+ <surname>Weimer</surname>
+ <affiliation>
+ <orgname>Red Hat</orgname>
+ <orgdiv>Product Security Team</orgdiv>
+ </affiliation>
+ <email>fweimer at redhat.com</email>
+ </author>
<editor>
<firstname>Eric</firstname>
<surname>Christensen</surname>
diff --git a/en-US/Implementation_of_Secure_Boot.xml b/en-US/Implementation_of_Secure_Boot.xml
index 6bb4bb2..af49f63 100644
--- a/en-US/Implementation_of_Secure_Boot.xml
+++ b/en-US/Implementation_of_Secure_Boot.xml
@@ -124,13 +124,24 @@ URI:https://fedoraproject.org/wiki/Features/SecureBoot
<section id="sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Shim">
<title>Shim</title>
<para>
- Shim is a signed binary that is used to boot the system. Secure
-Boot requires a binary to be signed by Microsoft, which helps create a
-chain of trust from the BIOS to the operating system. In Fedora the signed
-binary is named shim. Development of shim happens on github here:
+ Fedora uses a first-stage boot loader called shim which embeds a
+self-signed CA certificate. This CA is then used to verify the GRUB 2 boot
+loader (UEFI version, a PE/COFF program signed with AuthentiCode). Before
+booting a kernel, GRUB 2 calls back into shim to verify the AuthentiCode
+signature of the kernel.
+ </para>
+ <para>
+Development of shim happens on github here:
https://github.com/mjg59/shim
</para>
<para>
+shim supports "machine owner keys" (additional trusted certificates) and a
+mechanism to disable signature verification. The information is kept in
+UEFI variables which cannot be written after an operating system has
+booted. shim contains a physical presence check and asks for confirmation
+before it updates the settings stored in these UEFI variables.
+ </para>
+ <para>
<indexterm><primary>shim</primary><secondary>explanation</secondary></indexterm>
In &PRODUCT; there are two packages that make up shim. The
package named "shim" is the result of compiling the source code from GitHub
diff --git a/en-US/What_is_Secure_Boot.xml b/en-US/What_is_Secure_Boot.xml
index 10d5a3d..f908b6c 100644
--- a/en-US/What_is_Secure_Boot.xml
+++ b/en-US/What_is_Secure_Boot.xml
@@ -6,7 +6,28 @@
<chapter id="chap-UEFI_Secure_Boot_Guide-What_is_Secure_Boot">
<title>What is UEFI Secure Boot?</title>
<para>
- <firstterm>Secure Boot</firstterm> is a setup using <firstterm>UEFI</firstterm> firmware to check cryptographic signatures on the bootloader and associated operating system kernel to ensure that only trusted binaries are loaded during the boot process. These signatures are verified against keys stored in UEFI variables. If a binary contains a valid signature, it is allowed to execute. If it does not, the binary is not allowed to execute.
+<firstterm>Secure Boot</firstterm> is a technology where the system boot
+loader (<firstterm>UEFI</firstterm> environment, previously called "BIOS")
+checks that the next-stage boot loader is signed with a cryptographic key
+authorized by the configuration of the system boot loader. With adequate
+signature verification in the next-stage boot loader(s), kernel, and,
+potentially, user space, it is possible to prevent the execution of
+unsigned code. Certificate and signature revocation is implemented using
+append-only boot loader configuration variables, and additions must be
+cryptographically signed.
+ </para>
+ <para>
+From a user point of view, a system which has enabled Secure Boot and which
+is confronted with a tampered boot path simply stops working until Secure
+Boot is disabled or a signed next-stage boot loader is available on boot
+media. Similarly, operating system installers do not run and result in an
+error message. Users are not offered a way to override the boot loader
+decision to reject the signature, unlike the similar scenario with web
+server certificates. No certificate issuer information is provided to the
+user. Secure Boot does not prevent the installation or removal of
+second-stage boot loaders or require explicit user confirmation of such
+changes. Signatures are verified during booting, and not when the boot
+loader is installed or updated.
</para>
<para>
Earlier versions of &PRODUCT; booted on such hardware will refuse to boot until the user disables Secure Boot in the firmware. While disabling Secure Boot is a viable option that some users may wish to choose, it is not an optimal solution.
@@ -16,14 +37,62 @@
<para>
To facilitate out of the box functionality on new hardware, the maintainers of the <firstterm>GRUB</firstterm>, <firstterm>kernel</firstterm>, and associated packages have implemented Secure Boot support in &PRODUCT;. On UEFI machines, &PRODUCT; uses a small bootloader called <firstterm>shim</firstterm> that has been signed by the Microsoft signing service (via Verisign). This allows UEFI to load shim on Windows 8 client ready machines and continue the boot process for Linux. Shim in turn boots GRUB, which is signed by a &PRODUCT; key. GRUB then boots a similarly signed Linux kernel provided by &PRODUCT; which loads the rest of the OS as per the usual boot process. The machine remains in Secure Boot mode.
</para>
+ <note>
+ <title>Client Technology</title>
+ <para>
+Secure Boot is only available on some client devices, and it is explicitly
+labeled as client (as opposed to server) technology. It is expected that
+server technology will support Secure Boot at a future date.
+ </para>
+ </note>
+ <section id="sect-UEFI_Secure_Boot_Guide-What_is_Secure_Boot-Microsoft_Implementation">
+<title>Microsoft Implementation</title>
+ <para>
+Microsoft controls the cryptographic chain installed by system vendors.
+With its Secure Boot signing service, Microsoft creates an AuthentiCode
+signature on binaries submitted by third parties for use with Secure Boot.
+(A regular code signing certificate is not directly usable for booting, it
+is only used for submitting the binary to Microsoft.) The signatures which
+come out of signing service are currently pseudonymous and do not permit
+the identification of the party that submitted the binary.
+ </para>
+ <para>
+Microsoft Windows 8 supports AuthentiCode validation and loading of
+third-party kernel modules. Hibernation is not disabled, which may provide
+a venue to circumvent Secure Boot. Windows has infrastructure to extend
+cryptographic validation to user space programs, too.
+ </para>
+ <para>
+Microsoft is expected to eventually ship signed revocation requests in
+Windows Update which are installed into the system boot loader
+configuration during the next system boot. At the time of this writing,
+such a blacklist does not yet exist.
+ </para>
+ <para>
+Microsoft supports Secure Boot only with Windows 8, but it is not required
+for running Windows 8. Systems in a Secure Boot environment still boot if
+Secure Boot support is removed from the UEFI environment. Customers who
+want to use previous versions of Windows need to disable Secure Boot
+because Microsoft does not provide signed second-stage boot loaders for
+them.
+ </para>
+ </section>
<section id="sect-UEFI_Secure_Boot_Guide-What_is_Secure_Boot-Protect_you_from">
<title>What does Secure Boot protect you from?</title>
<para>
- Secure Boot is really just a mechanism to protect the boot phase of
-a system. The goal is to prevent untrusted code from booting the system,
-once that part has been verified, it's up to the operating system to take
-over protection. This does give the potential for the operating system to
-extend this chain of trust down into user binaries, but that is beyond the scope of this document.
+It is no longer possible to execute unsigned code in kernel mode (assuming
+that all system and operating system vendors do not implement any
+deliberate or accidental loopholes). This prevents the execution of
+currently existing malware during system boot.
+ </para>
+ <para>
+Secure Boot simplifies verification of the boot path in digital forensics.
+Legacy BIOS booting executes potentially malicious code loaded from the
+disk in a very early stage, which makes it difficult to rule out that the
+operating system has been tampered with at a very low level. (Parts of this
+benefit comes from the more declarative nature of the UEFI boot
+configuration on disk.) Pseudonymous signatures reduce the benefits for
+forensics.
</para>
<para>
&PRODUCT; has expanded the chain of trust into the kernel.
@@ -33,16 +102,69 @@ unsigned executable code is present until the initial ramdisk (initrd) is loaded
initrd cannot currently be signed, it cannot be verified.
</para>
</section>
- <section id="sect-UEFI_Secure_Boot_Guide-What_is_Secure_Boot-Does_not_Protect_you_from">
- <title>What does Secure Boot not protect you from?</title>
+ <section id="sect-UEFI_Secure_Boot_Guide-What_is_Secure_Boot-Risks">
+ <title>Potential Secure Boot Risks</title>
<para>
Secure Boot will not protect your PC from malware or attackers.
-Secure Boot itself is simply to protect the boot phase of a system. In
-&PRODUCT; if you use Secure Boot, what modules the kernel loads can be
-restricted, but user space malware cannot. This of course doesn't mean
-Secure Boot isn't useful, just that it currently only serves a single
-purpose, which is protecting the boot loader.
+Secure Boot itself protects the boot phase of a system. In &PRODUCT; if you
+use Secure Boot, what modules the kernel loads can be restricted, but user
+space malware cannot. The initial ramdisk (initrd) disk image used during
+boot is not signed and could contain malicious code. The kernel
</para>
+ <section id="sect-UEFI_Secure_Boot_Guide-What_is_Secure_Boot-Risks-Forced_Removal_of_Features">
+ <title>Forced removal of features in Secure Boot mode</title>
+ <para>
+ We currently use a blacklist approach to disable known-unsafe
+kernel functionality. If additional kernel functionality which is
+equivalent to arbitrary code execution in kernel mode becomes known, we
+will be forced to disable it. Customers relying on this functionality will
+be left with non-working hardware after a system upgrade, and perhaps with
+unbootable systems. Recovery would require manual steps per system, and
+physical presence may be required.
+ </para>
+ </section>
+ <section id="sect-UEFI_Secure_Boot_Guide-What_is_Secure_Boot-Risks-System_Transition">
+ <title>System Transitions out of Secure Boot</title>
+ <para>
+ A BIOS upgrade or mainboard replacement can disable Secure Boot
+on systems where it was previously enabled. Additional hardware installed
+into a machine may have requirements incompatible with Secure Boot (user
+space DMA, SystemTap support, non-Red Hat kernel modules). This means
+Secure Boot cannot be a requirement for system functionality, and it is
+extremely unwise to make it a policy requirement.
+ </para>
+ </section>
+ <section id="sect-UEFI_Secure_Boot_Guide-What_is_Secure_Boot-Risks-Provisiont_Beyond_Windows">
+ <title>No provisioning infrastructure beyond Microsoft Windows</title>
+ <para>
+ Some system vendors reportedly require a Windows 8 installation
+to activate Secure Boot. Customers who want to enable Secure Boot might
+have to obtain a Windows 8 client license, personalized by their system
+vendor. This scenario would not be relevant if Red Hat relied on a separate
+trust root under our control, provisioned in cooperation with hardware
+vendors.
+ </para>
+ </section>
+ <section id="sect-UEFI_Secure_Boot_Guide-What_is_Secure_Boot-Risks-Unproven_Revocation">
+ <title>Unproven Revocation Procedures</title>
+ <para>
+We do not know if the business processes surrounding revocation actually
+work. Revocations are complex because they have to be synchronized among
+operating system vendors to support dual-boot configurations. Without such
+coordination, a signature on a boot path could be revoked before the
+underlying operating system had a chance to update it. This would leave
+systems unbootable.
+ </para>
+ <para>
+It is not clear under what circumstances Microsoft will issue an
+unsolicited revocation. Potential revocation reasons are a failure to reach
+the security objective (that is, execution of unsigned code in kernel mode
+is possible under lab conditions), or actual exploitation of such a failure
+to compromise the boot path of Windows 8 systems outside labs. The latter
+could also apply to Secure Boot workarounds which load unsigned code after
+user interaction.
+ </para>
+ </section>
</section>
</chapter>
More information about the docs-commits
mailing list