[uefi-secure-boot-guide] master: Updated content per BZ 891758 (33f500e)

sparks at fedorahosted.org sparks at fedorahosted.org
Fri Jan 4 18:20:17 UTC 2013


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

On branch  : master

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

commit 33f500e08a776d3a1bc1cb506f8b2132a036c84d
Author: Eric Christensen <sparks at fedoraproject.org>
Date:   Fri Jan 4 12:58:15 2013 -0500

    Updated content per BZ 891758


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

 en-US/What_is_Secure_Boot.xml |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/en-US/What_is_Secure_Boot.xml b/en-US/What_is_Secure_Boot.xml
index c53c405..85b7037 100644
--- a/en-US/What_is_Secure_Boot.xml
+++ b/en-US/What_is_Secure_Boot.xml
@@ -6,17 +6,23 @@
 <chapter id="chap-UEFI_Secure_Boot_Guide-What_is_Secure_Boot">
 	<title>What is UEFI Secure Boot?</title>
 	<para>
-		Secure boot is a setup using UEFI firmware to check cryptographic signatures on the bootloader and associated OS kernel to ensure they have not been tampered with or bypassed in the boot process.  With the planned release of Windows 8, Microsoft has decided that all hardware that is marked "Windows 8 client ready" should:
+		Secure Boot is a setup using UEFI firmware to check cryptographic signatures on the bootloader and associated OS kernel to ensure that only trusted OS 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.
 		<simplelist>
 			<member>Have secure boot enabled by default.</member>
 			<member>Allow a physically present user to disable secure boot in the firmware interface.</member>
-			<member>Ship the Microsoft keys in firmware.</member>
+			<member>Ship the Microsoft key in firmware.</member>
 			<member>Allow a physically present user to enroll their own keys in the firmware interface.</member>
 		</simplelist>
-		This means that Fedora as it stands booted on such hardware will refuse to boot until the user disables secure boot in the firmware.
+	This means that Fedora versions before Fedora 18 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>
 	<para>
-		Maintainers of the grub2, kernel and associated packages have proposed a plan where by Fedora will have Verisign (via Microsoft) sign a bootloader shim that will in turn boot grub2 (signed by a Fedora key) and the Fedora kernel (signed by a Fedora key) to allow out of the box booting on secure boot enabled hardware. Additionally, they will provide tools and information for users to create their own keys and sign their own copy of boot shim and grub2 and kernel (and whatever else they wish to sign). This plan has been approved by the Fedora Engineering Steering Committee as of 23-Jul-2012.
+	To facilitate out of the box functionality on new hardware, the maintainers of the grub2, kernel and associated packages have implemented Secure Boot support in Fedora 18.  On UEFI machines, Fedora 18 uses a small bootloader called "shim" 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 grub2, which is signed by a Fedora key.  Grub2 then boots a similarly signed Linux kernel provided by Fedora which loads the rest of the OS as per the usual boot process.  The machine remains in Secure Boot mode.
+	</para>
+	<para>
+	Additional tools and information will provided for users to create their own keys and sign their own copy of shim and grub2 and kernel. 
+	</para>
+	<para>
+	This plan was approved by the Fedora Engineering Steering Committee on 23-Jul-2012.
 	</para>
 </chapter>
 



More information about the docs-commits mailing list