[uefi-secure-boot-guide] master: Added DocBook tags (9a45ffa)
sparks at fedoraproject.org
sparks at fedoraproject.org
Fri Feb 1 23:41:35 UTC 2013
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit 9a45ffae24a32f3baedaeb6dbc30d46c0137a4ed
Author: Eric Christensen <sparks at fedoraproject.org>
Date: Fri Feb 1 18:40:39 2013 -0500
Added DocBook tags
>---------------------------------------------------------------
en-US/Implementation_of_Secure_Boot.xml | 26 +++++++++++++++++++++-----
en-US/Tools.xml | 6 ++++--
en-US/What_is_Secure_Boot.xml | 6 ++++--
3 files changed, 29 insertions(+), 9 deletions(-)
diff --git a/en-US/Implementation_of_Secure_Boot.xml b/en-US/Implementation_of_Secure_Boot.xml
index 492065d..84c92cc 100644
--- a/en-US/Implementation_of_Secure_Boot.xml
+++ b/en-US/Implementation_of_Secure_Boot.xml
@@ -5,11 +5,13 @@
]>
<chapter id="chap-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot">
<title>UEFI Secure Boot Implementation</title>
+ <indexterm><primary>Secure Boot</primary><secondary>implementation</secondary></indexterm>
<para>
The &PRODUCT; 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>
<section id="sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Keys">
- <title>The Keys</title>
+ <title>Keys</title>
+ <indexterm><primary>Secure Boot</primary><secondary>keys</secondary></indexterm>
<para>
The solution to use the Microsoft signing service was one of
simplicity. The key Microsoft uses is shipped on all known hardware, which
@@ -23,15 +25,21 @@ respond to any new information appropriately.
to its complexity. Here is how the various components are signed.
</para>
<para>
+ <indexterm><primary>shim</primary><secondary>key</secondary></indexterm>
+ <indexterm><primary>keys</primary><secondary>shim</secondary></indexterm>
Shim: This is signed by the UEFI signing service. We do not have
control over this key. The shim contains the Fedora Boot CA public key.
</para>
<para>
+ <indexterm><primary>GRUB</primary><secondary>key</secondary></indexterm>
+ <indexterm><primary>keys</primary><secondary>GRUB</secondary></indexterm>
GRUB: This is signed by the "Fedora Boot Signer" key, which chains
off the Fedora Boot CA key. GRUB doesn't contain any keys, it calls into
shim for its verification.
</para>
<para>
+ <indexterm><primary>kernel</primary><secondary>key</secondary></indexterm>
+ <indexterm><primary>keys</primary><secondary>kernel</secondary></indexterm>
Kernel: This is also signed by the Fedora Boot Signer. The kernel
contains the public key used to sign kernel modules.
</para>
@@ -41,7 +49,11 @@ during build. This key is not saved, a new key is used with each kernel
build.
</para>
<para>
- The Fedora Boot CA is used to verify the
+ <indexterm><primary>&PRODUCT; Secure Boot CA</primary></indexterm>
+ <indexterm><primary>keys</primary><secondary>&PRODUCT; Secure Boot CA</secondary><tertiary>public key</tertiary></indexterm>
+ <indexterm><primary>GRUB</primary><secondary>integrity</secondary></indexterm>
+ <indexterm><primary>kernel</primary><secondary>integrity</secondary></indexterm>
+ The &PRODUCT; Secure Boot CA is used to verify the
integrity of GRUB and the kernel. The public key can currently be found in the
shim source package. The details of the key are:
<screen>
@@ -112,6 +124,7 @@ URI:https://fedoraproject.org/wiki/Features/SecureBoot
<section id="sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Shim">
<title>Shim</title>
<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 that makes
up shim. This package will not boot the system as it is not signed. The
@@ -120,7 +133,7 @@ shim-signed package. The shim-signed package contains the signed binary
that is capable of booting the system.
</para>
<para>
- The shim package also contains a blacklist of known bad keys or
+ The shim package also contains a <indexterm><primary>Secure Boot</primary><secondary>blacklist</secondary></indexterm>blacklist of known bad keys or
binaries that should not be allowed to boot. Thie blacklist is a file
called dbx.esl in the shim-signed package. Microsoft will provide this list
to &PROJECT; for inclusion. This may create periodic updates to the
@@ -156,7 +169,7 @@ in Secure Boot mode, which will cause several things to be true:
</section>
<section id="sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Restrictions">
<title>Restrictions</title>
- <para>
+ <para><indexterm><primary>Secure Boot</primary><secondary>restrictions</secondary></indexterm>
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>
@@ -165,15 +178,18 @@ in Secure Boot mode, which will cause several things to be true:
<member>systemtap kernel probing (and kprobes)</member>
</simplelist>
</para>
+ <note>
+ <title>Note</title>
<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 features, Secure Boot must
be disabled.
</para>
+ </note>
<important>
<title>Important</title>
- <para>
+ <para><indexterm><primary>keys</primary><secondary>expiration</secondary><tertiary>Fedora 18</tertiary></indexterm>
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
diff --git a/en-US/Tools.xml b/en-US/Tools.xml
index dd567b4..8f55047 100644
--- a/en-US/Tools.xml
+++ b/en-US/Tools.xml
@@ -11,23 +11,25 @@
<section id="sect-UEFI_Secure_Boot_Guide-Tools-shim">
<title>Shim</title>
<para>
- Shim is the cryptographically signed software that creates the trust between the UEFI firmware and GRUB and the kernel software. Shim is cryptographically signed by Verisign (via Microsoft) so that the UEFI firmware will cryptographically recognize the &PRODUCT; system and allow the software to continue through the boot process. The shim validates GRUB and kernel through a cryptographic verification based on a &PRODUCT; key used to sign all three.
+ <indexterm><primary>shim</primary><secondary>definition</secondary></indexterm>Shim is the cryptographically signed software that creates the trust between the UEFI firmware and GRUB and the kernel software. Shim is cryptographically signed by Verisign (via Microsoft) so that the UEFI firmware will cryptographically recognize the &PRODUCT; system and allow the software to continue through the boot process. The shim validates GRUB and kernel through a cryptographic verification based on a &PRODUCT; key used to sign all three.
</para>
</section>
<section id="sect-UEFI_Secure_Boot_Guide-Tools-pesign">
<title>Pesign</title>
<para>
- <firstterm>Pesign</firstterm> allows users to create their own shim and use their own cryptographic keys. Using this tool, one can create their own trust model and not be required to trust the Microsoft trust model. Once the user has created their keys and signed their shim, and optionally signed and built GRUB and kernel, they can use the setup mode in the firmware to install &PRODUCT; and use the <firstterm>sbsetup</firstterm> tool as provided by pesign to enroll their keys in the firmware.
+ <indexterm><primary>pesign</primary><secondary>definition</secondary></indexterm><firstterm>Pesign</firstterm> allows users to create their own shim and use their own cryptographic keys. Using this tool, one can create their own trust model and not be required to trust the Microsoft trust model. Once the user has created their keys and signed their shim, and optionally signed and built GRUB and kernel, they can use the setup mode in the firmware to install &PRODUCT; and use the <indexterm><primary>pesign</primary><secondary>sbsetup</secondary></indexterm><firstterm>sbsetup</firstterm> tool as provided by pesign to enroll their keys in the firmware.
</para>
</section>
<section id="sect-UEFI_Secure_Boot_Guide-Tools-efikeygen">
<title>EFIKeyGen</title>
<para>
+ <indexterm><primary>EFIKeyGen</primary><secondary>definition</secondary></indexterm>
</para>
</section>
<section id="sect-UEFI_Secure_Boot_Guide-Tools-sign_file">
<title>sign-file</title>
<para>
+ <indexterm><primary>sign-file</primary><secondary>definition</secondary></indexterm>
</para>
</section>
diff --git a/en-US/What_is_Secure_Boot.xml b/en-US/What_is_Secure_Boot.xml
index 9b720c3..10d5a3d 100644
--- a/en-US/What_is_Secure_Boot.xml
+++ b/en-US/What_is_Secure_Boot.xml
@@ -6,13 +6,15 @@
<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 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 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.
</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.
</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 GRUB, kernel and associated packages have implemented Secure Boot support in &PRODUCT;. On UEFI machines, &PRODUCT; 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 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.
+ 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>
More information about the docs-commits
mailing list