[uefi-secure-boot-guide] master: Add notes for each key. (4d20d45)
by Eric Christensen
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit 4d20d450c62c4eb2565680eabde7c143f70c4fbd
Author: Josh Bressers <josh(a)bress.net>
Date: Thu Jan 31 16:44:58 2013 -0600
Add notes for each key.
>---------------------------------------------------------------
en-US/Implementation_of_Secure_Boot.xml | 24 +++++++++++++++++++++++-
1 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/en-US/Implementation_of_Secure_Boot.xml b/en-US/Implementation_of_Secure_Boot.xml
index fc8646c..83e215a 100644
--- a/en-US/Implementation_of_Secure_Boot.xml
+++ b/en-US/Implementation_of_Secure_Boot.xml
@@ -19,7 +19,29 @@ There are of course risks having to rely on a third party for this service.
respond to any new information appropriately.
</para>
<para>
- Additionally, we have a Fedora Boot CA which is used to verify the
+ The key usage in the &PRODUCT; implementation can be confusing due
+to its complexity. Here is how the various components are signed.
+ </para>
+ <para>
+ 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>
+ 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
+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.
+ </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
+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
shim source package. The details of the key are:
<screen>
11 years, 3 months
[uefi-secure-boot-guide] master: Merge branch 'master' of git://git.fedorahosted.org/git/docs/uefi-secure-boot-guide into bressers (75d5407)
by Eric Christensen
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit 75d5407b2a62c52e320d81cab52779d45d84bdf9
Merge: 45c74e9 f5c1b2f
Author: Josh Bressers <josh(a)bress.net>
Date: Thu Jan 31 15:07:18 2013 -0600
Merge branch 'master' of git://git.fedorahosted.org/git/docs/uefi-secure-boot-guide into bressers
>---------------------------------------------------------------
en-US/Tools.xml | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/en-US/Tools.xml b/en-US/Tools.xml
index 47dfe06..c9d6854 100644
--- a/en-US/Tools.xml
+++ b/en-US/Tools.xml
@@ -11,11 +11,13 @@
<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.
</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 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.
</para>
</section>
<section id="sect-UEFI_Secure_Boot_Guide-Tools-efikeygen">
11 years, 3 months
[uefi-secure-boot-guide] master: Update blacklist info. (45c74e9)
by Eric Christensen
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit 45c74e9b8a43a274df07c8f05ad0934b0ddfd6af
Author: Josh Bressers <josh(a)bress.net>
Date: Thu Jan 31 15:06:35 2013 -0600
Update blacklist info.
>---------------------------------------------------------------
en-US/Implementation_of_Secure_Boot.xml | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/en-US/Implementation_of_Secure_Boot.xml b/en-US/Implementation_of_Secure_Boot.xml
index 1740fe5..fc8646c 100644
--- a/en-US/Implementation_of_Secure_Boot.xml
+++ b/en-US/Implementation_of_Secure_Boot.xml
@@ -99,12 +99,20 @@ 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. Microsoft will provide this
-list to &PROJECT; for inclusion. This may create periodic update to the
+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
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>
<para>
+ The details about the blacklist must come from Microsoft. We
+are not able to update this blacklist ourselves. The data is signed with a
+Microsoft key which will prevent unauthorized updates to this list.
+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
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
11 years, 3 months
[uefi-secure-boot-guide] master: Add notes about the shim. (ddc5e2b)
by Eric Christensen
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit ddc5e2bbd1fba9df7a20f78be974c0a1f643208d
Author: Josh Bressers <josh(a)bress.net>
Date: Thu Jan 31 14:48:23 2013 -0600
Add notes about the shim.
>---------------------------------------------------------------
en-US/Implementation_of_Secure_Boot.xml | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/en-US/Implementation_of_Secure_Boot.xml b/en-US/Implementation_of_Secure_Boot.xml
index 418ab28..1740fe5 100644
--- a/en-US/Implementation_of_Secure_Boot.xml
+++ b/en-US/Implementation_of_Secure_Boot.xml
@@ -90,6 +90,14 @@ URI:https://fedoraproject.org/wiki/Features/SecureBoot
<section id="sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Shim">
<title>The Shim</title>
<para>
+ In &PRODUCT; there are two packages that make up the 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
+results of building the shim package are signed, then incorporated into the
+shim-signed package. The shim-signed package contians 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. Microsoft will provide this
list to &PROJECT; for inclusion. This may create periodic update to the
11 years, 3 months
[uefi-secure-boot-guide] master: Add boot CA key info (d240a4d)
by Eric Christensen
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit d240a4da0783d69a208552deb9e015a218ce037d
Author: Josh Bressers <josh(a)bress.net>
Date: Thu Jan 31 14:42:33 2013 -0600
Add boot CA key info
>---------------------------------------------------------------
en-US/Implementation_of_Secure_Boot.xml | 70 ++++++++++++++++++++++++++++++-
1 files changed, 69 insertions(+), 1 deletions(-)
diff --git a/en-US/Implementation_of_Secure_Boot.xml b/en-US/Implementation_of_Secure_Boot.xml
index 4a52ca0..418ab28 100644
--- a/en-US/Implementation_of_Secure_Boot.xml
+++ b/en-US/Implementation_of_Secure_Boot.xml
@@ -18,6 +18,74 @@ There are of course risks having to rely on a third party for this service.
&PROJECT; is committed to closely watching activity in this space and will
respond to any new information appropriately.
</para>
+ <para>
+ Additionally, we have a Fedora Boot CA which is used to verify the
+integrity of grub2 and the kernel. This key can currently be found in the
+shim source package. The details of the key are:
+ <screen>
+Certificate:
+ Data:
+ Version: 3 (0x2)
+ Serial Number: 2574709492 (0x9976f2f4)
+ Signature Algorithm: sha256WithRSAEncryption
+ Issuer: CN=Fedora Secure Boot CA
+ Validity
+ Not Before: Dec 7 16:25:54 2012 GMT
+ Not After : Dec 5 16:25:54 2022 GMT
+ Subject: CN=Fedora Secure Boot CA
+ Subject Public Key Info:
+ Public Key Algorithm: rsaEncryption
+ Public-Key: (2048 bit)
+ Modulus:
+ 00:ae:f5:f7:52:81:a9:5c:3e:2b:f7:1d:55:f4:5a:
+ 68:84:2d:bc:8b:76:96:85:0d:27:b8:18:a5:cd:c1:
+ 83:b2:8c:27:5d:23:0a:d1:12:0a:75:98:a2:e6:5d:
+ 01:8a:f4:d9:9f:fc:70:bc:c3:c4:17:7b:02:b5:13:
+ c4:51:92:e0:c0:05:74:b9:2e:3d:24:78:a0:79:73:
+ 94:c0:c2:2b:b2:82:a7:f4:ab:67:4a:22:f3:64:cd:
+ c3:f9:0c:26:01:bf:1b:d5:3d:39:bf:c9:fa:fb:5e:
+ 52:b9:a4:48:fb:13:bf:87:29:0a:64:ef:21:7b:bc:
+ 1e:16:7b:88:4f:f1:40:2b:d9:22:15:47:4e:84:f6:
+ 24:1c:4d:53:16:5a:b1:29:bb:5e:7d:7f:c0:d4:e2:
+ d5:79:af:59:73:02:dc:b7:48:bf:ae:2b:70:c1:fa:
+ 74:7f:79:f5:ee:23:d0:03:05:b1:79:18:4f:fd:4f:
+ 2f:e2:63:19:4d:77:ba:c1:2c:8b:b3:d9:05:2e:d9:
+ d8:b6:51:13:bf:ce:36:67:97:e4:ad:58:56:07:ab:
+ d0:8c:66:12:49:dc:91:68:b4:c8:ea:dd:9c:c0:81:
+ c6:91:5b:db:12:78:db:ff:c1:af:08:16:fc:70:13:
+ 97:5b:57:ad:6b:44:98:7e:1f:ec:ed:46:66:95:0f:
+ 05:55
+ Exponent: 65537 (0x10001)
+ X509v3 extensions:
+ Authority Information Access:
+ CA Issuers -
+URI:https://fedoraproject.org/wiki/Features/SecureBoot
+
+ X509v3 Authority Key Identifier:
+ keyid:FD:E3:25:99:C2:D6:1D:B1:BF:58:07:33:5D:7B:20:E4:CD:96:3B:42
+
+ X509v3 Extended Key Usage:
+ Code Signing
+ X509v3 Subject Key Identifier:
+ FD:E3:25:99:C2:D6:1D:B1:BF:58:07:33:5D:7B:20:E4:CD:96:3B:42
+ Signature Algorithm: sha256WithRSAEncryption
+ 37:77:f0:3a:41:a2:1c:9f:71:3b:d6:9b:95:b5:15:df:4a:b6:
+ f4:d1:51:ba:0d:04:da:9c:b2:23:f0:f3:34:59:8d:b8:d4:9a:
+ 75:74:65:80:17:61:3a:c1:96:7f:a7:c1:2b:d3:1a:d6:60:3c:
+ 71:3a:a4:c4:e3:39:03:02:15:12:08:1f:4e:cd:97:50:f8:ff:
+ 50:cc:b6:3e:03:7d:7a:e7:82:7a:c2:67:be:c9:0e:11:0f:16:
+ 2e:1e:a9:f2:6e:fe:04:bd:ea:9e:f4:a9:b3:d9:d4:61:57:08:
+ 87:c4:98:d8:a2:99:64:de:15:54:8d:57:79:14:1f:fa:0d:4d:
+ 6b:cd:98:35:f5:0c:06:bd:f3:31:d6:fe:05:1f:60:90:b6:1e:
+ 10:f7:24:e0:3c:f6:33:50:cd:44:c2:71:18:51:bd:18:31:81:
+ 1e:32:e1:e6:9f:f9:9c:02:53:b4:e5:6a:41:d6:65:b4:2e:f1:
+ cf:b3:b8:82:b0:a3:96:e2:24:d8:83:ae:06:5b:b3:24:74:4d:
+ d1:a4:0a:1d:0a:32:1b:75:a2:96:d1:0e:3e:e1:30:c3:18:e8:
+ cb:53:c4:0b:00:ad:7e:ad:c8:49:41:ef:97:69:bd:13:5f:ef:
+ ef:3c:da:60:05:d8:92:fc:da:6a:ea:48:3f:0e:3e:73:77:fd:
+ a6:89:e9:3f
+ </screen>
+ </para>
</section>
<section id="sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Shim">
<title>The Shim</title>
@@ -29,7 +97,7 @@ 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>
<para>
- In both methods, shim, grub2, and the kernel will detect that they
+ In both boot methods, shim, grub2, 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
11 years, 3 months
[uefi-secure-boot-guide] master: Add a note about a danger of disabling secure boot. (3d03072)
by Eric Christensen
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit 3d0307217753f0c3a9a34c0ee9477b7bb6b32fb3
Author: Josh Bressers <josh(a)bress.net>
Date: Thu Jan 31 14:01:48 2013 -0600
Add a note about a danger of disabling secure boot.
>---------------------------------------------------------------
en-US/What_is_Secure_Boot.xml | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/en-US/What_is_Secure_Boot.xml b/en-US/What_is_Secure_Boot.xml
index b13206e..f04666a 100644
--- a/en-US/What_is_Secure_Boot.xml
+++ b/en-US/What_is_Secure_Boot.xml
@@ -42,6 +42,15 @@ 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: Merge branch 'master' of git://git.fedorahosted.org/git/docs/uefi-secure-boot-guide into bressers (214fe04)
by Eric Christensen
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit 214fe046ccf287b27b125096a7c405bfc6fad7cb
Merge: 30a75a5 5917d3b
Author: Josh Bressers <josh(a)bress.net>
Date: Thu Jan 31 13:36:34 2013 -0600
Merge branch 'master' of git://git.fedorahosted.org/git/docs/uefi-secure-boot-guide into bressers
>---------------------------------------------------------------
en-US/What_is_Secure_Boot.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/en-US/What_is_Secure_Boot.xml b/en-US/What_is_Secure_Boot.xml
index 1cb0b84..b13206e 100644
--- a/en-US/What_is_Secure_Boot.xml
+++ b/en-US/What_is_Secure_Boot.xml
@@ -28,7 +28,7 @@ outside of the concept of Secure Boot and into another topic.
&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
-malware is present until the initial ramdisk (initrd) is loaded. Since
+unsigned executable code is present until the initial ramdisk (initrd) is loaded. Since
initrd cannot currently be signed, it cannot be verified.
</para>
</section>
11 years, 3 months
[uefi-secure-boot-guide] master: Merge branch 'master' of git://git.fedorahosted.org/git/docs/uefi-secure-boot-guide into bressers (30a75a5)
by Eric Christensen
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit 30a75a5e95224ae7c2667b9b5afde317f98d5483
Merge: 11756fa 49b6425
Author: Josh Bressers <josh(a)bress.net>
Date: Thu Jan 31 12:36:59 2013 -0600
Merge branch 'master' of git://git.fedorahosted.org/git/docs/uefi-secure-boot-guide into bressers
Conflicts:
en-US/Implementation_of_Secure_Boot.xml
en-US/What_is_Secure_Boot.xml
>---------------------------------------------------------------
en-US/Implementation_of_Secure_Boot.xml | 12 ++++++------
en-US/UEFI_Secure_Boot_Guide.ent | 1 +
en-US/What_is_Secure_Boot.xml | 10 +++++-----
3 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/en-US/Implementation_of_Secure_Boot.xml b/en-US/Implementation_of_Secure_Boot.xml
index 757f7ff..4a52ca0 100644
--- a/en-US/Implementation_of_Secure_Boot.xml
+++ b/en-US/Implementation_of_Secure_Boot.xml
@@ -6,16 +6,16 @@
<chapter id="chap-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot">
<title>&PRODUCT;'s Implementation of UEFI Secure Boot</title>
<para>
- The Fedora 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.
+ 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>
<para>
The solution to use the Microsoft signing service was one of
simplicity. The key Microsoft uses is shipped on all known hardware, which
-should result in Fedora being able to boot on this hardware without issue.
-There are fo course risks having to rely on a third party for this service.
-Fedora is committed to closely watching activity in this space and will
+should result in &PRODUCT; being able to boot on this hardware without issue.
+There are of course risks having to rely on a third party for this service.
+&PROJECT; is committed to closely watching activity in this space and will
respond to any new information appropriately.
</para>
</section>
@@ -24,7 +24,7 @@ respond to any new information appropriately.
<para>
The shim package also contains a blacklist of known bad keys or
binaries that should not be allowed to boot. Microsoft will provide this
-list to Fedora for inclusion. This may create periodic update to the
+list to &PROJECT; for inclusion. This may create periodic update 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>
@@ -32,7 +32,7 @@ update the blacklist to ensure known bad code cannot be executed.
In both methods, shim, grub2, 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
-Fedora-specific cryptographic public key before starting it. The validation
+&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
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:
diff --git a/en-US/UEFI_Secure_Boot_Guide.ent b/en-US/UEFI_Secure_Boot_Guide.ent
index e746308..b1f8562 100644
--- a/en-US/UEFI_Secure_Boot_Guide.ent
+++ b/en-US/UEFI_Secure_Boot_Guide.ent
@@ -1,4 +1,5 @@
<!ENTITY PRODUCT "Fedora">
+<!ENTITY PROJECT "Fedora Project">
<!ENTITY BOOKID "UEFI_Secure_Boot_Guide">
<!ENTITY YEAR "2012-2013">
<!ENTITY HOLDER "Fedora Project Contributors">
diff --git a/en-US/What_is_Secure_Boot.xml b/en-US/What_is_Secure_Boot.xml
index 49c7b7f..1cb0b84 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 Fedora 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 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.
</para>
<section id="sect-UEFI_Secure_Boot_Guide-What_is_Secure_Boot-Protect_you_from">
<title>What does Secure Boot protect you from?</title>
@@ -25,8 +25,8 @@ 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>
- Fedora has expanded the chain of trust into the Kernel.
-Verification happens as far as only loadin signed kernel modules, but it
+ &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
malware is present until the initial ramdisk (initrd) is loaded. Since
initrd cannot currently be signed, it cannot be verified.
@@ -36,8 +36,8 @@ initrd cannot currently be signed, it cannot be verified.
<title>What does Secure Boot not protect you from?</title>
<para>
Secure Boot will not protect your PC from malware or attackers.
-Secure Boot itslef is simply to protect the boot phase of a system. In
-Fedora if you use Secure Boot, what modules the kernel loads can be
+Secure Boot itself is simply to protect the boot phase of a system. In
+&PRODUCT; if you use Secure Boot, what modules the kernel loads can be
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.
11 years, 3 months
[uefi-secure-boot-guide] master: Add notes about the implementation (shim, keys, and a note about the key expiration) (11756fa)
by Eric Christensen
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit 11756faedb9c658e4afd5259720b9b4201542c64
Author: Josh Bressers <josh(a)bress.net>
Date: Thu Jan 31 10:10:38 2013 -0600
Add notes about the implementation (shim, keys, and a note about the key
expiration)
>---------------------------------------------------------------
en-US/Implementation_of_Secure_Boot.xml | 60 ++++++++++++++++++++++++++----
1 files changed, 52 insertions(+), 8 deletions(-)
diff --git a/en-US/Implementation_of_Secure_Boot.xml b/en-US/Implementation_of_Secure_Boot.xml
index 013cb7a..757f7ff 100644
--- a/en-US/Implementation_of_Secure_Boot.xml
+++ b/en-US/Implementation_of_Secure_Boot.xml
@@ -8,15 +8,44 @@
<para>
The Fedora 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>
- <para>
- In both methods, shim, grub2, 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 Fedora-specific cryptographic public key before starting it. The validation is done via shim for grub2, and grub2 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:
+ <section id="sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Keys">
+ <title>The Keys</title>
+ <para>
+ The solution to use the Microsoft signing service was one of
+simplicity. The key Microsoft uses is shipped on all known hardware, which
+should result in Fedora being able to boot on this hardware without issue.
+There are fo course risks having to rely on a third party for this service.
+Fedora is committed to closely watching activity in this space and will
+respond to any new information appropriately.
+ </para>
+ </section>
+ <section id="sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Shim">
+ <title>The Shim</title>
+ <para>
+ The shim package also contains a blacklist of known bad keys or
+binaries that should not be allowed to boot. Microsoft will provide this
+list to Fedora for inclusion. This may create periodic update 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>
+ <para>
+ In both methods, shim, grub2, 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
+Fedora-specific cryptographic public key before starting it. The validation
+is done via shim for grub2, and grub2 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>
<member>it will validate the boot command line to only allow certain kernel settings</member>
<member>it will check modules at load time for signatures and refuse to load them if they are unsigned or signed with a signature not found in the UEFI key store variables (see note)</member>
<member>it will refuse any operations from userland which cause userland-defined DMA.</member>
</simplelist>
- </para>
- <para>
+ </para>
+ </section>
+ <section id="sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Restrictions">
+ <title>Restrictions</title>
+ <para>
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>
@@ -24,14 +53,29 @@
<member>third party modules that are unsigned, or signed with an unknown key</member>
<member>systemtap kernel probing (and kprobes)</member>
</simplelist>
- </para>
- <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.
- </para>
+ </para>
+ <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
+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>
+ 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
+out of the question. This is the date Microsoft gave the signature, Fedora
+has no control over it. We are investigating this issue and expect to
+resolve it in the future.
+ </para>
+ </important>
+ </section>
</chapter>
11 years, 3 months