Repository :
http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
---------------------------------------------------------------
commit 9a45ffae24a32f3baedaeb6dbc30d46c0137a4ed
Author: Eric Christensen <sparks(a)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>