[uefi-secure-boot-guide] fweimer: Reorganize &PRODUCT; Secure Boot description (3a45735)

fweimer at fedoraproject.org fweimer at fedoraproject.org
Wed Feb 13 17:07:20 UTC 2013 

Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git

On branch  : fweimer

>---------------------------------------------------------------

commit 3a457354f4f1f078d7d655daee1b0bb69a5b55b9
Author: Florian Weimer <fweimer at redhat.com>
Date:   Wed Feb 13 17:58:07 2013 +0100

    Reorganize &PRODUCT; Secure Boot description
    
    Do not duplicate information which is covered in the later section
    dealing with implementations details.


>---------------------------------------------------------------

 en-US/What_is_Secure_Boot.xml |   95 +++++++++++++++++++++++++++++------------
 1 files changed, 67 insertions(+), 28 deletions(-)

diff --git a/en-US/What_is_Secure_Boot.xml b/en-US/What_is_Secure_Boot.xml
index 3eb40c3..eed2357 100644
--- a/en-US/What_is_Secure_Boot.xml
+++ b/en-US/What_is_Secure_Boot.xml
@@ -410,40 +410,80 @@ AuthentiCode.
 </section>
 
 <section>
-<title>Fedora Secure Boot</title>
+<title>&PRODUCT; Secure Boot</title>
+<para>
+The &PRODUCT; Secure Boot implementation has a single security
+objective: it prevents the execution of unsigned code in kernel mode.
+</para>
+<para>
+&PRODUCT; can boot on systems with Microsoft Secure Boot enabled,
+provided the Microsoft certificate for third-party UEFI
+applications is installed.  This mode of operation is most
+important for installing &PRODUCT; on machines which have
+been prepared for Windows&nbsp;8.  Other hardware is not likely
+to provide a Microsoft Secure Boot environment.
+</para>
+<warning>
+<para>
+Third-party UEFI boot loaders (such as the &PRODUCT; boot loader) are
+not guaranteed to work on Microsoft Secure Boot systems because the
+necessary certificates are not part of the Microsoft Secure Boot
+specification.  If your hardware is in this category, you need to
+switch off UEFI Secure Boot, enroll the missing Microsoft certificate,
+or enroll the &PRODUCT; certificate.
+</para>
+</warning>
+<para>
+Some systems implement UEFI Secure Boot, but do not follow the
+Microsoft specification and use different certificates.  On such
+systems, it is possible to boot &PRODUCT; if the &PRODUCT;
+UEFI Secure Boot certificates have been installed before.  This needs
+a different first-stage boot loader.
+</para>
+<para>
+&PRODUCT; boots on UEFI systems which do not support or have disabled
+Secure Boot, too.  This works with all UEFI boot loaders.  These boot
+loaders also support running in an environment which performs boot
+path validation by other (non-UEFI) means.  In this mode, there are no
+restrictions on executing code in kernel mode.
+</para>
+<para>
+Details of the &PRODUCT; Secure Boot implementation are covered in
+<xref linkend="chap-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot"/>.
+Restrictions on kernel mode code execution disables certain
+functionality, see
+<xref linkend="sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Restrictions"/>.
+</para>
+</section>
 
-	<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.
-	</para>
-	<indexterm><primary>GRUB</primary></indexterm>
-	<indexterm><primary>shim</primary></indexterm>
-	<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>
 	<section id="sect-UEFI_Secure_Boot_Guide-What_is_Secure_Boot-Protect_you_from">
 		<title>What does Secure Boot protect you from?</title>
-		<para>
-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.
+<para>
+On the most basic level, UEFI Secure Boot prevents running unsigned
+boot loaders.  The effect of running the boot loader obviously depends
+on that boot loader.  The following refers to the &PRODUCT; implementation
+of Secure Boot.  The Microsoft implementation is different,
+see <xref linkend="sect-UEFI_Secure_Boot_Guide-What_is_Secure_Boot-Microsoft_Implementation"/>.
+</para>
+
+<para>
+&PRODUCT; has extended the chain of trust from the UEFI environment
+into the kernel.  Verification happens before loading kernel modules,
+but it does not extend to user space applications.  We can be certain
+that no unsigned executable code is present until the initial ramdisk
+(initrd) is loaded. Since initrd contents is not cryptographically
+signed and contains executable code, booting a signed &PRODUCT; boot
+loader can eventually lead to arbitrary effects.
+</para>
+<para>
+The &PRODUCT; Secure Boot implementation 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.
-Verification happens as far as only loading signed kernel modules, but it
-does not extend to user space applications. We can be certain that no
-unsigned executable code is present until the initial ramdisk (initrd) is loaded. Since
-initrd cannot currently be signed, it cannot be verified.
-		</para>
+configuration on disk.)
+</para>
 	</section>
         <section id="sect-UEFI_Secure_Boot_Guide-What_is_Secure_Boot-Risks">
                 <title>Potential Secure Boot Risks</title>
@@ -509,6 +549,5 @@ user interaction.
 			</para>
             </section>
         </section>
-</section>
 </chapter>

More information about the docs-commits mailing list