[uefi-secure-boot-guide] master: Tell apart Secure Boot, UEFI Secure Boot, Microsoft Secure Boot (4ff8de4)
sparks at fedoraproject.org
sparks at fedoraproject.org
Wed Feb 13 17:57:56 UTC 2013
Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
>---------------------------------------------------------------
commit 4ff8de480263587d0b9baf222b6eabada8075656
Author: Florian Weimer <fweimer at redhat.com>
Date: Wed Feb 13 14:07:44 2013 +0100
Tell apart Secure Boot, UEFI Secure Boot, Microsoft Secure Boot
Also rewrite the notes on the Microsoft implementation, and include
the Microsoft certificates.
Signed-off-by: Eric Christensen <sparks at redhat.com>
>---------------------------------------------------------------
en-US/What_is_Secure_Boot.xml | 436 ++++++++++++++++++++++++++++++++++++-----
1 files changed, 389 insertions(+), 47 deletions(-)
diff --git a/en-US/What_is_Secure_Boot.xml b/en-US/What_is_Secure_Boot.xml
index f908b6c..4833685 100644
--- a/en-US/What_is_Secure_Boot.xml
+++ b/en-US/What_is_Secure_Boot.xml
@@ -7,76 +7,417 @@
<title>What is UEFI Secure Boot?</title>
<para>
<firstterm>Secure Boot</firstterm> is a technology where the system boot
-loader (<firstterm>UEFI</firstterm> environment, previously called "BIOS")
+loader
checks that the next-stage boot loader is signed with a cryptographic key
authorized by the configuration of the system boot loader. With adequate
signature verification in the next-stage boot loader(s), kernel, and,
potentially, user space, it is possible to prevent the execution of
-unsigned code. Certificate and signature revocation is implemented using
-append-only boot loader configuration variables, and additions must be
-cryptographically signed.
+unsigned code.
</para>
- <para>
-From a user point of view, a system which has enabled Secure Boot and which
-is confronted with a tampered boot path simply stops working until Secure
+<para>
+ Secure Boot is sometimes called <firstterm>Verified
+ Boot</firstterm>. Boot path validation is also part of other
+ technologies such as <firstterm>Trusted Boot</firstterm>. Boot path
+ validation is indepedent of secure storage of cryptographic keys and
+ remote attestation.
+</para>
+<section>
+<title>UEFI Secure Boot</title>
+<para>
+ <firstterm>UEFI Secure Boot</firstterm> is the boot path validation
+ component of the <firstterm>UEFI</firstterm> specification
+ (<firstterm>Unified Extensible Firmware Interface</firstterm>).
+ Roughly speaking, it specifies the following:
+</para>
+<itemizedlist>
+ <listitem>
+ <para>
+ a programming interface for cryptographically protected UEFI
+ variables in non-volatile storage,
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ how the trusted X.509 root certificates are stored in UEFI
+ variables,
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ validation of UEFI applications (boot loaders and drivers) using
+ AuthentiCode signatures embedded in these applications, and
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ procedures to revoke known-bad certificates and application
+ hashes.
+ </para>
+ </listitem>
+</itemizedlist>
+<para>
+UEFI Secure Boot does not require specialized hardware, apart from
+non-volatile (flash) storage which can be switched from read-write
+mode to read-only mode during system boot. This storage has to be
+used to store the UEFI implementation itself and some of the
+protected UEFI variables (including the trusted root certificate
+store).
+</para>
+<para>
+From a user point of view, a system which has enabled UEFI Secure Boot and which
+is confronted with a tampered boot path simply stops working until UEFI Secure
Boot is disabled or a signed next-stage boot loader is available on boot
-media. Similarly, operating system installers do not run and result in an
+media. Similarly, operating system installers
+without a cryptographically valid signature
+do not run and result in an
error message. Users are not offered a way to override the boot loader
decision to reject the signature, unlike the similar scenario with web
server certificates. No certificate issuer information is provided to the
-user. Secure Boot does not prevent the installation or removal of
+user.
+</para>
+<para>
+UEFI Secure Boot does not prevent the installation or removal of
second-stage boot loaders or require explicit user confirmation of such
changes. Signatures are verified during booting, and not when the boot
loader is installed or updated.
- </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 <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>
+Therefore, UEFI Secure Boot does not stop boot path manipulations.
+It only simplifies their detection and the reconstruction of the
+original, uncompromised boot path.
+</para>
<note>
<title>Client Technology</title>
<para>
-Secure Boot is only available on some client devices, and it is explicitly
+UEFI Secure Boot is only available on some client devices, and it is explicitly
labeled as client (as opposed to server) technology. It is expected that
server technology will support Secure Boot at a future date.
</para>
</note>
- <section id="sect-UEFI_Secure_Boot_Guide-What_is_Secure_Boot-Microsoft_Implementation">
-<title>Microsoft Implementation</title>
- <para>
-Microsoft controls the cryptographic chain installed by system vendors.
-With its Secure Boot signing service, Microsoft creates an AuthentiCode
-signature on binaries submitted by third parties for use with Secure Boot.
-(A regular code signing certificate is not directly usable for booting, it
-is only used for submitting the binary to Microsoft.) The signatures which
-come out of signing service are currently pseudonymous and do not permit
-the identification of the party that submitted the binary.
- </para>
- <para>
-Microsoft Windows 8 supports AuthentiCode validation and loading of
-third-party kernel modules. Hibernation is not disabled, which may provide
-a venue to circumvent Secure Boot. Windows has infrastructure to extend
-cryptographic validation to user space programs, too.
- </para>
- <para>
+</section>
+<section id="sect-UEFI_Secure_Boot_Guide-What_is_Secure_Boot-Microsoft_Implementation">
+<title>Microsoft Secure Boot</title>
+<para>
+Microsoft has not published many details about their
+implementation of Secure Boot, which is based on UEFI Secure Boot.
+</para>
+<para>
+Microsoft supports UEFI Secure Boot only with Windows 8, but it is not required
+for running Windows 8. Systems in a UEFI Secure Boot environment still boot if
+Secure Boot support is removed from the UEFI environment. Customers who
+want to use previous versions of Windows need to disable Secure Boot
+because Microsoft does not provide signed boot loaders for them.
+</para>
+<para>
+Based on the public record, the following security objectives
+for Microsoft Secure Boot appear likely:
+</para>
+<itemizedlist>
+<listitem>
+ <para>
+ integrity protection of installation media which is stored on
+ writable media (such as hard disk recovery partitions),
+ </para>
+</listitem>
+<listitem>
+ <para>
+ protection of the boot path until heuristic countermeasures (such
+ as kernel mode anti-virus software) can be loaded during early
+ boot, and
+ </para>
+</listitem>
+<listitem>
+ <para>
+ automatic restoration of the original boot path, perhaps after the
+ system has been compromised by malware, without complete
+ reinstallation of the entire operating system.
+ </para>
+</listitem>
+</itemizedlist>
+<para>
+It is unclear whether there are plans to restrict access to certain
+(online) content to systems which have enabled UEFI Secure Boot and
+whose boot path is cryptographically valid. This would imply a remote
+attestation aspect which is not part of the UEFI Secure Boot
+specification, and which cannot be implemented securely without
+additional hardware support. It also would imply to that
+UEFI Secure Boot is no longer truly optional.
+</para>
+<para>
+There is no evidence that Microsoft intended to lock out anyone with
+their implementation of Secure Boot. However, automatic restoration
+of the original boot path is much more complicated once other boot
+loaders can co-exist on the same system.
+</para>
+<section>
+<title>Implementation details</title>
+<!--
+Requirements extracted from:
+
+Windows Hardware Certification Requirements: Client and Server Systems
+Microsoft Corporation
+Updated: September 18, 2012
+
+http://download.microsoft.com/download/a/d/f/adf5bede-c0fb-4cc0-a3e1-b38093f50ba1/windows8-hardware-cert-requirements-system.pdf
+-->
+<para>
+Microsoft requires that client PCs which carry the Windows 8 logo
+must enable UEFI Secure Boot and install Microsoft-provided key
+material. The required X.509 certificate is shown in <xref
+linkend="fig-Secure_Boot-Microsoft_PCA"/>. System vendors are
+encouraged to include other root certificates as needed, but those are
+not required to be present.
+</para>
+<figure id="fig-Secure_Boot-Microsoft_PCA">
+ <title>Microsoft Trusted X.509 Certificate for their Secure Boot implementation</title>
+<literallayout class="monospaced">
+Certificate:
+ Data:
+ Version: 3 (0x2)
+ Serial Number:
+ 61:07:76:56:00:00:00:00:00:08
+ Signature Algorithm: sha256WithRSAEncryption
+ Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
+ CN=Microsoft Root Certificate Authority 2010
+ Validity
+ Not Before: Oct 19 18:41:42 2011 GMT
+ Not After : Oct 19 18:51:42 2026 GMT
+ Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
+ CN=Microsoft Windows Production PCA 2011
+ Subject Public Key Info:
+ Public Key Algorithm: rsaEncryption
+ Public-Key: (2048 bit)
+ Modulus:
+ 00:dd:0c:bb:a2:e4:2e:09:e3:e7:c5:f7:96:69:bc:
+ […]
+ 87:65:b4:43:18:a8:b2:e0:6d:19:77:ec:5a:24:fa:
+ 48:03
+ Exponent: 65537 (0x10001)
+ X509v3 extensions:
+ 1.3.6.1.4.1.311.21.1:
+ 02:01:00
+ X509v3 Subject Key Identifier:
+ A9:29:02:39:8E:16:C4:97:78:CD:90:F9:9E:4F:9A:E1:7C:55:AF:53
+ 1.3.6.1.4.1.311.20.2:
+ 1E:0A:00:53:00:75:00:62:00:43:00:41
+ X509v3 Key Usage:
+ Digital Signature, Certificate Sign, CRL Sign
+ X509v3 Basic Constraints: critical
+ CA:TRUE
+ X509v3 Authority Key Identifier:
+ keyid:D5:F6:56:CB:8F:E8:A2:5C:62:68:D1:3D:94:90:5B:D7:CE:9A:18:C4
+
+ X509v3 CRL Distribution Points:
+
+ Full Name:
+ URI:http://crl.microsoft.com/pki/crl/products/MicRooCerAut_2010-06-23.crl
+
+ Authority Information Access:
+ CA Issuers - URI:http://www.microsoft.com/pki/certs/MicRooCerAut_2010-06-23.crt
+
+ Signature Algorithm: sha256WithRSAEncryption
+ 14:fc:7c:71:51:a5:79:c2:6e:b2:ef:39:3e:bc:3c:52:0f:6e:
+ […]
+ 04:cf:77:a4:62:1c:59:7e
+
+-----BEGIN CERTIFICATE-----
+MIIF1zCCA7+gAwIBAgIKYQd2VgAAAAAACDANBgkqhkiG9w0BAQsFADCBiDELMAkG
+A1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQx
+HjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjEyMDAGA1UEAxMpTWljcm9z
+b2Z0IFJvb3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IDIwMTAwHhcNMTExMDE5MTg0
+MTQyWhcNMjYxMDE5MTg1MTQyWjCBhDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldh
+c2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQxHjAcBgNVBAoTFU1pY3Jvc29mdCBD
+b3Jwb3JhdGlvbjEuMCwGA1UEAxMlTWljcm9zb2Z0IFdpbmRvd3MgUHJvZHVjdGlv
+biBQQ0EgMjAxMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN0Mu6Lk
+Lgnj58X3lmm8ACG9aTMz760Ey1SA7gaDu8UghNn30ovzOLCrpK0tfGJ5Bf/jSj8E
+NSBw48Tna+CcwDZ16Yox3Y1w5dw3tXRGlihbh2AjLL/cR6Vn91EnnnLrB6bJuR47
+UzV85dPsJ7mHHP65ySMJb6hGkcFuljxB08ujP10Cak3saR8lKFw2//1DFQqU4Bm0
+z9/CEuLCWyfuJ3gwi1sqCWsiiVNgFizAaB1TuuxJ851hjIVoCXNEXX2iVCvdefcV
+zzVdbBwrXM68nCOLb261Jtk2E8NP1ieuuTI7QZIs4cfNd+iqVE73XAsEh2W0Qxio
+suBtGXfsWiT6SAMCAwEAAaOCAUMwggE/MBAGCSsGAQQBgjcVAQQDAgEAMB0GA1Ud
+DgQWBBSpKQI5jhbEl3jNkPmeT5rhfFWvUzAZBgkrBgEEAYI3FAIEDB4KAFMAdQBi
+AEMAQTALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBTV
+9lbLj+iiXGJo0T2UkFvXzpoYxDBWBgNVHR8ETzBNMEugSaBHhkVodHRwOi8vY3Js
+Lm1pY3Jvc29mdC5jb20vcGtpL2NybC9wcm9kdWN0cy9NaWNSb29DZXJBdXRfMjAx
+MC0wNi0yMy5jcmwwWgYIKwYBBQUHAQEETjBMMEoGCCsGAQUFBzAChj5odHRwOi8v
+d3d3Lm1pY3Jvc29mdC5jb20vcGtpL2NlcnRzL01pY1Jvb0NlckF1dF8yMDEwLTA2
+LTIzLmNydDANBgkqhkiG9w0BAQsFAAOCAgEAFPx8cVGlecJusu85Prw8Ug9uKz8Q
+E3P+qGjQSKY0TYqWBSbuMUaQYXnW/zguRWv0wOUouNodj4rbCdcax0wKNmZqjOwb
+1wSQqBgXpJu54kAyNnbEwVrGv+QEwOoW06zDaO9irN1UbFAwWKbrfP6Up06O9Ox8
+hnNXwlIhczRa86OKVsgE2gcJ7fiL4870fo6u8PYLigj7P8kdcn9TuOu+Y+DjPTFl
+sIHl8qzNFqSfPaixm8JC0JCEX1Qd/4nquh1HkG+wc05Bn0CfX+WhKrIRkXOKISjw
+zt5zOV8+q1xg7N8DEKjTCen09paFtn9RiGZHGY2isBI9gSpoBXe7kUxie7bBB8e6
+eoc0Aw5LYnqZ6cr8zko3yS2kV3wc/j3cuA9a+tbEswKFAjrqs9lu5GkhN96B0fZ1
+GQVn05NXXikbOcjuLeHN5EVzW9DSznqrFhmCRljQXp2Bs2evbDXyvOU/JOI1ogp1
+BvYYVpnUeCzRBRvr0IgBnaoQ8QXfun4sY7cGmyMhxPl4bOJYFwY2K5ESA8yk2fIt
+uvmUnUDtGEXxzopcaz6rA9NwGCoKauBfR9HVYwoy8q/XNh8qcFrlQlkIcUtXun6D
+gfAhPPQcwcW5kJMOiEWThumxIJm+mMvFlaRdYtagYwggvXUQd30980W5n5efy1eA
+bzOpBM93pGIcWX4=
+-----END CERTIFICATE-----
+</literallayout>
+</figure>
+<para>
Microsoft is expected to eventually ship signed revocation requests in
-Windows Update which are installed into the system boot loader
-configuration during the next system boot. At the time of this writing,
-such a blacklist does not yet exist.
+Windows Update. These requests are installed into the UEFI Secure
+Boot configuration variables during the next system boot, after
+validating them against the Microsoft key. At the time of this
+writing, such a blacklist does not yet exist.
+</para>
+<para>
+Third-party boot loaders currently do not have access to the
+<emphasis>Microsoft Windows Production PCA 2011</emphasis> certificate
+Microsoft uses for their own products. Instead, Microsoft provides a
+signing service originally intended for UEFI drivers. This service
+has been extended to include third-party boot loaders, too. Microsoft
+reviews the submitted UEFI applications, provides an AuthentiCode
+signature using its own key, and sends the result back to the author.
+This signature does not identify the application author (it is
+pseudonymous), and, more importantly, it is chained via the
+intermediate certificate <emphasis>Microsoft Corporation UEFI CA
+2011</emphasis> (see <xref
+linkend="fig-Secure_Boot-Microsoft_UEFI_PCA"/>) to the
+<emphasis>Microsoft Corporation Third Party Marketplace
+Root</emphasis> root certificate.
+</para>
+<warning>
+<para>
+Third-party UEFI boot loaders are not guaranteed to work on Microsoft
+Secure Boot systems because the necessary certificates are not part
+of the Microsoft Secure Boot specification.
+</para>
+</warning>
+<figure id="fig-Secure_Boot-Microsoft_UEFI_PCA">
+<title>Microsoft X.509 certificate for third-party UEFI applications</title>
+<literallayout class="monospaced">
+Certificate:
+ Data:
+ Version: 3 (0x2)
+ Serial Number:
+ 61:08:d3:c4:00:00:00:00:00:04
+ Signature Algorithm: sha256WithRSAEncryption
+ Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
+ CN=Microsoft Corporation Third Party Marketplace Root
+ Validity
+ Not Before: Jun 27 21:22:45 2011 GMT
+ Not After : Jun 27 21:32:45 2026 GMT
+ Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
+ CN=Microsoft Corporation UEFI CA 2011
+ Subject Public Key Info:
+ Public Key Algorithm: rsaEncryption
+ Public-Key: (2048 bit)
+ Modulus:
+ 00:a5:08:6c:4c:c7:45:09:6a:4b:0c:a4:c0:87:7f:
+ 06:75:0c:43:01:54:64:e0:16:7f:07:ed:92:7d:0b:
+ b2:73:bf:0c:0a:c6:4a:45:61:a0:c5:16:2d:96:d3:
+ f5:2b:a0:fb:4d:49:9b:41:80:90:3c:b9:54:fd:e6:
+ bc:d1:9d:c4:a4:18:8a:7f:41:8a:5c:59:83:68:32:
+ bb:8c:47:c9:ee:71:bc:21:4f:9a:8a:7c:ff:44:3f:
+ 8d:8f:32:b2:26:48:ae:75:b5:ee:c9:4c:1e:4a:19:
+ 7e:e4:82:9a:1d:78:77:4d:0c:b0:bd:f6:0f:d3:16:
+ d3:bc:fa:2b:a5:51:38:5d:f5:fb:ba:db:78:02:db:
+ ff:ec:0a:1b:96:d5:83:b8:19:13:e9:b6:c0:7b:40:
+ 7b:e1:1f:28:27:c9:fa:ef:56:5e:1c:e6:7e:94:7e:
+ c0:f0:44:b2:79:39:e5:da:b2:62:8b:4d:bf:38:70:
+ e2:68:24:14:c9:33:a4:08:37:d5:58:69:5e:d3:7c:
+ ed:c1:04:53:08:e7:4e:b0:2a:87:63:08:61:6f:63:
+ 15:59:ea:b2:2b:79:d7:0c:61:67:8a:5b:fd:5e:ad:
+ 87:7f:ba:86:67:4f:71:58:12:22:04:22:22:ce:8b:
+ ef:54:71:00:ce:50:35:58:76:95:08:ee:6a:b1:a2:
+ 01:d5
+ Exponent: 65537 (0x10001)
+ X509v3 extensions:
+ 1.3.6.1.4.1.311.21.1:
+ 02:03:01:00:01
+ 1.3.6.1.4.1.311.21.2:
+ 04:14:F8:C1:6B:B7:7F:77:53:4A:F3:25:37:1D:4E:A1:26:7B:0F:20:70:80
+ X509v3 Subject Key Identifier:
+ 13:AD:BF:43:09:BD:82:70:9C:8C:D5:4F:31:6E:D5:22:98:8A:1B:D4
+ 1.3.6.1.4.1.311.20.2:
+ 1E:0A:00:53:00:75:00:62:00:43:00:41
+ X509v3 Key Usage:
+ Digital Signature, Certificate Sign, CRL Sign
+ X509v3 Basic Constraints: critical
+ CA:TRUE
+ X509v3 Authority Key Identifier:
+ keyid:45:66:52:43:E1:7E:58:11:BF:D6:4E:9E:23:55:08:3B:3A:22:6A:A8
+
+ X509v3 CRL Distribution Points:
+
+ Full Name:
+ URI:http://crl.microsoft.com/pki/crl/products/MicCorThiParMarRoo_2010-10-05.crl
+
+ Authority Information Access:
+ CA Issuers - URI:http://www.microsoft.com/pki/certs/MicCorThiParMarRoo_2010-10-05.crt
+
+ Signature Algorithm: sha256WithRSAEncryption
+ 35:08:42:ff:30:cc:ce:f7:76:0c:ad:10:68:58:35:29:46:32:
+ […]
+ 92:9b:f5:a6:bc:59:83:58
+
+-----BEGIN CERTIFICATE-----
+MIIGEDCCA/igAwIBAgIKYQjTxAAAAAAABDANBgkqhkiG9w0BAQsFADCBkTELMAkG
+A1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQx
+HjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjE7MDkGA1UEAxMyTWljcm9z
+b2Z0IENvcnBvcmF0aW9uIFRoaXJkIFBhcnR5IE1hcmtldHBsYWNlIFJvb3QwHhcN
+MTEwNjI3MjEyMjQ1WhcNMjYwNjI3MjEzMjQ1WjCBgTELMAkGA1UEBhMCVVMxEzAR
+BgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQxHjAcBgNVBAoTFU1p
+Y3Jvc29mdCBDb3Jwb3JhdGlvbjErMCkGA1UEAxMiTWljcm9zb2Z0IENvcnBvcmF0
+aW9uIFVFRkkgQ0EgMjAxMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
+AKUIbEzHRQlqSwykwId/BnUMQwFUZOAWfwftkn0LsnO/DArGSkVhoMUWLZbT9Sug
++01Jm0GAkDy5VP3mvNGdxKQYin9BilxZg2gyu4xHye5xvCFPmop8/0Q/jY8ysiZI
+rnW17slMHkoZfuSCmh14d00MsL32D9MW07z6K6VROF31+7rbeALb/+wKG5bVg7gZ
+E+m2wHtAe+EfKCfJ+u9WXhzmfpR+wPBEsnk55dqyYotNvzhw4mgkFMkzpAg31Vhp
+XtN87cEEUwjnTrAqh2MIYW9jFVnqsit51wxhZ4pb/V6th3+6hmdPcVgSIgQiIs6L
+71RxAM5QNVh2lQjuarGiAdUCAwEAAaOCAXYwggFyMBIGCSsGAQQBgjcVAQQFAgMB
+AAEwIwYJKwYBBAGCNxUCBBYEFPjBa7d/d1NK8yU3HU6hJnsPIHCAMB0GA1UdDgQW
+BBQTrb9DCb2CcJyM1U8xbtUimIob1DAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMA
+QTALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRFZlJD
+4X5YEb/WTp4jVQg7OiJqqDBcBgNVHR8EVTBTMFGgT6BNhktodHRwOi8vY3JsLm1p
+Y3Jvc29mdC5jb20vcGtpL2NybC9wcm9kdWN0cy9NaWNDb3JUaGlQYXJNYXJSb29f
+MjAxMC0xMC0wNS5jcmwwYAYIKwYBBQUHAQEEVDBSMFAGCCsGAQUFBzAChkRodHRw
+Oi8vd3d3Lm1pY3Jvc29mdC5jb20vcGtpL2NlcnRzL01pY0NvclRoaVBhck1hclJv
+b18yMDEwLTEwLTA1LmNydDANBgkqhkiG9w0BAQsFAAOCAgEANQhC/zDMzvd2DK0Q
+aFg1KUYydid87xJBJ0IbSqptgThIWRNV8+lYNKYWC4KqXa2C2oCDQQaPtB3yA7nz
+Gl0b8VCQ+bNVhEIoHCC9sq5RFMXArJeVIRyQ2w/8d56Vc5GIyr29UrkFUA3fV56g
+Ye0N5W0l2UAPF0DIzqNKwk2vmhIdCFSPvce8uSs9SSsfMvxqIWlPm8h+QjT8NgYX
+i48gQMCzmiV1J83JA6P2XdHnNlR6uVC10xLRB7+7dN/cHo+A1e0Y9C8UFmsv3maM
+sCPlx4TY7erBM4KtVksYLfFolQfNz/By8K673YaFmCwhTDMr8A9K8GiHtZJVMnWh
+aoJqPKMlEaTtrdcErsvYQFmghNGVTGKRIhp0HYw9Rw5EpuSwmzQ1sfq2U6gsgeyk
+BXHInbi66BtEZuRHVA6OVn+znxaYsobQaD6QI7UvXo9QhY3GjYJfQaH0Lg3gmdJs
+deS2abUhhvoH0fbiTdHarSx3Ux4lMjfHbFJylYaw8TVhahn1sjuBUFamMi3+oon5
+QoYnGFWhgspam/gwmFQUpkeWJS/IJuRBlBpcAj/lluOFWzw+P7tHFnJV4iUisdl7
+5wMGKqP3HpBGwwAN1hmJ4w41J2IDcRWm79AnoKBZN2D4OJS44Hhw+LpMhoeU9uCu
+AkXuZcK2o35pFnUHkpv1prxZg1g=
+-----END CERTIFICATE-----
+</literallayout>
+</figure>
+<para>
+A regular code signing certificate is <emphasis>not</emphasis>
+sufficient to guarantee booting on a Microsoft Secure Boot system.
+Microsoft requires a code signing certificate when communicating with
+UEFI application authors, but this is an internal detail not visible
+to the end user in any way.
+</para>
+<para>
+In the booted operating system, Microsoft Windows 8 supports
+AuthentiCode validation and loading of signed third-party kernel
+modules. Hibernation is not disabled, which may provide a venue to
+circumvent UEFI Secure Boot. Windows has infrastructure to extend
+cryptographic validation to user space programs, again based on
+AuthentiCode.
+</para>
+</section>
+</section>
+
+<section>
+<title>Fedora Secure Boot</title>
+
+ <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>
-Microsoft supports Secure Boot only with Windows 8, but it is not required
-for running Windows 8. Systems in a Secure Boot environment still boot if
-Secure Boot support is removed from the UEFI environment. Customers who
-want to use previous versions of Windows need to disable Secure Boot
-because Microsoft does not provide signed second-stage boot loaders for
-them.
+ 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>
<section id="sect-UEFI_Secure_Boot_Guide-What_is_Secure_Boot-Protect_you_from">
<title>What does Secure Boot protect you from?</title>
<para>
@@ -166,5 +507,6 @@ user interaction.
</para>
</section>
</section>
+</section>
</chapter>
More information about the docs-commits
mailing list