From aee7b5ba60b474d134218735695c379c37fba2cb Mon Sep 17 00:00:00 2001
From: Laszlo Ersek <lersek@redhat.com>
Date: Fri, 5 May 2017 20:24:14 +0200
Subject: [PATCH 03/10] OvmfPkg/EnrollDefaultKeys: blacklist empty file in dbx
for Windows HCK (RH)
Message-id: <20170505182421.19670-4-lersek@redhat.com>
Patchwork-id: 75030
O-Subject: [RHEL-7.4 ovmf PATCH v2 03/10] OvmfPkg/EnrollDefaultKeys: blacklist
empty file in dbx for Windows HCK (RH)
Bugzilla: 1443351
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Acked-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Acked-by: Miroslav Rezanina <mrezanin@redhat.com>
The Microsoft.UefiSecureBootLogo.Tests.OutOfBoxConfirmDBXisPresent test
case of the Secure Boot Logo Test in the Microsoft Hardware Certification
Kit expects that the "dbx" variable exist.
The article at <https://technet.microsoft.com/en-us/library/dn747883.aspx>
writes (excerpt):
Windows 8.1 Secure Boot Key Creation and Management Guidance
1. Secure Boot, Windows 8.1 and Key Management
1.4 Signature Databases (Db and Dbx)
1.4.3 Forbidden Signature Database (dbx)
The contents of EFI_IMAGE_SIGNATURE_DATABASE1 dbx must be checked when
verifying images before checking db and any matches must prevent the
image from executing. The database may contain multiple certificates,
keys, and hashes in order to identify forbidden images. The Windows
Hardware Certification Requirements state that a dbx must be present,
so any dummy value, such as the SHA-256 hash of 0, may be used as a
safe placeholder until such time as Microsoft begins delivering dbx
updates.
The byte array introduced and enrolled into dbx in this patch captures the
SHA256 checksum of the empty file, blacklisting it for loading &
execution. This qualifies as a dummy, since the empty file is not a valid
UEFI binary anyway.
Technically speaking, we could also capture an official (although soon to
be obsolete) dbx update from <http://www.uefi.org/revocationlistfile>.
However, the terms and conditions on distributing that binary aren't
exactly light reading, so let's best steer clear of it, and follow the
"dummy entry" practice recommended -- in natural English langauge -- in
the above-referenced TechNet article.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
RHEL-7 port notes:
- Upstream status: N/A, EnrollDefaultKeys.efi is downstream only.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.c | 51 ++++++++++++++++++++++++-
OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.inf | 1 +
2 files changed, 51 insertions(+), 1 deletion(-)
diff --git a/OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.c b/OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.c
index 04e25bc..dd413df 100644
--- a/OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.c
+++ b/OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.c
@@ -485,6 +485,44 @@ STATIC CONST UINT8 MicrosoftUefiCA[] = {
};
//
+// The Microsoft.UefiSecureBootLogo.Tests.OutOfBoxConfirmDBXisPresent test case
+// of the Secure Boot Logo Test in the Microsoft Hardware Certification Kit
+// expects that the "dbx" variable exist.
+//
+// The article at <https://technet.microsoft.com/en-us/library/dn747883.aspx>
+// writes (excerpt):
+//
+// Windows 8.1 Secure Boot Key Creation and Management Guidance
+// 1. Secure Boot, Windows 8.1 and Key Management
+// 1.4 Signature Databases (Db and Dbx)
+// 1.4.3 Forbidden Signature Database (dbx)
+//
+// The contents of EFI_IMAGE_SIGNATURE_DATABASE1 dbx must be checked when
+// verifying images before checking db and any matches must prevent the
+// image from executing. The database may contain multiple certificates,
+// keys, and hashes in order to identify forbidden images. The Windows
+// Hardware Certification Requirements state that a dbx must be present, so
+// any dummy value, such as the SHA-256 hash of 0, may be used as a safe
+// placeholder until such time as Microsoft begins delivering dbx updates.
+//
+// The byte array below captures the SHA256 checksum of the empty file,
+// blacklisting it for loading & execution. This qualifies as a dummy, since
+// the empty file is not a valid UEFI binary anyway.
+//
+// Technically speaking, we could also capture an official (although soon to be
+// obsolete) dbx update from <http://www.uefi.org/revocationlistfile>. However,
+// the terms and conditions on distributing that binary aren't exactly light
+// reading, so let's best steer clear of it, and follow the "dummy entry"
+// practice recommended -- in natural English langauge -- in the
+// above-referenced TechNet article.
+//
+STATIC CONST UINT8 mSha256OfDevNull[] = {
+ 0xe3, 0xb0, 0xc4, 0x42, 0x98, 0xfc, 0x1c, 0x14, 0x9a, 0xfb, 0xf4, 0xc8, 0x99,
+ 0x6f, 0xb9, 0x24, 0x27, 0xae, 0x41, 0xe4, 0x64, 0x9b, 0x93, 0x4c, 0xa4, 0x95,
+ 0x99, 0x1b, 0x78, 0x52, 0xb8, 0x55
+};
+
+//
// The following test cases of the Secure Boot Logo Test in the Microsoft
// Hardware Certification Kit:
//
@@ -615,7 +653,8 @@ typedef struct {
@param[in] CertType The GUID determining the type of all the
certificates in the set that is passed in. For
example, gEfiCertX509Guid stands for DER-encoded
- X.509 certificates.
+ X.509 certificates, while gEfiCertSha256Guid stands
+ for SHA256 image hashes.
@param[in] ... A list of
@@ -918,6 +957,16 @@ ShellAppMain (
}
Status = EnrollListOfCerts (
+ EFI_IMAGE_SECURITY_DATABASE1,
+ &gEfiImageSecurityDatabaseGuid,
+ &gEfiCertSha256Guid,
+ mSha256OfDevNull, sizeof mSha256OfDevNull, &gEfiCallerIdGuid,
+ NULL);
+ if (EFI_ERROR (Status)) {
+ return 1;
+ }
+
+ Status = EnrollListOfCerts (
EFI_KEY_EXCHANGE_KEY_NAME,
&gEfiGlobalVariableGuid,
&gEfiCertX509Guid,
diff --git a/OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.inf b/OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.inf
index 30c127f..0ad86a2 100644
--- a/OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.inf
+++ b/OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.inf
@@ -36,6 +36,7 @@
[Guids]
gEfiCertPkcs7Guid
+ gEfiCertSha256Guid
gEfiCertX509Guid
gEfiCustomModeEnableGuid
gEfiGlobalVariableGuid
--
1.8.3.1