[uefi-secure-boot-guide] master: Add notes about the implementation (shim, keys, and a note about the key expiration) (11756fa)

[sparks at fedoraproject.org]

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

On branch  : master

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

commit 11756faedb9c658e4afd5259720b9b4201542c64
Author: Josh Bressers <josh at bress.net>
Date:   Thu Jan 31 10:10:38 2013 -0600

    Add notes about the implementation (shim, keys, and a note about the key
    expiration)


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

 en-US/Implementation_of_Secure_Boot.xml |   60 ++++++++++++++++++++++++++----
 1 files changed, 52 insertions(+), 8 deletions(-)

diff --git a/en-US/Implementation_of_Secure_Boot.xml b/en-US/Implementation_of_Secure_Boot.xml
index 013cb7a..757f7ff 100644
--- a/en-US/Implementation_of_Secure_Boot.xml
+++ b/en-US/Implementation_of_Secure_Boot.xml
@@ -8,15 +8,44 @@
 	<para>
 	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>
-	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:
+	<section id="sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Keys">
+		<title>The Keys</title>
+		<para>
+		The solution to use the Microsoft signing service was one of
+simplicity. The key Microsoft uses is shipped on all known hardware, which
+should result in Fedora being able to boot on this hardware without issue.
+There are fo course risks having to rely on a third party for this service.
+Fedora is committed to closely watching activity in this space and will
+respond to any new information appropriately.
+		</para>
+	</section>
+	<section id="sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Shim">
+		<title>The Shim</title>
+		<para>
+		The shim package also contains a blacklist of known bad keys or
+binaries that should not be allowed to boot. Microsoft will provide this
+list to Fedora for inclusion. This may create periodic update to the
+shim-signed package that do not change the actual shim binary, but will
+update the blacklist to ensure known bad code cannot be executed.
+		</para>
+		<para>
+		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>
 		</simplelist>
-	</para>
-	<para>
+		</para>
+	</section>
+	<section id="sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Restrictions">
+		<title>Restrictions</title>
+		<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>
@@ -24,14 +53,29 @@
 			<member>third party modules that are unsigned, or signed with an unknown key</member>
 			<member>systemtap kernel probing (and kprobes)</member>
 		</simplelist>
-	</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>
+		</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. If you require support of any of these featurs, Secure Boot must
+be disabled.
+		</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>
+	<important>
+		<title>Important</title>
+		<para>
+		Currently, the Fedora shim was signed in a way that gives it an
+expiration date of October 2013, prior to the Fedora 18 end-of-life. We are
+not aware of any hardware that honors this expiration date, but it's not
+out of the question. This is the date Microsoft gave the signature, Fedora
+has no control over it. We are investigating this issue and expect to
+resolve it in the future.
+		</para>
+	</important>
+	</section>
 </chapter>