summaryrefslogtreecommitdiffstats
path: root/meta/recipes-core/ovmf/ovmf_git.bb
diff options
context:
space:
mode:
authorPatrick Ohly <patrick.ohly@intel.com>2016-12-21 09:18:05 +0100
committerRichard Purdie <richard.purdie@linuxfoundation.org>2017-02-28 11:26:33 +0000
commit1913ace7d0898b5a23a2dbdc574ab1d8648927c5 (patch)
tree8df460b8a0fefb3c2d538f23fd1af13fbb3ca419 /meta/recipes-core/ovmf/ovmf_git.bb
parentb91fc0893651b9e3069893e36439de0b4e70ad13 (diff)
downloadopenembedded-core-1913ace7d0898b5a23a2dbdc574ab1d8648927c5.tar.gz
ovmf: build image which enrolls standard keys
When booting a qemu virtual machine with ovmf.secboot, it comes up with no keys installed and thus Secure Boot disabled. To lock down the machine like a typical PC, one has to enroll the same keys that PC vendors normally install, i.e. the ones from Microsoft. This can be done manually (see https://wiki.ubuntu.com/SecurityTeam/SecureBoot and https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_into_UEFI_Secure_Boot_White_Paper.pdf) or automatically with the EnrollDefaultKeys.efi helper from the Fedora ovmf rpm. To use this with qemu: $ bitbake ovmf-shell-image ... $ runqemu serial nographic qemux86 ovmf-shell-image wic ovmf.secboot ... UEFI Interactive Shell v2.1 EDK II UEFI v2.60 (EDK II, 0x00010000) Mapping table FS0: Alias(s):HD2b:;BLK4: PciRoot(0x0)/Pci(0x5,0x0)/HD(1,GPT,06AEF759-3982-4AF6-B517-70BA6304FC1C,0x800,0x566C) BLK0: Alias(s): PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0) BLK1: Alias(s): PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x1) BLK2: Alias(s): PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0) BLK3: Alias(s): PciRoot(0x0)/Pci(0x5,0x0) Press ESC in 1 seconds to skip startup.nsh or any other key to continue. Shell> fs0:EnrollDefaultKeys.efi info: SetupMode=1 SecureBoot=0 SecureBootEnable=0 CustomMode=0 VendorKeys=1 info: SetupMode=0 SecureBoot=1 SecureBootEnable=1 CustomMode=0 VendorKeys=0 info: success Shell> reset Remember that this will modify deploy/images/qemux86/ovmf.secboot.qcow2, so make a copy and use the full path of that copy instead of the "ovmf" argument if needed. The ovmf-shell-image contains an EFI shell, which is what got started here directly. After enrolling the keys, Secure Boot is active and the same image cannot be booted anymore, so the BIOS goes through the normal boot targets (including network boot, which can take a while to time out), and ends up in the internal EFI shell. Trying to invoke bootia32.efi (the shell from the image) or EnrollDefaultKeys.efi then fails: Shell> bootia32.efi Command Error Status: Security Violation The main purpose at the moment is to test that Secure Boot enforcement really works. If we had a way to sign generated images, that part could also be tested by booting in a locked down qemu instance. 0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch is from https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch?id=b1781931894bf2057464e634beed68b1e3218c9e with one line changed to fix https://bugzilla.redhat.com/show_bug.cgi?id=132502: "EFI_STATUS Status = EFI_SUCCESS;" in EnrollListOfX509Certs() lacked the initializer. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Diffstat (limited to 'meta/recipes-core/ovmf/ovmf_git.bb')
-rw-r--r--meta/recipes-core/ovmf/ovmf_git.bb22
1 files changed, 22 insertions, 0 deletions
diff --git a/meta/recipes-core/ovmf/ovmf_git.bb b/meta/recipes-core/ovmf/ovmf_git.bb
index bdec6aa851..436b2f06f2 100644
--- a/meta/recipes-core/ovmf/ovmf_git.bb
+++ b/meta/recipes-core/ovmf/ovmf_git.bb
@@ -19,6 +19,7 @@ SRC_URI = "git://github.com/tianocore/edk2.git;branch=master \
SRC_URI_append_class-target = " \
${@bb.utils.contains('PACKAGECONFIG', 'secureboot', 'http://www.openssl.org/source/openssl-1.0.2j.tar.gz;name=openssl;subdir=${S}/CryptoPkg/Library/OpensslLib', '', d)} \
+ file://0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch \
"
SRCREV="4575a602ca6072ee9d04150b38bfb143cbff8588"
@@ -136,6 +137,7 @@ do_compile_class-target() {
ln ${build_dir}/FV/OVMF.fd ${WORKDIR}/ovmf/ovmf.fd
ln ${build_dir}/FV/OVMF_CODE.fd ${WORKDIR}/ovmf/ovmf.code.fd
ln ${build_dir}/FV/OVMF_VARS.fd ${WORKDIR}/ovmf/ovmf.vars.fd
+ ln ${build_dir}/${OVMF_ARCH}/Shell.efi ${WORKDIR}/ovmf/
if ${@bb.utils.contains('PACKAGECONFIG', 'secureboot', 'true', 'false', d)}; then
# See CryptoPkg/Library/OpensslLib/Patch-HOWTO.txt and
@@ -150,6 +152,7 @@ do_compile_class-target() {
${S}/OvmfPkg/build.sh $PARALLEL_JOBS -a $OVMF_ARCH -b RELEASE -t ${FIXED_GCCVER} ${OVMF_SECURE_BOOT_FLAGS}
ln ${build_dir}/FV/OVMF.fd ${WORKDIR}/ovmf/ovmf.secboot.fd
ln ${build_dir}/FV/OVMF_CODE.fd ${WORKDIR}/ovmf/ovmf.secboot.code.fd
+ ln ${build_dir}/${OVMF_ARCH}/EnrollDefaultKeys.efi ${WORKDIR}/ovmf/
fi
}
@@ -159,8 +162,27 @@ do_install_class-native() {
}
do_install_class-target() {
+ # Content for UEFI shell iso. We install the EFI shell as
+ # bootx64/ia32.efi because then it can be started even when the
+ # firmware itself does not contain it.
+ install -d ${D}/efi/boot
+ install ${WORKDIR}/ovmf/Shell.efi ${D}/efi/boot/boot${@ "ia32" if "${TARGET_ARCH}" != "x86_64" else "x64"}.efi
+ if ${@bb.utils.contains('PACKAGECONFIG', 'secureboot', 'true', 'false', d)}; then
+ install ${WORKDIR}/ovmf/EnrollDefaultKeys.efi ${D}
+ fi
}
+# This always gets packaged because ovmf-shell-image depends on it.
+# This allows testing that recipe in all configurations because it
+# can always be part of a world build.
+#
+# However, EnrollDefaultKeys.efi is only included when Secure Boot is enabled.
+PACKAGES =+ "ovmf-shell-efi"
+FILES_ovmf-shell-efi = " \
+ EnrollDefaultKeys.efi \
+ efi/ \
+"
+
do_deploy() {
}
do_deploy[cleandirs] = "${DEPLOYDIR}"