[uefi-secure-boot-guide] master: Made some editing and spelling changes (0ab487b)
by Eric Christensen
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit 0ab487b3c4f0491c6dd4bd9e7109529c17ce804a
Author: Eric Christensen <sparks(a)fedoraproject.org>
Date: Fri Feb 1 17:49:43 2013 -0500
Made some editing and spelling changes
>---------------------------------------------------------------
en-US/Tools.xml | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/en-US/Tools.xml b/en-US/Tools.xml
index c9d6854..dd567b4 100644
--- a/en-US/Tools.xml
+++ b/en-US/Tools.xml
@@ -6,18 +6,18 @@
<chapter id="chap-UEFI_Secure_Boot_Guide-Tools">
<title>Tools</title>
<para>
- Several tools have been developed to allow &PRODUCT; work with the UEFI Secure Boot firmware.
+ Several tools have been developed to allow &PRODUCT; to work with the UEFI Secure Boot firmware.
</para>
<section id="sect-UEFI_Secure_Boot_Guide-Tools-shim">
<title>Shim</title>
<para>
- <firstterm>Shim</firstterm> 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 though a cryptographic verification based on a &PRODUCT; key used to sign all three.
+ 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>
+ <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 keys and 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.
+ <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.
</para>
</section>
<section id="sect-UEFI_Secure_Boot_Guide-Tools-efikeygen">
11 years, 3 months
[uefi-secure-boot-guide] master: Made some editing and spelling changes (ff4436b)
by Eric Christensen
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit ff4436b9a7e08ffe800a1cc971157234e8bdbd03
Author: Eric Christensen <sparks(a)fedoraproject.org>
Date: Fri Feb 1 17:45:52 2013 -0500
Made some editing and spelling changes
>---------------------------------------------------------------
en-US/Implementation_of_Secure_Boot.xml | 28 ++++++++++++++--------------
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/en-US/Implementation_of_Secure_Boot.xml b/en-US/Implementation_of_Secure_Boot.xml
index 4998d6c..492065d 100644
--- a/en-US/Implementation_of_Secure_Boot.xml
+++ b/en-US/Implementation_of_Secure_Boot.xml
@@ -41,8 +41,8 @@ during build. This key is not saved, a new key is used with each kernel
build.
</para>
<para>
- The Fedora Boot CA which is used to verify the
-integrity of GRUB and the kernel. This key can currently be found in the
+ The Fedora 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>
Certificate:
@@ -110,20 +110,20 @@ URI:https://fedoraproject.org/wiki/Features/SecureBoot
</para>
</section>
<section id="sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Shim">
- <title>The Shim</title>
+ <title>Shim</title>
<para>
- In &PRODUCT; there are two packages that make up the shim. The
+ 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 the shim. This package will not boot the system as it is not signed. The
+up shim. This package will not boot the system as it is not signed. The
results of building the shim package are signed, then incorporated into the
-shim-signed package. The shim-signed package contians the signed binary
+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
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 update to the
+to &PROJECT; for inclusion. This may create periodic updates 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>
@@ -138,7 +138,7 @@ being used for attacks from executing.
In both boot methods, shim, GRUB, 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
-&PRODUCT;-specific cryptographic public key before starting it. The validation
+&PRODUCT;-specific cryptographic public key before starting. The validation
is done via shim for GRUB, and GRUB 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:
@@ -148,6 +148,11 @@ in Secure Boot mode, which will cause several things to be true:
<member>it will refuse any operations from userland which cause userland-defined DMA.</member>
</simplelist>
</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>
</section>
<section id="sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Restrictions">
<title>Restrictions</title>
@@ -163,14 +168,9 @@ in Secure Boot mode, which will cause several things to be true:
<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
+timeframe. If you require support of any of these features, 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>
11 years, 3 months
[uefi-secure-boot-guide] master: Fixed spelling error (74025b2)
by Eric Christensen
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit 74025b276cda26547f959cbd11f6b83cafebc824
Author: Eric Christensen <sparks(a)fedoraproject.org>
Date: Fri Feb 1 17:36:36 2013 -0500
Fixed spelling error
>---------------------------------------------------------------
en-US/Implementation_of_Secure_Boot.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/en-US/Implementation_of_Secure_Boot.xml b/en-US/Implementation_of_Secure_Boot.xml
index bceb9fe..4998d6c 100644
--- a/en-US/Implementation_of_Secure_Boot.xml
+++ b/en-US/Implementation_of_Secure_Boot.xml
@@ -33,7 +33,7 @@ shim for its verification.
</para>
<para>
Kernel: This is also signed by the Fedora Boot Signer. The kernel
-contains the public key used to sign kerenl modules.
+contains the public key used to sign kernel modules.
</para>
<para>
Kernel Modules: These are signed with a private key generated
11 years, 3 months
[uefi-secure-boot-guide] master: Changed grub2 to GRUB (178e528)
by Eric Christensen
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit 178e52899a2b24b810f5d76185674470be11c4e2
Author: Eric Christensen <sparks(a)fedoraproject.org>
Date: Fri Feb 1 17:28:32 2013 -0500
Changed grub2 to GRUB
>---------------------------------------------------------------
en-US/Implementation_of_Secure_Boot.xml | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/en-US/Implementation_of_Secure_Boot.xml b/en-US/Implementation_of_Secure_Boot.xml
index 80c70ed..bceb9fe 100644
--- a/en-US/Implementation_of_Secure_Boot.xml
+++ b/en-US/Implementation_of_Secure_Boot.xml
@@ -27,8 +27,8 @@ to its complexity. Here is how the various components are signed.
control over this key. The shim contains the Fedora Boot CA public key.
</para>
<para>
- Grub2: This is signed by the "Fedora Boot Signer" key, which chains
-off the Fedora Boot CA key. Grub2 doesn't contain any keys, it calls into
+ 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>
@@ -42,7 +42,7 @@ build.
</para>
<para>
The Fedora Boot CA which is used to verify the
-integrity of grub2 and the kernel. This key can currently be found in the
+integrity of GRUB and the kernel. This key can currently be found in the
shim source package. The details of the key are:
<screen>
Certificate:
@@ -135,11 +135,11 @@ Microsoft has stated that the blacklist is to be used to prevent binaries
being used for attacks from executing.
</para>
<para>
- In both boot methods, shim, grub2, and the kernel will detect that they
+ In both boot methods, shim, GRUB, 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
&PRODUCT;-specific cryptographic public key before starting it. The validation
-is done via shim for grub2, and grub2 calls back to shim to validate the
+is done via shim for GRUB, and GRUB 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>
11 years, 3 months
[uefi-secure-boot-guide] master: Changed the title of the chapter to reduce the length for rendering (670e38f)
by Eric Christensen
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit 670e38f70985654e5bd5080c14ce0853a0673c68
Author: Eric Christensen <sparks(a)fedoraproject.org>
Date: Fri Feb 1 17:10:24 2013 -0500
Changed the title of the chapter to reduce the length for rendering
>---------------------------------------------------------------
en-US/Implementation_of_Secure_Boot.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/en-US/Implementation_of_Secure_Boot.xml b/en-US/Implementation_of_Secure_Boot.xml
index 4365fd3..80c70ed 100644
--- a/en-US/Implementation_of_Secure_Boot.xml
+++ b/en-US/Implementation_of_Secure_Boot.xml
@@ -4,7 +4,7 @@
%BOOK_ENTITIES;
]>
<chapter id="chap-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot">
- <title>&PRODUCT;'s Implementation of UEFI Secure Boot</title>
+ <title>UEFI Secure Boot Implementation</title>
<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>
11 years, 3 months
[uefi-secure-boot-guide] master: Fixed 'grub's and rewrote the scope sentence again (d9fe09f)
by Eric Christensen
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit d9fe09fbc5c3a5b7da6dd3f4eb12ebc7f371617d
Author: Eric Christensen <sparks(a)fedoraproject.org>
Date: Fri Feb 1 17:06:42 2013 -0500
Fixed 'grub's and rewrote the scope sentence again
>---------------------------------------------------------------
en-US/What_is_Secure_Boot.xml | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/en-US/What_is_Secure_Boot.xml b/en-US/What_is_Secure_Boot.xml
index 95de533..9b720c3 100644
--- a/en-US/What_is_Secure_Boot.xml
+++ b/en-US/What_is_Secure_Boot.xml
@@ -12,7 +12,7 @@
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>
<para>
- 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 &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 grub2, which is signed by a &PRODUCT; key. Grub2 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 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.
</para>
<section id="sect-UEFI_Secure_Boot_Guide-What_is_Secure_Boot-Protect_you_from">
<title>What does Secure Boot protect you from?</title>
@@ -21,8 +21,7 @@
a system. The goal is to prevent untrusted code from booting the system,
once that part has been verified, it's up to the operating system to take
over protection. This does give the potential for the operating system to
-extend this chain of trust down into user binaries, but that moves us
-outside of the concept of Secure Boot and into another topic.
+extend this chain of trust down into user binaries, but that is beyond the scope of this document.
</para>
<para>
&PRODUCT; has expanded the chain of trust into the kernel.
11 years, 3 months
[uefi-secure-boot-guide] master: Removed merge marks (02cc559)
by Eric Christensen
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit 02cc55975a5a744b3221d8f53c01e43bbf89580b
Author: Eric Christensen <sparks(a)fedoraproject.org>
Date: Fri Feb 1 17:03:47 2013 -0500
Removed merge marks
>---------------------------------------------------------------
en-US/Implementation_of_Secure_Boot.xml | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/en-US/Implementation_of_Secure_Boot.xml b/en-US/Implementation_of_Secure_Boot.xml
index 1ca8378..4365fd3 100644
--- a/en-US/Implementation_of_Secure_Boot.xml
+++ b/en-US/Implementation_of_Secure_Boot.xml
@@ -37,11 +37,7 @@ contains the public key used to sign kerenl modules.
</para>
<para>
Kernel Modules: These are signed with a private key generated
-<<<<<<< HEAD
-during build. This key is not saved, a new key is used with each Kernel
-=======
during build. This key is not saved, a new key is used with each kernel
->>>>>>> bressers
build.
</para>
<para>
11 years, 3 months
[uefi-secure-boot-guide] master: Adding additional text to Implementation and What is... (60a7cc1)
by Eric Christensen
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit 60a7cc1b80d4c785d5b394acac74dc8d20d2d4a5
Merge: ca5d73c 437ecf9
Author: Eric Christensen <sparks(a)fedoraproject.org>
Date: Fri Feb 1 16:45:04 2013 -0500
Adding additional text to Implementation and What is...
>---------------------------------------------------------------
en-US/Implementation_of_Secure_Boot.xml | 4 ++++
en-US/What_is_Secure_Boot.xml | 11 +----------
2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/en-US/Implementation_of_Secure_Boot.xml b/en-US/Implementation_of_Secure_Boot.xml
index 06e2463..1ca8378 100644
--- a/en-US/Implementation_of_Secure_Boot.xml
+++ b/en-US/Implementation_of_Secure_Boot.xml
@@ -37,7 +37,11 @@ contains the public key used to sign kerenl modules.
</para>
<para>
Kernel Modules: These are signed with a private key generated
+<<<<<<< HEAD
during build. This key is not saved, a new key is used with each Kernel
+=======
+during build. This key is not saved, a new key is used with each kernel
+>>>>>>> bressers
build.
</para>
<para>
diff --git a/en-US/What_is_Secure_Boot.xml b/en-US/What_is_Secure_Boot.xml
index f04666a..95de533 100644
--- a/en-US/What_is_Secure_Boot.xml
+++ b/en-US/What_is_Secure_Boot.xml
@@ -25,7 +25,7 @@ extend this chain of trust down into user binaries, but that moves us
outside of the concept of Secure Boot and into another topic.
</para>
<para>
- &PRODUCT; has expanded the chain of trust into the Kernel.
+ &PRODUCT; has expanded the chain of trust into the kernel.
Verification happens as far as only loading signed kernel modules, but it
does not extend to user space applications. We can be certain that no
unsigned executable code is present until the initial ramdisk (initrd) is loaded. Since
@@ -42,15 +42,6 @@ restricted, but user space malware cannot. This of course doesn't mean
Secure Boot isn't useful, just that it currently only serves a single
purpose, which is protecting the boot loader.
</para>
- <note>
- <title>Do not disable secure boot</title>
- <para>
- It is important you do not disable Secure Boot if
-your system fails to boot. A plausible attack would be replacing the shim
-with something dangerous and hoping a user will disable Secure Boot to
-solve their problem.
- </para>
- </note>
</section>
</chapter>
11 years, 3 months
[uefi-secure-boot-guide] master: Fix kerenel capitilization (437ecf9)
by Eric Christensen
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit 437ecf9bf7d521e4e73f9a8e38ad43c6a1f80176
Author: Josh Bressers <josh(a)bress.net>
Date: Fri Feb 1 10:57:11 2013 -0600
Fix kerenel capitilization
>---------------------------------------------------------------
en-US/Implementation_of_Secure_Boot.xml | 2 +-
en-US/What_is_Secure_Boot.xml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/en-US/Implementation_of_Secure_Boot.xml b/en-US/Implementation_of_Secure_Boot.xml
index 06e2463..4365fd3 100644
--- a/en-US/Implementation_of_Secure_Boot.xml
+++ b/en-US/Implementation_of_Secure_Boot.xml
@@ -37,7 +37,7 @@ contains the public key used to sign kerenl modules.
</para>
<para>
Kernel Modules: These are signed with a private key generated
-during build. This key is not saved, a new key is used with each Kernel
+during build. This key is not saved, a new key is used with each kernel
build.
</para>
<para>
diff --git a/en-US/What_is_Secure_Boot.xml b/en-US/What_is_Secure_Boot.xml
index b13206e..95de533 100644
--- a/en-US/What_is_Secure_Boot.xml
+++ b/en-US/What_is_Secure_Boot.xml
@@ -25,7 +25,7 @@ extend this chain of trust down into user binaries, but that moves us
outside of the concept of Secure Boot and into another topic.
</para>
<para>
- &PRODUCT; has expanded the chain of trust into the Kernel.
+ &PRODUCT; has expanded the chain of trust into the kernel.
Verification happens as far as only loading signed kernel modules, but it
does not extend to user space applications. We can be certain that no
unsigned executable code is present until the initial ramdisk (initrd) is loaded. Since
11 years, 3 months
[uefi-secure-boot-guide] master: Remove a confusing note. (847e195)
by Eric Christensen
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit 847e195961c2a88a198ad73cfb73aa9b6de33a88
Author: Josh Bressers <josh(a)bress.net>
Date: Fri Feb 1 10:11:04 2013 -0600
Remove a confusing note.
>---------------------------------------------------------------
en-US/What_is_Secure_Boot.xml | 9 ---------
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/en-US/What_is_Secure_Boot.xml b/en-US/What_is_Secure_Boot.xml
index f04666a..b13206e 100644
--- a/en-US/What_is_Secure_Boot.xml
+++ b/en-US/What_is_Secure_Boot.xml
@@ -42,15 +42,6 @@ restricted, but user space malware cannot. This of course doesn't mean
Secure Boot isn't useful, just that it currently only serves a single
purpose, which is protecting the boot loader.
</para>
- <note>
- <title>Do not disable secure boot</title>
- <para>
- It is important you do not disable Secure Boot if
-your system fails to boot. A plausible attack would be replacing the shim
-with something dangerous and hoping a user will disable Secure Boot to
-solve their problem.
- </para>
- </note>
</section>
</chapter>
11 years, 3 months