[uefi-secure-boot-guide] master: Changes made per BZ 891924 (6abdb39)

[sparks at fedorahosted.org]

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

On branch  : master

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

commit 6abdb39f7dc7145062f732382b1967c45cc573be
Author: Eric Christensen <sparks at fedoraproject.org>
Date:   Fri Jan 4 13:13:56 2013 -0500

    Changes made per BZ 891924


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

 en-US/Implementation_of_Secure_Boot.xml |   24 ++++++++++++++++++++++--
 1 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/en-US/Implementation_of_Secure_Boot.xml b/en-US/Implementation_of_Secure_Boot.xml
index b60d1b8..024d4cf 100644
--- a/en-US/Implementation_of_Secure_Boot.xml
+++ b/en-US/Implementation_of_Secure_Boot.xml
@@ -6,10 +6,30 @@
 <chapter id="chap-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot">
 	<title>&PRODUCT;'s Implementation of UEFI Secure Boot</title>
 	<para>
-		Systems with UEFI Secure Boot enabled will ship with a set of vendor-determined keys installed in the firmware. These keys include the ability to boot from binaries signed by the signing service hosted by Microsoft. This feature includes simultaneous support for two methods of booting under this scheme. Under the first scheme, Fedora will utilize the signing service hosted by Microsoft. Under the second, a site will create their own keys and deploy them in system firmware, and will do their own signing of binaries with it. In both schemes, shim, grub2, and the kernel will detect that they are started in what UEFI describes as "User mode" with Secure Boot enabled, and upon detecting this they will validate the next stage with a Fedora-specific cryptographic public key before starting it. Additionally, grub2 will operate with similar restrictions as it would if you had set a supervisory password in your configuration. Once the kernel is booted, it will also detect that it is
  in Secure Boot mode, which will cause several things to be true: it will validate the boot command line to only allow certain kernel settings, it will check loaded modules for signatures and refuse to load them if they are unsigned, and it will refuse any operations from userland which cause userland-defined DMA.
+	The Fedora Secure Boot implementation includes support for two methods of booting under the Secure Boot mechanism.  The first method utilizes the signing service hosted by Microsoft to provide a copy of the shim bootloader signed with the Microsoft keys.  The second method is a more general form of the first, wherein a site or user can create their own keys, deploy them in system firmware, and sign their own binaries. 
 	</para>
 	<para>
-		Under this scheme, the signing service will be used to sign a first-stage bootloader, <ulink url="https://github.com/mjg59/shim">shim</ulink>, which holds a Fedora-specific public key. shim will then validate against the Fedora-defined key referenced above. 
+	In both methods, shim, grub2, and the kernel will detect that they are started in what UEFI describes as "User mode" with Secure Boot enabled, and upon detecting this they will validate the next stage with a Fedora-specific cryptographic public key before starting it. The validation is done via shim for grub2, and grub2 calls back to shim to validate the kernel as well.  Once the kernel is booted, it will also detect that it is in Secure Boot mode, which will cause several things to be true:
+		<simplelist>
+			<member>it will validate the boot command line to only allow certain kernel settings</member>
+			<member>it will check modules at load time for signatures and refuse to load them if they are unsigned or signed with a signature not found in the UEFI key store variables (see note)</member>
+			<member>it will refuse any operations from userland which cause userland-defined DMA.</member>
 	</para>
+	<para>
+	These restrictions are in place to be fully compliant with Secure Boot.  This requires us to prevent any execution of unverified code at the supervisor level.  Most users won't notice these restrictions as most of the userspace packages that required such access have been fixed to work without it.  However, there are a few services or features that will not work in a Secure Boot enabled machine at this time.  They include:
+		<simplelist>
+			<member>kexec/kdump</member>
+			<member>hibernate (suspend to disk)</member>
+			<member>third party modules that are unsigned, or signed with an unknown key</member>
+			<member>systemtap kernel probing (and kprobes)</member>
+	</para>
+	<para>
+	In future iterations of Secure Boot support the above may also be possible, however secure implementations were not feasible in the Fedora 18 timeframe.
+	</para>
+	<note>
+		<title>Note</title>
+		<para>Other distributions have chosen to not require signed kernel modules in their Secure Boot implementation.  Fedora believes that to fully support Secure Boot this is required.  We are working to limit the impacts of this while ensuring that untrusted module code is not allowed to execute.
+		</para>
+	</note>
 </chapter>