commit d4e39f62f62da96face2f6641b6ba23bc11769ba
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Sat Dec 13 09:18:26 2014 +0100
Change wrong entity to "Fedora"
en-US/Working_with_Kernel_Modules.xml | 20 ++++++++++----------
1 files changed, 10 insertions(+), 10 deletions(-)
---
diff --git a/en-US/Working_with_Kernel_Modules.xml
b/en-US/Working_with_Kernel_Modules.xml
index 1af0060..214f01c 100644
--- a/en-US/Working_with_Kernel_Modules.xml
+++ b/en-US/Working_with_Kernel_Modules.xml
@@ -478,10 +478,10 @@ virtio-net</screen>
<section id="sect-signing-kernel-modules-for-secure-boot">
<title>Signing Kernel Modules for Secure Boot</title>
<para>
- &PRODUCT; includes support for the UEFI Secure Boot feature, which means that
&PRODUCT; can be installed and run on systems where UEFI Secure Boot is enabled.
<footnote><para>&PRODUCT; does not require the use of Secure Boot on UEFI
systems.</para></footnote> When Secure Boot is enabled, the EFI operating
system boot loaders, the &PRODUCT; kernel, and all kernel modules must be signed with
a private key and authenticated with the corresponding public key. The &PRODUCT;
distribution includes signed boot loaders, signed kernels, and signed kernel modules. In
addition, the signed first-stage boot loader and the signed kernel include embedded
&PRODUCT; public keys. These signed executable binaries and embedded keys enable
&PRODUCT; to install, boot, and run with the Microsoft UEFI Secure Boot CA keys that
are provided by the UEFI firmware on systems that support UEFI Secure
Boot.<footnote><para>Not all UEFI-based systems include support for Secure
Boot.</para></footnote>
+ Fedora includes support for the UEFI Secure Boot feature, which means that Fedora can
be installed and run on systems where UEFI Secure Boot is enabled.
<footnote><para>Fedora does not require the use of Secure Boot on UEFI
systems.</para></footnote> When Secure Boot is enabled, the EFI operating
system boot loaders, the Fedora kernel, and all kernel modules must be signed with a
private key and authenticated with the corresponding public key. The Fedora distribution
includes signed boot loaders, signed kernels, and signed kernel modules. In addition, the
signed first-stage boot loader and the signed kernel include embedded Fedora public keys.
These signed executable binaries and embedded keys enable Fedora to install, boot, and run
with the Microsoft UEFI Secure Boot CA keys that are provided by the UEFI firmware on
systems that support UEFI Secure Boot.<footnote><para>Not all UEFI-based
systems include support for Secure Boot.</para></footnote>
</para>
<para>
- The information provided in the following sections describes steps necessary to
enable you to self-sign privately built kernel modules for use with &PRODUCT; on
UEFI-based systems where Secure Boot is enabled. These sections also provide an overview
of available options for getting your public key onto the target system where you want to
deploy your kernel module.
+ The information provided in the following sections describes steps necessary to
enable you to self-sign privately built kernel modules for use with Fedora on UEFI-based
systems where Secure Boot is enabled. These sections also provide an overview of available
options for getting your public key onto the target system where you want to deploy your
kernel module.
</para>
<section id="sect-prerequisites">
@@ -544,7 +544,7 @@ virtio-net</screen>
<section id="sect-kernel-module-authentication">
<title>Kernel Module Authentication</title>
<para>
- In &PRODUCT;, when a kernel module is loaded, the module's signature is
checked using the public X.509 keys on the kernel's system key ring, excluding those
keys that are on the kernel's system black list key ring.
+ In Fedora, when a kernel module is loaded, the module's signature is checked
using the public X.509 keys on the kernel's system key ring, excluding those keys that
are on the kernel's system black list key ring.
</para>
<section
id="sect-sources-for-public-keys-used-to-authenticate-kernel-modules">
@@ -618,13 +618,13 @@ virtio-net</screen>
Note that if the system is not UEFI-based or if UEFI Secure Boot is not enabled,
then only the keys that are embedded in the kernel are loaded onto the system key ring and
you have no ability to augment that set of keys without rebuilding the kernel. The system
black list key ring is a list of X.509 keys which have been revoked. If your module is
signed by a key on the black list then it will fail authentication even if your public key
is in the system key ring.
</para>
<para>
- You can display information about the keys on the system key rings using the
<command>keyctl</command> utility. The following is abbreviated example output
from a &PRODUCT; system where UEFI Secure Boot is not enabled.
+ You can display information about the keys on the system key rings using the
<command>keyctl</command> utility. The following is abbreviated example output
from a Fedora system where UEFI Secure Boot is not enabled.
</para>
<screen>~]# <command>keyctl list %:.system_keyring</command>
1 key in keyring:
61139991: ---lswrv 0 0 asymmetric: Fedora kernel signing key:
1fc9e68f7419556348fdee2fdeb7ff9da6337b</screen>
<para>
- The following is abbreviated example output from a &PRODUCT; system where UEFI
Secure Boot is enabled.
+ The following is abbreviated example output from a Fedora system where UEFI Secure
Boot is enabled.
</para>
<screen>~]# <command>keyctl list %:.system_keyring</command>
6 keys in keyring:
@@ -743,7 +743,7 @@ virtio-net</screen>
<procedure>
<step>
<para>
- The <command>openssl</command> tool can be used to generate a key pair
that satisfies the requirements for kernel module signing in &PRODUCT;. Some of the
parameters for this key generation request are best specified with a configuration file;
follow the example below to create your own configuration file.</para>
+ The <command>openssl</command> tool can be used to generate a key pair
that satisfies the requirements for kernel module signing in Fedora. Some of the
parameters for this key generation request are best specified with a configuration file;
follow the example below to create your own configuration file.</para>
<screen>~]# <command>cat << EOF >
<replaceable>configuration_file</replaceable>.config</command>
[ req ]
default_bits = 4096
@@ -789,7 +789,7 @@ EOF</screen>
<section
id="sect-enrolling-public-key-on-target-system"><title>Enrolling Public
Key on Target System</title>
<para>
- When &PRODUCT; boots on a UEFI-based system with Secure Boot enabled, all keys
that are in the Secure Boot db key database, but not in the dbx database of revoked keys,
are loaded onto the system keyring by the kernel. The system keyring is used to
authenticate kernel modules.
+ When Fedora boots on a UEFI-based system with Secure Boot enabled, all keys that are
in the Secure Boot db key database, but not in the dbx database of revoked keys, are
loaded onto the system keyring by the kernel. The system keyring is used to authenticate
kernel modules.
</para>
<section
id="sect-factory-firmware-image-including-public-key"><title>Factory
Firmware Image Including Public Key</title>
<para>
@@ -801,7 +801,7 @@ EOF</screen>
It is possible to add a key to an existing populated and active Secure Boot key
database. This can be done by writing and providing an EFI executable
<emphasis>enrollment</emphasis> image. Such an enrollment image contains a
properly formed request to append a key to the Secure Boot key database. This request must
include data that is properly signed by the private key that corresponds to a public key
that is already in the system's Secure Boot Key Exchange Key (KEK) database.
Additionally, this EFI image must be signed by a private key that corresponds to a public
key that is already in the key database.
</para>
<para>
- It is also possible to write an enrollment image that runs under &PRODUCT;.
However, the &PRODUCT; image must be properly signed by a private key that corresponds
to a public key that is already in the KEK database.
+ It is also possible to write an enrollment image that runs under Fedora. However,
the Fedora image must be properly signed by a private key that corresponds to a public key
that is already in the KEK database.
</para>
<para>
The construction of either type of key enrollment images requires assistance from
the platform vendor.
@@ -809,7 +809,7 @@ EOF</screen>
</section>
<section
id="sect-system-administrator-manually-adding-public-key-to-the-mok-list"><title>System
Administrator Manually Adding Public Key to the MOK List</title>
<para>
- The Machine Owner Key (MOK) facility is a feature that is supported by
&PRODUCT; and can be used to augment the UEFI Secure Boot key database. When
&PRODUCT; boots on a UEFI-enabled system with Secure Boot enabled, the keys on the MOK
list are also added to the system keyring in addition to the keys from the key database.
The MOK list keys are also stored persistently and securely in the same fashion as the
Secure Boot key database keys, but these are two separate facilities. The MOK facility is
supported by shim.efi, MokManager.efi, grubx64.efi, and the &PRODUCT;
<command>mokutil</command> utility.
+ The Machine Owner Key (MOK) facility is a feature that is supported by Fedora and
can be used to augment the UEFI Secure Boot key database. When Fedora boots on a
UEFI-enabled system with Secure Boot enabled, the keys on the MOK list are also added to
the system keyring in addition to the keys from the key database. The MOK list keys are
also stored persistently and securely in the same fashion as the Secure Boot key database
keys, but these are two separate facilities. The MOK facility is supported by shim.efi,
MokManager.efi, grubx64.efi, and the Fedora <command>mokutil</command>
utility.
</para>
<para>
The major capability provided by the MOK facility is the ability to add public keys
to the MOK list without needing to have the key chain back to another key that is already
in the KEK database. However, enrolling a MOK key requires manual interaction by a
<emphasis>physically present</emphasis> user at the UEFI system console on
each target system. Nevertheless, the MOK facility provides an excellent method for
testing newly generated key pairs and testing kernel modules signed with them.
@@ -820,7 +820,7 @@ EOF</screen>
<procedure>
<step>
<para>
- Request addition of your public key to the MOK list using a &PRODUCT;
userspace utility:
+ Request addition of your public key to the MOK list using a Fedora userspace
utility:
</para>
<screen>~]# <command>mokutil <option>--import</option>
<filename>my_signing_key_pub.der</filename></command></screen>
<para>