[system-administrators-guide/21] Change wrong entity to "Fedora"
stephenw
stephenw at fedoraproject.org
Thu Jan 15 21:47:13 UTC 2015
commit 5ed371de0c83e56fd5531d6f47db06076d732ef0
Author: Stephen Wadeley <swadeley at 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>
More information about the docs-commits
mailing list