UEFI + Secure Boot + qemu
cover UEFI + Secure Boot + qemu
There seems to be a consensus that supporting UEFI in OE-core for qemu would be valuable, and there have been some (stalled) attempts to add it. For reference, see:
[OE-core] [PATCH V3 0/3] Add UEFI firmware for qemux86*
[OE-core] Add ovmf-native to make qemu-native/runqemu support boot UEFI image?
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5654
https://github.com/01org/luv-yocto/issues/38
This patch set includes the necessary recipes (ovmf and iasl from meta-luv), some improvements to them (in particular, enabling Secure Boot), and changes to runqemu to make it easier to boot with UEFI. A special image recipes builds an image which can be used to lock down a virtual machine by enrolling the "normal" pre-installed certificates.
I decided to keep the setup simple and use just a single file for UEFI code and variables because that makes the usage via runqemu very easy. See the "runqemu: support UEFI with OVMF firmware" patch for details. The downside is that the firmware can't be updated without loosing variables. I don't see a big need for long-lived virtual machine instances, but would like to hear from others about that.
What's missing is automated testing of this new feature. I'm open for suggestions here; right now I don't know enough about the automated testing in the AB to propose something.
I've discussed the usage of ovmf/iasl with Ricardo and he agreed that moving ovmf and iasl from meta-luv to OE-core makes sense. Ricardo, would you be willing to act as maintainer of it there, like you did in meta-luv?
Beware that "git am --keep-cr" must be used to import the ovmf patches correctly.
The following changes since commit 5e21afc9395060b489156d3f90505a372b713f37:
Revert "selftest/wic: extending test coverage for WIC script options" (2016-12-20 17:06:01 +0000)
are available in the git repository at:
git://github.com/pohly/openembedded-core secure-boot
https://github.com/pohly/openembedded-core/tree/secure-boot
Patrick Ohly (7):
ovmf: explicitly depend on nasm-native
ovmf: deploy firmware in image directory ovmf_git.bb: enable parallel compilation ovmf_git.bb: enable Secure Boot
runqemu: let command line parameters override defaults
runqemu: support UEFI with OVMF firmware
ovmf: build image which enrolls standard keys
meta-luv (2):
ovmf: move from meta-luv to OE-core
iasl: move from meta-luv to OE-core
meta/recipes-core/ovmf/ovmf-shell-image.bb | 22 + ...s-Force-tools-variables-to-host-toolchain.patch | 48 + .../ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch | 110 ++ ...0002-ovmf-update-path-to-native-BaseTools.patch | 32 + ...makefile-adjust-to-build-in-under-bitbake.patch | 39 + ...ollDefaultKeys-application-for-enrolling-.patch | 1123 ++++++++++++++++++++ meta/recipes-core/ovmf/ovmf/ovmf-shell-image.wks | 4 + meta/recipes-core/ovmf/ovmf_git.bb | 178 ++++ meta/recipes-extended/iasl/iasl_20120215.bb | 27 + meta/recipes-extended/iasl/iasl_20150410.bb | 27 + meta/recipes-extended/iasl/iasl_20150515.bb | 27 + scripts/runqemu | 37 +- 12 files changed, 1673 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-core/ovmf/ovmf-shell-image.bb create mode 100644 meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch create mode 100644 meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch create mode 100644 meta/recipes-core/ovmf/ovmf/0002-ovmf-update-path-to-native-BaseTools.patch create mode 100644 meta/recipes-core/ovmf/ovmf/0003-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch create mode 100644 meta/recipes-core/ovmf/ovmf/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch create mode 100644 meta/recipes-core/ovmf/ovmf/ovmf-shell-image.wks create mode 100644 meta/recipes-core/ovmf/ovmf_git.bb create mode 100644 meta/recipes-extended/iasl/iasl_20120215.bb create mode 100644 meta/recipes-extended/iasl/iasl_20150410.bb create mode 100644 meta/recipes-extended/iasl/iasl_20150515.bb
Signature · 1 line
2.1.4
PATCH 1/9 ovmf: move from meta-luv to OE-core
From: meta-luv <[email protected]>
This is an unmodified copy of github.com/01org/luv-yocto/meta-luv/recipes-core/ovmf revision 4be4329.
--- ...s-Force-tools-variables-to-host-toolchain.patch | 48 ++++++++ .../ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch | 110 +++++++++++++++++++ ...0002-ovmf-update-path-to-native-BaseTools.patch | 32 ++++++ ...makefile-adjust-to-build-in-under-bitbake.patch | 39 +++++++ meta/recipes-core/ovmf/ovmf_git.bb | 121 +++++++++++++++++++++ 5 files changed, 350 insertions(+) create mode 100644 meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch create mode 100644 meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch create mode 100644 meta/recipes-core/ovmf/ovmf/0002-ovmf-update-path-to-native-BaseTools.patch create mode 100644 meta/recipes-core/ovmf/ovmf/0003-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch create mode 100644 meta/recipes-core/ovmf/ovmf_git.bb
meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch new file +48 -0
@@ -0,0 +1,48 @@ +From 6e24bde1979c2d7149b37d142fb882dfde0e9770 Mon Sep 17 00:00:00 2001 +From: Matt Fleming <[email protected]> +Date: Fri, 27 Jun 2014 11:12:18 +0100 +Subject: [PATCH] BaseTools: Force tools variables to host toolchain + +Signed-off-by: Matt Fleming <[email protected]> +--- + BaseTools/Source/C/Makefiles/app.makefile | 7 +++++++ + BaseTools/Source/C/VfrCompile/GNUmakefile | 5 +++++ + 2 files changed, 12 insertions(+) + +diff --git a/BaseTools/Source/C/Makefiles/app.makefile b/BaseTools/Source/C/Makefiles/app.makefile +index 19269a1..62aad0f 100644 +--- a/BaseTools/Source/C/Makefiles/app.makefile ++++ b/BaseTools/Source/C/Makefiles/app.makefile +@@ -16,6 +16,13 @@ include $(MAKEROOT)/Makefiles/header.makefile + + APPLICATION = $(MAKEROOT)/bin/$(APPNAME) + ++CC = gcc ++CXX = g++ ++AS = gcc ++AR = ar ++LD = ld ++LINKER = $(CC) ++ + .PHONY:all + all: $(MAKEROOT)/bin $(APPLICATION) + +diff --git a/BaseTools/Source/C/VfrCompile/GNUmakefile b/BaseTools/Source/C/VfrCompile/GNUmakefile +index 82005e1..5ac5f7e 100644 +--- a/BaseTools/Source/C/VfrCompile/GNUmakefile ++++ b/BaseTools/Source/C/VfrCompile/GNUmakefile +@@ -26,6 +26,11 @@ OBJECTS = AParser.o DLexerBase.o ATokenBuffer.o EfiVfrParser.o VfrLexer.o VfrSyn + + VFR_CPPFLAGS = -DPCCTS_USE_NAMESPACE_STD $(CPPFLAGS) + ++CC = gcc ++CXX = g++ ++AS = gcc ++AR = ar ++LD = ld + LINKER = $(BUILD_CXX) + + EXTRA_CLEAN_OBJECTS = EfiVfrParser.cpp EfiVfrParser.h VfrParser.dlg VfrTokens.h VfrLexer.cpp VfrLexer.h VfrSyntax.cpp tokens.h +-- +1.9.0 +
meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch new file +110 -0
110 lines not on this page · raw message
meta/recipes-core/ovmf/ovmf/0002-ovmf-update-path-to-native-BaseTools.patch new file +32 -0
@@ -0,0 +1,32 @@ +From 9e632e3f9edd09632cc877dff6ea57608f979aab Mon Sep 17 00:00:00 2001 +From: Ricardo Neri <[email protected]> +Date: Thu, 9 Jun 2016 02:23:01 -0700 +Subject: [PATCH] ovmf: update path to native BaseTools + +BaseTools is a set of utilities to build EDK-based firmware. These utilities +are used during the build process. Thus, they need to be built natively. +When cross-compiling, we need to provide a path to the location of these +tools. The BBAKE_EDK_TOOLS_PATH string is used as a pattern to be replaced +with the appropriate location before building. + +Signed-off-by: Ricardo Neri <[email protected]> +--- + OvmfPkg/build.sh | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh +index eb5eb73..9058fca 100755 +--- a/OvmfPkg/build.sh ++++ b/OvmfPkg/build.sh +@@ -30,7 +30,7 @@ then + # this assumes svn pulls have the same root dir + # export EDK_TOOLS_PATH=`pwd`/../BaseTools + # This version is for the tools source in edk2 +- export EDK_TOOLS_PATH=`pwd`/BaseTools ++ export EDK_TOOLS_PATH=BBAKE_EDK_TOOLS_PATH/BaseTools + echo $EDK_TOOLS_PATH + source edksetup.sh BaseTools + else +-- +2.8.1 +
meta/recipes-core/ovmf/ovmf/0003-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch new file +39 -0
@@ -0,0 +1,39 @@ +From 2320650c6d381b914fe91b2dedaa5870279a8bcf Mon Sep 17 00:00:00 2001 +From: Ricardo Neri <[email protected]> +Date: Sun, 27 Nov 2016 18:42:55 -0800 +Subject: [PATCH] BaseTools: makefile: adjust to build in under bitbake + +Prepend the build flags with those of bitbake. This is to build +using the bitbake native sysroot include and library directories. + +Signed-off-by: Ricardo Neri <[email protected]> +--- + BaseTools/Source/C/Makefiles/header.makefile | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +diff --git a/BaseTools/Source/C/Makefiles/header.makefile b/BaseTools/Source/C/Makefiles/header.makefile +index 821d114..fe0f08b 100644 +--- a/BaseTools/Source/C/Makefiles/header.makefile ++++ b/BaseTools/Source/C/Makefiles/header.makefile +@@ -44,14 +44,14 @@ ARCH_INCLUDE = -I $(MAKEROOT)/Include/AArch64/ + endif + + INCLUDE = $(TOOL_INCLUDE) -I $(MAKEROOT) -I $(MAKEROOT)/Include/Common -I $(MAKEROOT)/Include/ -I $(MAKEROOT)/Include/IndustryStandard -I $(MAKEROOT)/Common/ -I .. -I . $(ARCH_INCLUDE) +-BUILD_CPPFLAGS = $(INCLUDE) -O2 ++BUILD_CPPFLAGS := $(BUILD_CPPFLAGS) $(INCLUDE) -O2 + ifeq ($(DARWIN),Darwin) + # assume clang or clang compatible flags on OS X +-BUILD_CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-deprecated-declarations -Wno-self-assign -Wno-unused-result -nostdlib -c -g ++BUILD_CFLAGS := $(BUILD_CFLAGS) -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-deprecated-declarations -Wno-self-assign -Wno-unused-result -nostdlib -c -g + else +-BUILD_CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-deprecated-declarations -Wno-unused-result -nostdlib -c -g ++BUILD_CFLAGS := $(BUILD_CFLAGS) -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-deprecated-declarations -Wno-unused-result -nostdlib -c -g + endif +-BUILD_LFLAGS = ++BUILD_LFLAGS := $(LDFLAGS) + BUILD_CXXFLAGS = + + ifeq ($(ARCH), IA32) +-- +2.9.3 +
meta/recipes-core/ovmf/ovmf_git.bb new file +121 -0
121 lines not on this page · raw message
Signature · 1 line
2.1.4
PATCH 2/9 iasl: move from meta-luv to OE-core
In reply to Patrick OhlyFrom: meta-luv <[email protected]>
This is an unmodified copy of github.com/01org/luv-yocto/meta-luv/recipes-extended/iasl revision 4be4329.
iasl is also provided by the meta-oe layer's acpica recipe. iasl is a bit simpler and thus seems more suitable for OE-core.
When the meta-oe layer is active, PREFERRED_PROVIDER_iasl-native must be set to avoid a warning. It can be set to "acpica-native" when something from acpica besides just iasl is needed.
--- meta/recipes-extended/iasl/iasl_20120215.bb | 27 +++++++++++++++++++++++++++ meta/recipes-extended/iasl/iasl_20150410.bb | 27 +++++++++++++++++++++++++++ meta/recipes-extended/iasl/iasl_20150515.bb | 27 +++++++++++++++++++++++++++ 3 files changed, 81 insertions(+) create mode 100644 meta/recipes-extended/iasl/iasl_20120215.bb create mode 100644 meta/recipes-extended/iasl/iasl_20150410.bb create mode 100644 meta/recipes-extended/iasl/iasl_20150515.bb
meta/recipes-extended/iasl/iasl_20120215.bb new file +27 -0
@@ -0,0 +1,27 @@ +DESCRIPTION = "This is a cross development C compiler, assembler and linker environment for the production of 8086 executables (Optionally MSDOS COM)" +HOMEPAGE = "http://www.acpica.org/" +LICENSE = "Intel-ACPI" +LIC_FILES_CHKSUM = "file://asldefine.h;endline=115;md5=d4d7cf809b8b5e03131327b3f718e8f0" +SECTION = "console/tools" +PR="r1" + +DEPENDS="flex-native bison-native" + +SRC_URI="https://acpica.org/sites/acpica/files/acpica-unix-${PV}.tar.gz" + +SRC_URI[md5sum] = "324c89e5bb9002e2711e0494290ceacc" +SRC_URI[sha256sum] = "b2b497415f29ddbefe7be8b9429b62c1f1f6e1ec11456928e4e7da86578e5b8d" + +S="${WORKDIR}/acpica-unix-${PV}/source/compiler" + +NATIVE_INSTALL_WORKS = "1" +BBCLASSEXTEND = "native" + +do_compile() { + CFLAGS="-Wno-error=redundant-decls" $MAKE +} + +do_install() { + mkdir -p ${D}${prefix}/bin + cp ${S}/iasl ${D}${prefix}/bin +}
meta/recipes-extended/iasl/iasl_20150410.bb new file +27 -0
@@ -0,0 +1,27 @@ +DESCRIPTION = "This is a cross development C compiler, assembler and linker environment for the production of 8086 executables (Optionally MSDOS COM)" +HOMEPAGE = "http://www.acpica.org/" +LICENSE = "Intel-ACPI" +LIC_FILES_CHKSUM = "file://Makefile;endline=22;md5=b15414d545d190713f1bab9023dba3be" +SECTION = "console/tools" +PR="r1" + +DEPENDS="flex-native bison-native" + +SRC_URI="https://acpica.org/sites/acpica/files/acpica-unix-${PV}.tar.gz" + +SRC_URI[md5sum] = "7b49c79728dde65ab1ba4edbee6f0b22" +SRC_URI[sha256sum] = "1dce8d9edeb234fd553806987471f6206f429c2aab45556f62a5b2bfe2464875" + +S="${WORKDIR}/acpica-unix-${PV}" + +NATIVE_INSTALL_WORKS = "1" +BBCLASSEXTEND = "native" + +do_compile() { + make iasl +} + +do_install() { + mkdir -p ${D}${prefix}/bin + cp ${S}/generate/unix/bin/iasl ${D}${prefix}/bin +}
meta/recipes-extended/iasl/iasl_20150515.bb new file +27 -0
@@ -0,0 +1,27 @@ +DESCRIPTION = "This is a cross development C compiler, assembler and linker environment for the production of 8086 executables (Optionally MSDOS COM)" +HOMEPAGE = "http://www.acpica.org/" +LICENSE = "Intel-ACPI" +LIC_FILES_CHKSUM = "file://Makefile;endline=22;md5=b15414d545d190713f1bab9023dba3be" +SECTION = "console/tools" +PR="r1" + +DEPENDS="flex-native bison-native" + +SRC_URI="https://acpica.org/sites/acpica/files/acpica-unix-${PV}.tar.gz" + +SRC_URI[md5sum] = "c8c128b2d4859b52bc9c802faba2e908" +SRC_URI[sha256sum] = "bfa1f296a3cc13421331dbaad3b62e0184678cc312104c3e8ac799ead0742c45" + +S="${WORKDIR}/acpica-unix-${PV}" + +NATIVE_INSTALL_WORKS = "1" +BBCLASSEXTEND = "native" + +do_compile() { + make iasl +} + +do_install() { + mkdir -p ${D}${prefix}/bin + cp ${S}/generate/unix/bin/iasl ${D}${prefix}/bin +}
Signature · 1 line
2.1.4
PATCH 3/9 ovmf: explicitly depend on nasm-native
In reply to Patrick OhlyFixes a build issue when nasm was not build already because of something else.
--- meta/recipes-core/ovmf/ovmf_git.bb | 2 ++ 1 file changed, 2 insertions(+)
meta/recipes-core/ovmf/ovmf_git.bb +2 -0
@@ -20,6 +20,8 @@ DEPENDS_class-native="util-linux-native iasl-native ossp-uuid-native" DEPENDS_class-target="ovmf-native" +DEPENDS_append = " nasm-native" + EDK_TOOLS_DIR="edk2_basetools" # OVMF has trouble building with the default optimization of -O2.
Signature · 1 line
2.1.4
PATCH 4/9 ovmf: deploy firmware in image directory
In reply to Patrick OhlyWhen used with '-drive if=pflash', qemu will store UEFI variables inside the firmware image file. That is unexpected for a file located in the sysroot, which should be read-only, while it is normal for image files in the deploy/images directory. Therefore that directory is a better place for use with runqemu.
The name was chose so that "runqemu ovmf" can be used as shorthand for "runqemu <full path>/ovmf.qcow2" by treating "ovmf" as the base name of the BIOS file. "ovmf_secboot.qcow2" is meant to be used for the Secure Boot enabled BIOS. qcow2 is used because it is needed for "savevm" snapshots of a virtual machine.
Alternatively, OVMF_CODE.fd (read-only) and OVMF_VARS.fd (read/write) could be used. That would then allow updating the firmware of an existing machine without wiping out the variables set earlier. Configuring that in qemu would be more complicated, so for now the simpler approach with combined code and variable store is used.
--- meta/recipes-core/ovmf/ovmf_git.bb | 33 +++++++++++++++++++++++---------- 1 file changed, 23 insertions(+), 10 deletions(-)
meta/recipes-core/ovmf/ovmf_git.bb +23 -10
@@ -16,7 +16,7 @@ PARALLEL_MAKE = "" S = "${WORKDIR}/git" -DEPENDS_class-native="util-linux-native iasl-native ossp-uuid-native" +DEPENDS_class-native="util-linux-native iasl-native ossp-uuid-native qemu-native" DEPENDS_class-target="ovmf-native"
@@ -97,9 +97,20 @@ do_compile_class-target() { OVMF_ARCH="IA32" fi + # ${WORKDIR}/ovmf is a well-known location where do_install and + # do_deploy will be able to find the files. + rm -rf ${WORKDIR}/ovmf + mkdir ${WORKDIR}/ovmf + OVMF_DIR_SUFFIX="X64" + if [ "${TARGET_ARCH}" != "x86_64" ] ; then + OVMF_DIR_SUFFIX="Ia32" # Note the different capitalization + fi FIXED_GCCVER=$(fixup_target_tools ${GCC_VER}) - echo FIXED_GCCVER is ${FIXED_GCCVER} + bbnote FIXED_GCCVER is ${FIXED_GCCVER} + build_dir="${S}/Build/Ovmf$OVMF_DIR_SUFFIX/RELEASE_${FIXED_GCCVER}" + ${S}/OvmfPkg/build.sh -a $OVMF_ARCH -b RELEASE -t ${FIXED_GCCVER} + ln ${build_dir}/FV/OVMF.fd ${WORKDIR}/ovmf/OVMF.fd } do_install_class-native() {
@@ -108,16 +119,18 @@ do_install_class-native() { } do_install_class-target() { - OVMF_DIR_SUFFIX="X64" - if [ "${TARGET_ARCH}" != "x86_64" ] ; then - OVMF_DIR_SUFFIX="Ia32" # Note the different capitalization - fi + # Traditional location. install -d ${D}${datadir}/ovmf + install -m 0755 ${WORKDIR}/ovmf/OVMF.fd ${D}${datadir}/ovmf/bios.bin +} - FIXED_GCCVER=$(fixup_target_tools ${GCC_VER}) - build_dir="${S}/Build/Ovmf$OVMF_DIR_SUFFIX/RELEASE_${FIXED_GCCVER}" - install -m 0755 ${build_dir}/FV/OVMF.fd \ - ${D}${datadir}/ovmf/bios.bin +inherit deploy +do_deploy() { +} +do_deploy_class-target() { + # For use with "runqemu ovmf". + qemu-img convert -f raw -O qcow2 ${WORKDIR}/ovmf/OVMF.fd ${DEPLOYDIR}/ovmf.qcow2 } +addtask do_deploy after do_compile before do_build BBCLASSEXTEND = "native"
Signature · 1 line
2.1.4
PATCH 5/9 ovmf_git.bb: enable parallel compilation
In reply to Patrick OhlyThe Fedora srpm [1] seems to have no problems with parallel compilation, so let's also use that for the target. The native tools however indeed have dependency problems:
| test_Ecc_CParser (CheckPythonSyntax.Tests) ... gcc -o ../bin/EfiRom -L/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/usr/lib -L/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/lib -Wl,-rpath-link,/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/usr/lib -Wl,-rpath-link,/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/lib -Wl,-rpath,/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/usr/lib -Wl,-rpath,/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/lib -Wl,-O1 EfiRom.o -L../libs -lCommon | /usr/bin/ld: cannot find -lCommon | collect2: error: ld returned 1 exit status
ERROR: Task (virtual:native:.../meta/recipes-core/ovmf/ovmf_git.bb:do_compile) failed with exit code '1'
[1] https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/edk2.spec
--- meta/recipes-core/ovmf/ovmf_git.bb | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
meta/recipes-core/ovmf/ovmf_git.bb +3 -2
@@ -12,7 +12,7 @@ SRC_URI = "git://github.com/tianocore/edk2.git;branch=master \ SRCREV="4575a602ca6072ee9d04150b38bfb143cbff8588" -PARALLEL_MAKE = "" +PARALLEL_MAKE_class-native = "" S = "${WORKDIR}/git"
@@ -92,6 +92,7 @@ do_compile_class-native() { do_compile_class-target() { export LFLAGS="${LDFLAGS}" + PARALLEL_JOBS="${@ '${PARALLEL_MAKE}'.replace('-j', '-n')}" OVMF_ARCH="X64" if [ "${TARGET_ARCH}" != "x86_64" ] ; then OVMF_ARCH="IA32"
@@ -109,7 +110,7 @@ do_compile_class-target() { bbnote FIXED_GCCVER is ${FIXED_GCCVER} build_dir="${S}/Build/Ovmf$OVMF_DIR_SUFFIX/RELEASE_${FIXED_GCCVER}" - ${S}/OvmfPkg/build.sh -a $OVMF_ARCH -b RELEASE -t ${FIXED_GCCVER} + ${S}/OvmfPkg/build.sh $PARALLEL_JOBS -a $OVMF_ARCH -b RELEASE -t ${FIXED_GCCVER} ln ${build_dir}/FV/OVMF.fd ${WORKDIR}/ovmf/OVMF.fd }
Signature · 1 line
2.1.4
PATCH 6/9 ovmf_git.bb: enable Secure Boot
In reply to Patrick OhlyThe recipe now compiles OVMF twice, once without Secure Boot, once with. This is the same approach as in
https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/edk2.spec
The results are "ovmf.qcow2" and "ovmf.secboot.qcow2" in the image deploy directory, so
runqemu <machine> <image> ovmf.secboot
will boot with Secure Boot enabled.
In contrast to Fedora, no attempt is made to strip potentially patent encumbered algorithms out of the OpenSSL archive. OVMF does not use the ones considered problematic for Fedora, so this shouldn't be a problem.
--- meta/recipes-core/ovmf/ovmf_git.bb | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-)
meta/recipes-core/ovmf/ovmf_git.bb +26 -1
@@ -1,6 +1,6 @@ DESCRIPTION = "OVMF - UEFI firmware for Qemu and KVM" HOMEPAGE = "http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF" -LICENSE = "BSD" +LICENSE = "BSD & OpenSSL" LIC_FILES_CHKSUM = "file://OvmfPkg/License.txt;md5=343dc88e82ff33d042074f62050c3496" SRC_URI = "git://github.com/tianocore/edk2.git;branch=master \
@@ -10,7 +10,13 @@ SRC_URI = "git://github.com/tianocore/edk2.git;branch=master \ file://0003-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch \ " +SRC_URI_append_class-target = " \ + http://www.openssl.org/source/openssl-1.0.2j.tar.gz;name=openssl;subdir=${S}/CryptoPkg/Library/OpensslLib \ +" + SRCREV="4575a602ca6072ee9d04150b38bfb143cbff8588" +SRC_URI[openssl.md5sum] = "96322138f0b69e61b7212bc53d5e912b" +SRC_URI[openssl.sha256sum] = "e7aff292be21c259c6af26469c7a9b3ba26e9abaaffd325e3dccc9785256c431" PARALLEL_MAKE_class-native = ""
@@ -30,6 +36,10 @@ BUILD_OPTIMIZATION="-pipe" # OVMF supports IA only, although it could conceivably support ARM someday. COMPATIBLE_HOST='(i.86|x86_64).*' +# Additional build flags for OVMF with Secure Boot. +# Fedora also uses "-D SMM_REQUIRE -D EXCLUDE_SHELL_FROM_FD". +OVMF_SECURE_BOOT_FLAGS = "-DSECURE_BOOT_ENABLE=TRUE" + do_patch_append_class-native() { bb.build.exec_func('do_fix_iasl', d) bb.build.exec_func('do_fix_toolchain', d)
@@ -110,8 +120,22 @@ do_compile_class-target() { bbnote FIXED_GCCVER is ${FIXED_GCCVER} build_dir="${S}/Build/Ovmf$OVMF_DIR_SUFFIX/RELEASE_${FIXED_GCCVER}" + bbnote "Building without Secure Boot." + rm -rf ${S}/Build/Ovmf$OVMF_DIR_SUFFIX ${S}/OvmfPkg/build.sh $PARALLEL_JOBS -a $OVMF_ARCH -b RELEASE -t ${FIXED_GCCVER} ln ${build_dir}/FV/OVMF.fd ${WORKDIR}/ovmf/OVMF.fd + + # See CryptoPkg/Library/OpensslLib/Patch-HOWTO.txt and + # https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/ for + # building with Secure Boot enabled. + bbnote "Building with Secure Boot." + rm -rf ${S}/Build/Ovmf$OVMF_DIR_SUFFIX + if ! [ -f ${S}/CryptoPkg/Library/OpensslLib/openssl-*/edk2-patch-applied ]; then + ( cd ${S}/CryptoPkg/Library/OpensslLib/openssl-* && patch -p1 <$(echo ../EDKII_openssl-*.patch) && touch edk2-patch-applied ) + fi + ( cd ${S}/CryptoPkg/Library/OpensslLib/ && ./Install.sh ) + ${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 } do_install_class-native() {
@@ -131,6 +155,7 @@ do_deploy() { do_deploy_class-target() { # For use with "runqemu ovmf". qemu-img convert -f raw -O qcow2 ${WORKDIR}/ovmf/OVMF.fd ${DEPLOYDIR}/ovmf.qcow2 + qemu-img convert -f raw -O qcow2 ${WORKDIR}/ovmf/OVMF.secboot.fd ${DEPLOYDIR}/ovmf.secboot.qcow2 } addtask do_deploy after do_compile before do_build
Signature · 1 line
2.1.4
PATCH 7/9 runqemu: let command line parameters override defaults
In reply to Patrick OhlyIt may be necessary to override the parameters gathered for the qemu invocation. For example, the qemux86 machine configuration sets "-vga vmware", but when using OVMF as BIOS, only "-vga std" is supported.
By putting the parameters derived from custom runqemu parameters like "qemuparams" after the parameters derived from the machine configuration the user gets the possibility to override those.
--- scripts/runqemu | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
scripts/runqemu +1 -1
@@ -926,7 +926,7 @@ class BaseConfig(object): check_libgl(qemu_bin) - self.qemu_opt = "%s %s %s %s %s" % (qemu_bin, self.get('NETWORK_CMD'), self.qemu_opt_script, self.get('ROOTFS_OPTIONS'), self.get('QB_OPT_APPEND')) + self.qemu_opt = "%s %s %s %s %s" % (qemu_bin, self.get('NETWORK_CMD'), self.get('ROOTFS_OPTIONS'), self.get('QB_OPT_APPEND'), self.qemu_opt_script) if self.snapshot: self.qemu_opt += " -snapshot"
Signature · 1 line
2.1.4
PATCH 8/9 runqemu: support UEFI with OVMF firmware
In reply to Patrick OhlyIn the simplest case, "runqemu qemux86 <some-image> qcow2 ovmf" for an EFI-enabled image in the qcow2 format will locate the OVMF firmware file, override the graphics hardware with "-vga std" because that is all that OVMF supports, and boot with UEFI enabled. This depends on "bitbake ovmf" deploying a "ovmf.qcow2" firmware file in the image deploy directory.
The firmware file is activated as a flash drive instead of using the qemu BIOS parameters, because that is the recommended method
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764918#47) as it allows storing UEFI variables in the file.
Instead of just "ovmf", a full path to an existing file can also be used, just as with the rootfs. That may be useful when making a permanent copy of the virtual machine data files.
--- scripts/runqemu | 37 ++++++++++++++++++++++++++++++++++++- 1 file changed, 36 insertions(+), 1 deletion(-)
scripts/runqemu +36 -1
@@ -74,6 +74,7 @@ of the following environment variables (in any order): kvm-vhost - enable KVM with vhost when running x86/x86_64 (VT-capable CPU required) publicvnc - enable a VNC server open to all hosts audio - enable audio + [*/]ovmf* - OVMF BIOS file or base name for booting with UEFI tcpserial=<port> - specify tcp serial port number biosdir=<dir> - specify custom bios dir biosfilename=<filename> - specify bios filename
@@ -162,6 +163,12 @@ class BaseConfig(object): self.clean_nfs_dir = False self.nfs_server = '' self.rootfs = '' + # File name of a OVMF BIOS file, to be added with -drive if=pflash. + # Found in the same places as the rootfs, with or without one of + # these suffices: qcow2, bin. + # Setting one also adds "-vga std" because that is all that + # OVMF supports. + self.ovmf_bios = '' self.qemuboot = '' self.qbconfload = False self.kernel = ''
@@ -369,6 +376,8 @@ class BaseConfig(object): self.qemu_opt_script += ' %s' % arg[len('qemuparams='):] elif arg.startswith('bootparams='): self.kernel_cmdline_script += ' %s' % arg[len('bootparams='):] + elif os.path.basename(arg).startswith('ovmf'): + self.ovmf_bios = arg elif os.path.exists(arg) or (re.search(':', arg) and re.search('/', arg)): self.check_arg_path(os.path.abspath(arg)) elif re.search('-image-', arg):
@@ -472,6 +481,20 @@ class BaseConfig(object): if not os.path.exists(self.rootfs): raise Exception("Can't find rootfs: %s" % self.rootfs) + def check_ovmf(self): + """Check and set full path for OVMF BIOS file.""" + + if self.ovmf_bios is None or os.path.exists(self.ovmf_bios): + return + + for suffix in ('qcow2', 'bin'): + ovmf_bios = '%s/%s.%s' % (self.get('DEPLOY_DIR_IMAGE'), self.ovmf_bios, suffix) + if os.path.exists(ovmf_bios): + self.ovmf_bios = ovmf_bios + return + + raise Exception("Can't find OVMF BIOS: %s" % self.ovmf_bios) + def check_kernel(self): """Check and set kernel, dtb""" # The vm image doesn't need a kernel
@@ -562,6 +585,7 @@ class BaseConfig(object): self.check_kvm() self.check_fstype() self.check_rootfs() + self.check_ovmf() self.check_kernel() self.check_biosdir() self.check_mem()
@@ -670,6 +694,8 @@ class BaseConfig(object): print('NFS_DIR: [%s]' % self.nfs_dir) else: print('ROOTFS: [%s]' % self.rootfs) + if self.ovmf_bios: + print('OVMF: [%s]' % self.ovmf_bios) print('CONFFILE: [%s]' % self.qemuboot) print('')
@@ -926,7 +952,16 @@ class BaseConfig(object): check_libgl(qemu_bin) - self.qemu_opt = "%s %s %s %s %s" % (qemu_bin, self.get('NETWORK_CMD'), self.get('ROOTFS_OPTIONS'), self.get('QB_OPT_APPEND'), self.qemu_opt_script) + self.qemu_opt = "%s %s %s %s" % (qemu_bin, self.get('NETWORK_CMD'), self.get('ROOTFS_OPTIONS'), self.get('QB_OPT_APPEND')) + + if self.ovmf_bios: + format = self.ovmf_bios.rsplit('.', 1)[-1] + self.qemu_opt += ' -drive if=pflash,format=%s,file=%s' % (format, self.ovmf_bios) + # OVMF only supports normal VGA, i.e. we need to override a -vga vmware + # that gets added for example for normal qemux86. + self.qemu_opt += ' -vga std' + + self.qemu_opt += ' ' + self.qemu_opt_script if self.snapshot: self.qemu_opt += " -snapshot"
Signature · 1 line
2.1.4
PATCH 9/9 ovmf: build image which enrolls standard keys
In reply to Patrick OhlyWhen 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.
--- meta/recipes-core/ovmf/ovmf-shell-image.bb | 22 + ...ollDefaultKeys-application-for-enrolling-.patch | 1123 ++++++++++++++++++++ meta/recipes-core/ovmf/ovmf/ovmf-shell-image.wks | 4 + meta/recipes-core/ovmf/ovmf_git.bb | 16 + 4 files changed, 1165 insertions(+) create mode 100644 meta/recipes-core/ovmf/ovmf-shell-image.bb create mode 100644 meta/recipes-core/ovmf/ovmf/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch create mode 100644 meta/recipes-core/ovmf/ovmf/ovmf-shell-image.wks
meta/recipes-core/ovmf/ovmf-shell-image.bb new file +22 -0
@@ -0,0 +1,22 @@ +# This needs to run before image.bbclass reads IMAGE_FSTYPES, +# which is guaranteed by the ordering of anonymous functions +# in a recipe. +python () { + # Ignore customization of IMAGE_FSTYPES because + # for this image recipe, only the .wic format + # with a single vfat partition makes sense. + d.setVar('IMAGE_FSTYPES', 'wic') +} +WKS_FILE = "ovmf/ovmf-shell-image.wks" + +inherit image + +# We want a minimal image with just ovmf-shell-efi +# unpacked in it. We avoid installing unnecessary +# stuff as much as possible, but some things still +# get through and need to be removed. +PACKAGE_INSTALL = "ovmf-shell-efi" +LINGUAS_INSTALL = "" +do_image () { + rm -rf `ls -d ${IMAGE_ROOTFS}/* | grep -v efi` +}
meta/recipes-core/ovmf/ovmf/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch new file +1123 -0
1,123 lines not on this page · raw message
meta/recipes-core/ovmf/ovmf/ovmf-shell-image.wks new file +4 -0
@@ -0,0 +1,4 @@ +# short-description: Create an EFI disk image with just the EFI system partition + +part / --source rootfs --ondisk sda --fstype=vfat --align 1024 +bootloader --ptable gpt --timeout=5
meta/recipes-core/ovmf/ovmf_git.bb +16 -0
@@ -12,6 +12,7 @@ SRC_URI = "git://github.com/tianocore/edk2.git;branch=master \ SRC_URI_append_class-target = " \ http://www.openssl.org/source/openssl-1.0.2j.tar.gz;name=openssl;subdir=${S}/CryptoPkg/Library/OpensslLib \ + file://0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch \ " SRCREV="4575a602ca6072ee9d04150b38bfb143cbff8588"
@@ -136,6 +137,9 @@ do_compile_class-target() { ( cd ${S}/CryptoPkg/Library/OpensslLib/ && ./Install.sh ) ${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 + for i in Shell.efi EnrollDefaultKeys.efi; do + ln ${build_dir}/${OVMF_ARCH}/$i ${WORKDIR}/ovmf/$i + done } do_install_class-native() {
@@ -147,8 +151,20 @@ do_install_class-target() { # Traditional location. install -d ${D}${datadir}/ovmf install -m 0755 ${WORKDIR}/ovmf/OVMF.fd ${D}${datadir}/ovmf/bios.bin + # 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 + install ${WORKDIR}/ovmf/EnrollDefaultKeys.efi ${D} } +PACKAGES =+ "ovmf-shell-efi" +FILES_ovmf-shell-efi = " \ + EnrollDefaultKeys.efi \ + efi/ \ +" + inherit deploy do_deploy() { }
Signature · 1 line
2.1.4
Re: [PATCH 2/9] iasl: move from meta-luv to OE-core
In reply to Patrick OhlyHi Patrick,
Quoted 8 lines · Patrick Ohly
From: meta-luv <[email protected]>
This is an unmodified copy of github.com/01org/luv-yocto/meta-luv/recipes-extended/iasl revision 4be4329.
iasl is also provided by the meta-oe layer's acpica recipe. iasl is a bit simpler and thus seems more suitable for OE-core.
Simpler in what sense? acpica recipe is trivial and provide fully acpica tools. Would you mind to import meta-oe acpica recipe instead of providing a reduced set of acpica for not much benefit?
Quoted 116 lines
When the meta-oe layer is active, PREFERRED_PROVIDER_iasl-native must be set to avoid a warning. It can be set to "acpica-native" when something from acpica besides just iasl is needed.
Signed-off-by Patrick Ohly <[email protected]>--- meta/recipes-extended/iasl/iasl_20120215.bb | 27 +++++++++++++++++++++++++++ meta/recipes-extended/iasl/iasl_20150410.bb | 27 +++++++++++++++++++++++++++ meta/recipes-extended/iasl/iasl_20150515.bb | 27 +++++++++++++++++++++++++++ 3 files changed, 81 insertions(+) create mode 100644 meta/recipes-extended/iasl/iasl_20120215.bb create mode 100644 meta/recipes-extended/iasl/iasl_20150410.bb create mode 100644 meta/recipes-extended/iasl/iasl_20150515.bbmeta/recipes-extended/iasl/iasl_20120215.bb new file +27
-0@@ -0,0 +1,27 @@ +DESCRIPTION = "This is a cross development C compiler, assembler and linker environment for the production of 8086 executables (Optionally MSDOS COM)" +HOMEPAGE = "http://www.acpica.org/" +LICENSE = "Intel-ACPI" +LIC_FILES_CHKSUM = "file://asldefine.h;endline=115;md5=d4d7cf809b8b5e03131327b3f718e8f0" +SECTION = "console/tools" +PR="r1" + +DEPENDS="flex-native bison-native" + +SRC_URI="https://acpica.org/sites/acpica/files/acpica-unix-${PV}.tar.gz" + +SRC_URI[md5sum] = "324c89e5bb9002e2711e0494290ceacc" +SRC_URI[sha256sum] = "b2b497415f29ddbefe7be8b9429b62c1f1f6e1ec11456928e4e7da86578e5b8d" + +S="${WORKDIR}/acpica-unix-${PV}/source/compiler" + +NATIVE_INSTALL_WORKS = "1" +BBCLASSEXTEND = "native" + +do_compile() { + CFLAGS="-Wno-error=redundant-decls" $MAKE +} + +do_install() { + mkdir -p ${D}${prefix}/bin + cp ${S}/iasl ${D}${prefix}/bin +}meta/recipes-extended/iasl/iasl_20150410.bb new file +27
-0@@ -0,0 +1,27 @@ +DESCRIPTION = "This is a cross development C compiler, assembler and linker environment for the production of 8086 executables (Optionally MSDOS COM)" +HOMEPAGE = "http://www.acpica.org/" +LICENSE = "Intel-ACPI" +LIC_FILES_CHKSUM = "file://Makefile;endline=22;md5=b15414d545d190713f1bab9023dba3be" +SECTION = "console/tools" +PR="r1" + +DEPENDS="flex-native bison-native" + +SRC_URI="https://acpica.org/sites/acpica/files/acpica-unix-${PV}.tar.gz" + +SRC_URI[md5sum] = "7b49c79728dde65ab1ba4edbee6f0b22" +SRC_URI[sha256sum] = "1dce8d9edeb234fd553806987471f6206f429c2aab45556f62a5b2bfe2464875" + +S="${WORKDIR}/acpica-unix-${PV}" + +NATIVE_INSTALL_WORKS = "1" +BBCLASSEXTEND = "native" + +do_compile() { + make iasl +} + +do_install() { + mkdir -p ${D}${prefix}/bin + cp ${S}/generate/unix/bin/iasl ${D}${prefix}/bin +}meta/recipes-extended/iasl/iasl_20150515.bb new file +27
-1@@ -0,0 +1,27 @@ +DESCRIPTION = "This is a cross development C compiler, assembler and linker environment for the production of 8086 executables (Optionally MSDOS COM)" +HOMEPAGE = "http://www.acpica.org/" +LICENSE = "Intel-ACPI" +LIC_FILES_CHKSUM = "file://Makefile;endline=22;md5=b15414d545d190713f1bab9023dba3be" +SECTION = "console/tools" +PR="r1" + +DEPENDS="flex-native bison-native" + +SRC_URI="https://acpica.org/sites/acpica/files/acpica-unix-${PV}.tar.gz" + +SRC_URI[md5sum] = "c8c128b2d4859b52bc9c802faba2e908" +SRC_URI[sha256sum] = "bfa1f296a3cc13421331dbaad3b62e0184678cc312104c3e8ac799ead0742c45" + +S="${WORKDIR}/acpica-unix-${PV}" + +NATIVE_INSTALL_WORKS = "1" +BBCLASSEXTEND = "native" + +do_compile() { + make iasl +} + +do_install() { + mkdir -p ${D}${prefix}/bin + cp ${S}/generate/unix/bin/iasl ${D}${prefix}/bin +} --2.1.4
Quoted 5 lines
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Cheers,
Signature · 1 line
Fathi
Hi,
Quoted 21 lines · Patrick Ohly
There seems to be a consensus that supporting UEFI in OE-core for qemu would be valuable, and there have been some (stalled) attempts to add it. For reference, see:
[OE-core] [PATCH V3 0/3] Add UEFI firmware for qemux86*
[OE-core] Add ovmf-native to make qemu-native/runqemu support boot UEFI image?
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5654
https://github.com/01org/luv-yocto/issues/38This patch set includes the necessary recipes (ovmf and iasl from meta-luv), some improvements to them (in particular, enabling Secure Boot), and changes to runqemu to make it easier to boot with UEFI. A special image recipes builds an image which can be used to lock down a virtual machine by enrolling the "normal" pre-installed certificates.
I decided to keep the setup simple and use just a single file for UEFI code and variables because that makes the usage via runqemu very easy. See the "runqemu: support UEFI with OVMF firmware" patch for details. The downside is that the firmware can't be updated without loosing variables. I don't see a big need for long-lived virtual machine instances, but would like to hear from others about that.
Quoted 8 lines
What's missing is automated testing of this new feature. I'm open for suggestions here; right now I don't know enough about the automated testing in the AB to propose something.
I've discussed the usage of ovmf/iasl with Ricardo and he agreed that moving ovmf and iasl from meta-luv to OE-core makes sense. Ricardo, would you be willing to act as maintainer of it there, like you did in meta-luv?
fwiw, I've been maintaining acpica recipe in meta-oe, and will keep an eye here as well.
meta-luv supports both x86* and arm*, and we have an interest in having the same features available and working for qemuaarch64.
Quoted 50 lines
Beware that "git am --keep-cr" must be used to import the ovmf patches correctly.
The following changes since commit
5e21afc9395060b489156d3f90505a372b713f37:Revert "selftest/wic: extending test coverage for WIC script options" (2016-12-20 17:06:01 +0000)
are available in the git repository at:
git://github.com/pohly/openembedded-coresecure-boot
https://github.com/pohly/openembedded-core/tree/secure-bootPatrick Ohly (7):
ovmf: explicitly depend on nasm-native
ovmf: deploy firmware in image directory ovmf_git.bb: enable parallel compilation ovmf_git.bb: enable Secure Boot
runqemu: let command line parameters override defaults
runqemu: support UEFI with OVMF firmware
ovmf: build image which enrolls standard keysmeta-luv (2):
ovmf: move from meta-luv to OE-core
iasl: move from meta-luv to OE-coremeta/recipes-core/ovmf/ovmf-shell-image.bb | 22 + ...s-Force-tools-variables-to-host-toolchain.patch | 48 + .../ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch | 110 ++ ...0002-ovmf-update-path-to-native-BaseTools.patch | 32 + ...makefile-adjust-to-build-in-under-bitbake.patch | 39 + ...ollDefaultKeys-application-for-enrolling-.patch | 1123 ++++++++++++++++++++ meta/recipes-core/ovmf/ovmf/ovmf-shell-image.wks | 4 + meta/recipes-core/ovmf/ovmf_git.bb | 178 ++++ meta/recipes-extended/iasl/iasl_20120215.bb | 27 + meta/recipes-extended/iasl/iasl_20150410.bb | 27 + meta/recipes-extended/iasl/iasl_20150515.bb | 27 + scripts/runqemu | 37 +- 12 files changed, 1673 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-core/ovmf/ovmf-shell-image.bb create mode 100644 meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch create mode 100644 meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch create mode 100644 meta/recipes-core/ovmf/ovmf/0002-ovmf-update-path-to-native-BaseTools.patch create mode 100644 meta/recipes-core/ovmf/ovmf/0003-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch create mode 100644 meta/recipes-core/ovmf/ovmf/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch create mode 100644 meta/recipes-core/ovmf/ovmf/ovmf-shell-image.wks create mode 100644 meta/recipes-core/ovmf/ovmf_git.bb create mode 100644 meta/recipes-extended/iasl/iasl_20120215.bb create mode 100644 meta/recipes-extended/iasl/iasl_20150410.bb create mode 100644 meta/recipes-extended/iasl/iasl_20150515.bb
Quoted 8 lines
--
2.1.4--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Cheers,
Signature · 1 line
Fathi
Re: [PATCH 2/9] iasl: move from meta-luv to OE-core
In reply to Fathi BoudraQuoted 5 lines · Fathi Boudra
Quoted 2 lines · Patrick Ohly
iasl is also provided by the meta-oe layer's acpica recipe. iasl is a bit simpler and thus seems more suitable for OE-core.
Simpler in what sense?
Less code to compile, which might matter for people who just want a working UEFI for qemu and nothing else. I haven't measured the difference, though.
Quoted 3 lines
acpica recipe is trivial and provide fully acpica tools.
Would you mind to import meta-oe acpica recipe instead of providing a reduced set of acpica for not much benefit?
I don't have a strong opinion about this and would be fine with moving acpica to OE-core instead, too.
Signature · 6 lines
Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.
Re: [PATCH 2/9] iasl: move from meta-luv to OE-core
Quoted 10 lines · Patrick Ohly
Quoted 5 lines · Fathi Boudra
Quoted 2 lines · Patrick Ohly
iasl is also provided by the meta-oe layer's acpica recipe. iasl is a bit simpler and thus seems more suitable for OE-core.
Simpler in what sense?
Less code to compile, which might matter for people who just want a working UEFI for qemu and nothing else. I haven't measured the difference, though.
to build, it's taking 3-4 minutes on a 3 year old laptop (i5-2520m @ 2.5 Ghz).
Quoted 6 lines
Quoted 3 lines
acpica recipe is trivial and provide fully acpica tools.
Would you mind to import meta-oe acpica recipe instead of providing a reduced set of acpica for not much benefit?I don't have a strong opinion about this and would be fine with moving acpica to OE-core instead, too.
It would be nice. thanks.
Quoted 7 lines
--
Best Regards, Patrick OhlyThe content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.
Quoted 21 lines · Patrick Ohly
There seems to be a consensus that supporting UEFI in OE-core for qemu would be valuable, and there have been some (stalled) attempts to add it. For reference, see:
[OE-core] [PATCH V3 0/3] Add UEFI firmware for qemux86*
[OE-core] Add ovmf-native to make qemu-native/runqemu support boot UEFI image?
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5654
https://github.com/01org/luv-yocto/issues/38This patch set includes the necessary recipes (ovmf and iasl from meta-luv), some improvements to them (in particular, enabling Secure Boot), and changes to runqemu to make it easier to boot with UEFI. A special image recipes builds an image which can be used to lock down a virtual machine by enrolling the "normal" pre-installed certificates.
I decided to keep the setup simple and use just a single file for UEFI code and variables because that makes the usage via runqemu very easy. See the "runqemu: support UEFI with OVMF firmware" patch for details. The downside is that the firmware can't be updated without loosing variables. I don't see a big need for long-lived virtual machine instances, but would like to hear from others about that.
Quoted 3 lines
What's missing is automated testing of this new feature. I'm open for suggestions here; right now I don't know enough about the automated testing in the AB to propose something.
I guess that tests could be written for buildbot. In the LUV buildbot, we build OVMF as part of our sanity tests for LUV. We do it mostly because we need to boot some UEFI firmware in qemu, though. We don't extensively test OVMF. We also build OVMF with Secure Boot separately. Now that you have kindly written the recipe, we want to leverage it. :)
Quoted 5 lines
I've discussed the usage of ovmf/iasl with Ricardo and he agreed that moving ovmf and iasl from meta-luv to OE-core makes sense. Ricardo, would you be willing to act as maintainer of it there, like you did in meta-luv?
Yes, I can keep doing the same work I did in meta-luv for OVMF now in OE-core.
Thanks and BR,
Ricardo
Quoted 54 lines
Beware that "git am --keep-cr" must be used to import the ovmf patches correctly.
The following changes since commit
5e21afc9395060b489156d3f90505a372b713f37:Revert "selftest/wic: extending test coverage for WIC script options" (2016-12-20 17:06:01 +0000)
are available in the git repository at:
git://github.com/pohly/openembedded-coresecure-boot
https://github.com/pohly/openembedded-core/tree/secure-bootPatrick Ohly (7):
ovmf: explicitly depend on nasm-native
ovmf: deploy firmware in image directory ovmf_git.bb: enable parallel compilation ovmf_git.bb: enable Secure Boot
runqemu: let command line parameters override defaults
runqemu: support UEFI with OVMF firmware
ovmf: build image which enrolls standard keysmeta-luv (2):
ovmf: move from meta-luv to OE-core
iasl: move from meta-luv to OE-coremeta/recipes-core/ovmf/ovmf-shell-image.bb | 22 + ...s-Force-tools-variables-to-host-toolchain.patch | 48 + .../ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch | 110 ++ ...0002-ovmf-update-path-to-native-BaseTools.patch | 32 + ...makefile-adjust-to-build-in-under-bitbake.patch | 39 + ...ollDefaultKeys-application-for-enrolling-.patch | 1123 ++++++++++++++++++++ meta/recipes-core/ovmf/ovmf/ovmf-shell-image.wks | 4 + meta/recipes-core/ovmf/ovmf_git.bb | 178 ++++ meta/recipes-extended/iasl/iasl_20120215.bb | 27 + meta/recipes-extended/iasl/iasl_20150410.bb | 27 + meta/recipes-extended/iasl/iasl_20150515.bb | 27 + scripts/runqemu | 37 +- 12 files changed, 1673 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-core/ovmf/ovmf-shell-image.bb create mode 100644 meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch create mode 100644 meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch create mode 100644 meta/recipes-core/ovmf/ovmf/0002-ovmf-update-path-to-native-BaseTools.patch create mode 100644 meta/recipes-core/ovmf/ovmf/0003-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch create mode 100644 meta/recipes-core/ovmf/ovmf/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch create mode 100644 meta/recipes-core/ovmf/ovmf/ovmf-shell-image.wks create mode 100644 meta/recipes-core/ovmf/ovmf_git.bb create mode 100644 meta/recipes-extended/iasl/iasl_20120215.bb create mode 100644 meta/recipes-extended/iasl/iasl_20150410.bb create mode 100644 meta/recipes-extended/iasl/iasl_20150515.bbSignature · 1 line
2.1.4
Quoted 5 lines · Fathi Boudra
fwiw, I've been maintaining acpica recipe in meta-oe, and will keep an eye here as well.
meta-luv supports both x86* and arm*, and we have an interest in having the same features available and working for qemuaarch64.
I was not aware of this. Perhaps there is no need for us to maintain a separate recipe in meta-luv.
Re: [PATCH 1/9] ovmf: move from meta-luv to OE-core
In reply to Patrick OhlyQuoted 2 lines · Patrick Ohly
create mode 100644
meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch
We added this patch because we were interested in enabling BGRT for our own Linux kernel testing purposes. I am not sure if this patch is of the interest of the wider OE-core audience. I would think it does not.
Re: [PATCH 2/9] iasl: move from meta-luv to OE-core
In reply to Patrick OhlyQuoted 6 lines · Patrick Ohly
From: meta-luv <[email protected]>
This is an unmodified copy of github.com/01org/luv-yocto/meta-luv/recipes-extended/iasl revision 4be4329.
Quoted 6 lines
iasl is also provided by the meta-oe layer's acpica recipe. iasl is a bit simpler and thus seems more suitable for OE-core.
When the meta-oe layer is active, PREFERRED_PROVIDER_iasl-native must be set to avoid a warning. It can be set to "acpica-native" when something from acpica besides just iasl is needed.
It would be worth pondering whether to use this recipe or the one that Fathi Boudra maintains.
Re: [PATCH 4/9] ovmf: deploy firmware in image directory
In reply to Patrick OhlyQuoted 13 lines · Patrick Ohly
When used with '-drive if=pflash', qemu will store UEFI variables inside the firmware image file. That is unexpected for a file located in
the sysroot, which should be read-only, while it is normal for image files in the deploy/images directory. Therefore that directory is a better place for use with runqemu.The name was chose so that "runqemu ovmf" can be used as shorthand for "runqemu <full path>/ovmf.qcow2" by treating "ovmf" as the base name of the BIOS file. "ovmf_secboot.qcow2" is meant to be used for the Secure Boot enabled BIOS. qcow2 is used because it is needed for "savevm" snapshots of a virtual machine.
Quoted 6 lines
Alternatively, OVMF_CODE.fd (read-only) and OVMF_VARS.fd (read/write) could be used. That would then allow updating the firmware of an existing machine without wiping out the variables set earlier. Configuring that in qemu would be more complicated, so for now the simpler approach with combined code and variable store is used.
This looks good to me!
Re: [PATCH 5/9] ovmf_git.bb: enable parallel compilation
In reply to Patrick OhlyQuoted 3 lines · Patrick Ohly
The Fedora srpm [1] seems to have no problems with parallel compilation, so let's also use that for the target. The native tools however indeed have dependency problems:
True. It is good to paralize what we can. This also looks good to me.
Quoted 9 lines · Ricardo Neri
Quoted 5 lines · Fathi Boudra
fwiw, I've been maintaining acpica recipe in meta-oe, and will keep an eye here as well.
meta-luv supports both x86* and arm*, and we have an interest in having the same features available and working for qemuaarch64.I was not aware of this. Perhaps there is no need for us to maintain a separate recipe in meta-luv.
Looks like there is consensus that maintaining an acpica recipe in OE-core is the right approach. I'll prepare a revision of this patch series that includes acpica instead of iasl and also addresses the other points that Ricardo raised.
Signature · 6 lines
Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.
Re: [PATCH 4/9] ovmf: deploy firmware in image directory
In reply to Patrick OhlyQuoted 60 lines · Patrick Ohly
When used with '-drive if=pflash', qemu will store UEFI variables inside the firmware image file. That is unexpected for a file located in the sysroot, which should be read-only, while it is normal for image files in the deploy/images directory. Therefore that directory is a better place for use with runqemu.
The name was chose so that "runqemu ovmf" can be used as shorthand for "runqemu <full path>/ovmf.qcow2" by treating "ovmf" as the base name of the BIOS file. "ovmf_secboot.qcow2" is meant to be used for the Secure Boot enabled BIOS. qcow2 is used because it is needed for "savevm" snapshots of a virtual machine.
Alternatively, OVMF_CODE.fd (read-only) and OVMF_VARS.fd (read/write) could be used. That would then allow updating the firmware of an existing machine without wiping out the variables set earlier. Configuring that in qemu would be more complicated, so for now the simpler approach with combined code and variable store is used.
Signed-off-by Patrick Ohly <[email protected]>--- meta/recipes-core/ovmf/ovmf_git.bb | 33 +++++++++++++++++++++++---------- 1 file changed, 23 insertions(+), 10 deletions(-)meta/recipes-core/ovmf/ovmf_git.bb +13
-2@@ -16,7 +16,7 @@ PARALLEL_MAKE = "" S = "${WORKDIR}/git" -DEPENDS_class-native="util-linux-native iasl-native ossp-uuid-native" +DEPENDS_class-native="util-linux-native iasl-native ossp-uuid-native qemu-native" DEPENDS_class-target="ovmf-native"@@ -97,9 +97,20 @@ do_compile_class-target() { OVMF_ARCH="IA32" fi + # ${WORKDIR}/ovmf is a well-known location where do_install and + # do_deploy will be able to find the files. + rm -rf ${WORKDIR}/ovmf + mkdir ${WORKDIR}/ovmf + OVMF_DIR_SUFFIX="X64" + if [ "${TARGET_ARCH}" != "x86_64" ] ; then + OVMF_DIR_SUFFIX="Ia32" # Note the different capitalization + fi FIXED_GCCVER=$(fixup_target_tools ${GCC_VER}) - echo FIXED_GCCVER is ${FIXED_GCCVER} + bbnote FIXED_GCCVER is ${FIXED_GCCVER} + build_dir="${S}/Build/Ovmf$OVMF_DIR_SUFFIX/RELEASE_${FIXED_GCCVER}" + ${S}/OvmfPkg/build.sh -a $OVMF_ARCH -b RELEASE -t ${FIXED_GCCVER} + ln ${build_dir}/FV/OVMF.fd ${WORKDIR}/ovmf/OVMF.fd } do_install_class-native() {
meta/recipes-core/ovmf/ovmf_git.bb do_install_class-native() { · line 124
Quoted 10 lines
meta/recipes-core/ovmf/ovmf_git.bb +2
-4@@ -108,16 +119,18 @@ do_install_class-native() { } do_install_class-target() { - OVMF_DIR_SUFFIX="X64" - if [ "${TARGET_ARCH}" != "x86_64" ] ; then - OVMF_DIR_SUFFIX="Ia32" # Note the different capitalization - fi + # Traditional location. install -d ${D}${datadir}/ovmf + install -m 0755 ${WORKDIR}/ovmf/OVMF.fd ${D}${datadir}/ovmf/bios.bin
Now that I think about it. Installing here does not sever any purpose. Thus, I think this can be removed by perhaps doing do_install[noexec] = "1"
meta/recipes-core/ovmf/ovmf_git.bb do_install_class-native() { · line 127
Quoted 7 lines
meta/recipes-core/ovmf/ovmf_git.bb +2
-4+} - FIXED_GCCVER=$(fixup_target_tools ${GCC_VER}) - build_dir="${S}/Build/Ovmf$OVMF_DIR_SUFFIX/RELEASE_${FIXED_GCCVER}" - install -m 0755 ${build_dir}/FV/OVMF.fd \ - ${D}${datadir}/ovmf/bios.bin +inherit deploy
I am not sure if there is a right way for inheriting in bitbake. However, a quick grep -n inherit reveals that the majority of the recipes put their inheritances towards the top of the recipe.
Thanks and BR,
Ricardo
Quoted 9 lines
meta/recipes-core/ovmf/ovmf_git.bb +6
-0+do_deploy() { +} +do_deploy_class-target() { + # For use with "runqemu ovmf". + qemu-img convert -f raw -O qcow2 ${WORKDIR}/ovmf/OVMF.fd ${DEPLOYDIR}/ovmf.qcow2 } +addtask do_deploy after do_compile before do_build BBCLASSEXTEND = "native"
Re: [PATCH 6/9] ovmf_git.bb: enable Secure Boot
In reply to Patrick OhlyQuoted 3 lines · Patrick Ohly
The recipe now compiles OVMF twice, once without Secure Boot, once with. This is the same approach as in
https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/edk2.spec
Besides the fact that Fedora does it, is there a particular reason to build twice? On my side, I am able to build with secure boot with a single build. Also, the Ubuntu documentation does not mention that two builds are needed [1].
I do see that in Fedora, the build parameters change. OVMF without secure boot support is built with -a X64 -p OvmfPkg/OvmfPkgX64.dsc while OVMF with secure boot support is built with -a IA32 -a X64 -p OvmfPkg/OvmfPkgIa32X64.dsc. Perhaps this is the reason?
Quoted 6 lines
The results are "ovmf.qcow2" and "ovmf.secboot.qcow2" in the image deploy directory, so
runqemu <machine> <image> ovmf.secboot
will boot with Secure Boot enabled.
Quoted 6 lines
In contrast to Fedora, no attempt is made to strip potentially patent encumbered algorithms out of the OpenSSL archive. OVMF does not use the ones considered problematic for Fedora, so this shouldn't be a problem.
Fixes luv-yocto/#38
Also, I think it would be nice if we could choose between to not have secure boot at all for OVMF. Maybe this could be achieved by having a common ovmf.inc and two ovmf_git.bb and ovmf_sb_git.bb with the different the specific things to support secure boot or not. Maybe all that is needed in the secure boot recipe are the extra variables for OpenSSL and a prepend to do_compile_class-target with the OpenSSL patching. Something to ponder.
Quoted 53 lines
Signed-off-by Patrick Ohly <[email protected]>--- meta/recipes-core/ovmf/ovmf_git.bb | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-)meta/recipes-core/ovmf/ovmf_git.bb +15
-1@@ -1,6 +1,6 @@ DESCRIPTION = "OVMF - UEFI firmware for Qemu and KVM" HOMEPAGE = "http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF" -LICENSE = "BSD" +LICENSE = "BSD & OpenSSL" LIC_FILES_CHKSUM = "file://OvmfPkg/License.txt;md5=343dc88e82ff33d042074f62050c3496" SRC_URI = "git://github.com/tianocore/edk2.git;branch=master \@@ -10,7 +10,13 @@ SRC_URI = "git://github.com/tianocore/edk2.git;branch=master \ file://0003-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch \ " +SRC_URI_append_class-target = " \ + http://www.openssl.org/source/openssl-1.0.2j.tar.gz;name=openssl;subdir=${S}/CryptoPkg/Library/OpensslLib \ +" + SRCREV="4575a602ca6072ee9d04150b38bfb143cbff8588" +SRC_URI[openssl.md5sum] = "96322138f0b69e61b7212bc53d5e912b" +SRC_URI[openssl.sha256sum] = "e7aff292be21c259c6af26469c7a9b3ba26e9abaaffd325e3dccc9785256c431" PARALLEL_MAKE_class-native = ""@@ -30,6 +36,10 @@ BUILD_OPTIMIZATION="-pipe" # OVMF supports IA only, although it could conceivably support ARM someday. COMPATIBLE_HOST='(i.86|x86_64).*' +# Additional build flags for OVMF with Secure Boot. +# Fedora also uses "-D SMM_REQUIRE -D EXCLUDE_SHELL_FROM_FD". +OVMF_SECURE_BOOT_FLAGS = "-DSECURE_BOOT_ENABLE=TRUE" + do_patch_append_class-native() { bb.build.exec_func('do_fix_iasl', d) bb.build.exec_func('do_fix_toolchain', d)@@ -110,8 +120,22 @@ do_compile_class-target() { bbnote FIXED_GCCVER is ${FIXED_GCCVER} build_dir="${S}/Build/Ovmf$OVMF_DIR_SUFFIX/RELEASE_${FIXED_GCCVER}" + bbnote "Building without Secure Boot." + rm -rf ${S}/Build/Ovmf$OVMF_DIR_SUFFIX ${S}/OvmfPkg/build.sh $PARALLEL_JOBS -a $OVMF_ARCH -b RELEASE -t ${FIXED_GCCVER} ln ${build_dir}/FV/OVMF.fd ${WORKDIR}/ovmf/OVMF.fd + + # See CryptoPkg/Library/OpensslLib/Patch-HOWTO.txt and
meta/recipes-core/ovmf/ovmf_git.bb do_compile_class-target() { · line 138
Quoted 10 lines
meta/recipes-core/ovmf/ovmf_git.bb +10
-0+ # https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/ for + # building with Secure Boot enabled. + bbnote "Building with Secure Boot." + rm -rf ${S}/Build/Ovmf$OVMF_DIR_SUFFIX + if ! [ -f ${S}/CryptoPkg/Library/OpensslLib/openssl-*/edk2-patch-applied ]; then + ( cd ${S}/CryptoPkg/Library/OpensslLib/openssl-* && patch -p1 <$(echo ../EDKII_openssl-*.patch) && touch edk2-patch-applied ) + fi + ( cd ${S}/CryptoPkg/Library/OpensslLib/ && ./Install.sh ) + ${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
At this point both ${WORKDIR}/ovmf/OVMF.secboot.fd and ${WORKDIR}/ovmf/OVMF.fd will be linked to the same OVMF.fd with secure boot support. Maybe this could be fixed by copying the files rather than creating a symbolic link.
meta/recipes-core/ovmf/ovmf_git.bb do_deploy() { · line 158
Quoted 8 lines
meta/recipes-core/ovmf/ovmf_git.bb +1
-0} do_install_class-native() {@@ -131,6 +155,7 @@ do_deploy() { do_deploy_class-target() { # For use with "runqemu ovmf". qemu-img convert -f raw -O qcow2 ${WORKDIR}/ovmf/OVMF.fd ${DEPLOYDIR}/ovmf.qcow2 + qemu-img convert -f raw -O qcow2 ${WORKDIR}/ovmf/OVMF.secboot.fd ${DEPLOYDIR}/ovmf.secboot.qcow2
In the same line as my previous comment, these two images will have secure boot support.
Thanks and BR,
Ricardo
Quoted 6 lines
meta/recipes-core/ovmf/ovmf_git.bb +0
-0} addtask do_deploy after do_compile before do_buildSignature · 1 line
2.1.4
Re: [PATCH 4/9] ovmf: deploy firmware in image directory
In reply to Ricardo NeriQuoted 8 lines · Ricardo Neri
meta/recipes-core/ovmf/ovmf_git.bb do_install_class-native() {
Quoted 8 lines
do_install_class-target() {
meta/recipes-core/ovmf/ovmf_git.bb +2
-4- OVMF_DIR_SUFFIX="X64" - if [ "${TARGET_ARCH}" != "x86_64" ] ; then - OVMF_DIR_SUFFIX="Ia32" # Note the different capitalization - fi + # Traditional location. install -d ${D}${datadir}/ovmf + install -m 0755 ${WORKDIR}/ovmf/OVMF.fd
Quoted 6 lines
${D}${datadir}/ovmf/bios.bin
Now that I think about it. Installing here does not sever any purpose. Thus, I think this can be removed by perhaps doing do_install[noexec] =
"1"
I take back this. I seems that scripts/runqemu does look for OVMF in STAGING_DIR_HOST/NATIVE. Perhaps this can be changed how that you are also updating runqemu.
Quoted 7 lines · Patrick Ohly
Quoted 1 line
Quoted 1 line
fwiw, I've been maintaining acpica recipe in meta-oe, and will
keep an
Quoted 5 lines
Quoted 3 lines
eye here as well.
meta-luv supports both x86* and arm*, and we have an interest in having the same features available and working for qemuaarch64.I was not aware of this. Perhaps there is no need for us to maintain
Quoted 8 lines
a
Quoted 1 line
separate recipe in meta-luv.
Looks like there is consensus that maintaining an acpica recipe in OE-core is the right approach. I'll prepare a revision of this patch series that includes acpica instead of iasl and also addresses the other
points that Ricardo raised.
Just to be clear. I meant that it would be better for meta-luv to leverage the acpica recipe present in meta-OE :).
Re: [PATCH 8/9] runqemu: support UEFI with OVMF firmware
In reply to Patrick Ohlyscripts/runqemu class BaseConfig(object): · line 171
Quoted 8 lines · Patrick Ohly
+ # File name of a OVMF BIOS file, to be added with -drive
if=pflash.
+ # Found in the same places as the rootfs, with or without one
ofscripts/runqemu +4
-0+ # these suffices: qcow2, bin. + # Setting one also adds "-vga std" because that is all that + # OVMF supports. + self.ovmf_bios = ''
runqemu has the options biosdir and biosfilename. Although the log for these options was lost when the script was migrated to python, the motivation of adding these options was to use OVMF. It uses the -L and -bios options of qemu. To my knowledge, the only custom bios at the moment is OVMF. Thus, you would ponder either removing or tweaking these options with your approach; which makes more sense to me.
Thanks and BR,
Ricardo
Re: [PATCH 8/9] runqemu: support UEFI with OVMF firmware
Quoted 10 lines · Ricardo Neri
Review
Quoted 8 lines · Patrick Ohly
+ # File name of a OVMF BIOS file, to be added with -drive
if=pflash.
+ # Found in the same places as the rootfs, with or without one
of(quoted diff) +4
-0+ # these suffices: qcow2, bin. + # Setting one also adds "-vga std" because that is all that + # OVMF supports. + self.ovmf_bios = ''
Quoted 2 lines
runqemu has the options biosdir and biosfilename. Although the log for these options was lost when the script was migrated to python,
You probably mean this:
http://git.openembedded.org/openembedded-core/commit/?id=d302f5683dd736ac4cd4b601a046d22000d41e68
http://git.openembedded.org/openembedded-core/commit/?id=29c9e6f44541b7f8731e21e9d1a0adca9da28e37
Quoted 5 lines
the
motivation of adding these options was to use OVMF. It uses the -L and -bios options of qemu. To my knowledge, the only custom bios at the moment is OVMF. Thus, you would ponder either removing or tweaking these options with your approach; which makes more sense to me.
I have no personal opinion about the usefulness of the "biosdir" and "biosfilename" options. Just looking at what they do, they might have value also when not using OVMF (for example, the "VGA BIOS" that is mentioned in the first commit). But if no-one is actually using these options, then they should indeed be removed to simplify runqemu.
The problem just is to determine whether they are used :-/ As I don't know, I'd prefer to keep them for now and remove them separately.
Regarding the approach that I proposed for the "ovmf" file(s): what's your opinion about that? I was a bit worried that too much "magic" is involved here (special keyword that expands to files and sets -vga), but it is convenient and quite naturally supports additional use cases (explicitly selecting files at non-standard locations, separate code and variable files).
Regarding that last argument: in the current patch series, only the combined ovmf.fd gets deployed and I argued that this is sufficient. To test that supporting separate code and variables also works, I've implemented that locally so that ovmf.fd ovmf_secboot.fd, ovmf_code.fd, ovmf_secboot_code.fd and ovmf_vars.fd get deployed and runqemu supports more than one "ovmf" parameter - this worked nicely. Full change below.
Now that I've implemented it, I wonder whether it would be worth submitting that as part of rev2 of this patch series. Any opinions?
meta/recipes-core/ovmf/ovmf_git.bb +6 -2
@@ -125,6 +125,8 @@ do_compile_class-target() { rm -rf ${S}/Build/Ovmf$OVMF_DIR_SUFFIX ${S}/OvmfPkg/build.sh $PARALLEL_JOBS -a $OVMF_ARCH -b RELEASE -t ${FIXED_GCCVER} 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 # See CryptoPkg/Library/OpensslLib/Patch-HOWTO.txt and # https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/ for
@@ -137,6 +139,7 @@ do_compile_class-target() { ( cd ${S}/CryptoPkg/Library/OpensslLib/ && ./Install.sh ) ${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.code.secboot.fd for i in Shell.efi EnrollDefaultKeys.efi; do ln ${build_dir}/${OVMF_ARCH}/$i ${WORKDIR}/ovmf/$i done
@@ -170,8 +173,9 @@ do_deploy() { } do_deploy_class-target() { # For use with "runqemu ovmf". - qemu-img convert -f raw -O qcow2 ${WORKDIR}/ovmf/OVMF.fd ${DEPLOYDIR}/ovmf.qcow2 - qemu-img convert -f raw -O qcow2 ${WORKDIR}/ovmf/OVMF.secboot.fd ${DEPLOYDIR}/ovmf.secboot.qcow2 + for i in OVMF OVMF.secboot OVMF.code OVMF.vars OVMF.code.secboot; do + qemu-img convert -f raw -O qcow2 ${WORKDIR}/ovmf/$i.fd ${DEPLOYDIR}/`echo $i | tr A-Z a-z`.qcow2 + done } addtask do_deploy after do_compile before do_build
scripts/runqemu +20 -19
@@ -163,12 +163,12 @@ class BaseConfig(object): self.clean_nfs_dir = False self.nfs_server = '' self.rootfs = '' - # File name of a OVMF BIOS file, to be added with -drive if=pflash. + # File name(s) of a OVMF BIOS file or variable store, to be added with -drive if=pflash. # Found in the same places as the rootfs, with or without one of # these suffices: qcow2, bin. # Setting one also adds "-vga std" because that is all that # OVMF supports. - self.ovmf_bios = '' + self.ovmf_bios = [] self.qemuboot = '' self.qbconfload = False self.kernel = ''
@@ -376,13 +376,13 @@ class BaseConfig(object): self.qemu_opt_script += ' %s' % arg[len('qemuparams='):] elif arg.startswith('bootparams='): self.kernel_cmdline_script += ' %s' % arg[len('bootparams='):] - elif os.path.basename(arg).startswith('ovmf'): - self.ovmf_bios = arg elif os.path.exists(arg) or (re.search(':', arg) and re.search('/', arg)): self.check_arg_path(os.path.abspath(arg)) - elif re.search('-image-', arg): + elif re.search('-image-', arg) or arg.endswith('-image'): # Lazy rootfs self.rootfs = arg + elif os.path.basename(arg).startswith('ovmf'): + self.ovmf_bios.append(arg) else: # At last, assume is it the MACHINE if (not unknown_arg) or unknown_arg == arg:
@@ -482,18 +482,18 @@ class BaseConfig(object): raise Exception("Can't find rootfs: %s" % self.rootfs) def check_ovmf(self): - """Check and set full path for OVMF BIOS file.""" + """Check and set full path for OVMF BIOS file(s).""" - if self.ovmf_bios is None or os.path.exists(self.ovmf_bios): - return - - for suffix in ('qcow2', 'bin'): - ovmf_bios = '%s/%s.%s' % (self.get('DEPLOY_DIR_IMAGE'), self.ovmf_bios, suffix) - if os.path.exists(ovmf_bios): - self.ovmf_bios = ovmf_bios - return - - raise Exception("Can't find OVMF BIOS: %s" % self.ovmf_bios) + for index, ovmf in enumerate(self.ovmf_bios): + if os.path.exists(ovmf): + continue + for suffix in ('qcow2', 'bin'): + path = '%s/%s.%s' % (self.get('DEPLOY_DIR_IMAGE'), ovmf, suffix) + if os.path.exists(path): + self.ovmf_bios[index] = path + break + else: + raise Exception("Can't find OVMF BIOS: %s" % ovmf) def check_kernel(self): """Check and set kernel, dtb"""
@@ -695,7 +695,7 @@ class BaseConfig(object): else: print('ROOTFS: [%s]' % self.rootfs) if self.ovmf_bios: - print('OVMF: [%s]' % self.ovmf_bios) + print('OVMF: %s' % self.ovmf_bios) print('CONFFILE: [%s]' % self.qemuboot) print('')
@@ -939,9 +939,10 @@ class BaseConfig(object): self.qemu_opt = "%s %s %s %s" % (qemu_bin, self.get('NETWORK_CMD'), self.get('ROOTFS_OPTIONS'), self.get('QB_OPT_APPEND')) + for ovmf in self.ovmf_bios: + format = ovmf.rsplit('.', 1)[-1] + self.qemu_opt += ' -drive if=pflash,format=%s,file=%s' % (format, ovmf) if self.ovmf_bios: - format = self.ovmf_bios.rsplit('.', 1)[-1] - self.qemu_opt += ' -drive if=pflash,format=%s,file=%s' % (format, self.ovmf_bios) # OVMF only supports normal VGA, i.e. we need to override a -vga vmware # that gets added for example for normal qemux86. self.qemu_opt += ' -vga std'
Signature · 6 lines
Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.
Re: [PATCH 4/9] ovmf: deploy firmware in image directory
In reply to Ricardo NeriQuoted 9 lines · Ricardo Neri
meta/recipes-core/ovmf/ovmf_git.bb do_install_class-native() { · line 124
Quoted 8 lines
do_install_class-target() {
meta/recipes-core/ovmf/ovmf_git.bb +2
-4- OVMF_DIR_SUFFIX="X64" - if [ "${TARGET_ARCH}" != "x86_64" ] ; then - OVMF_DIR_SUFFIX="Ia32" # Note the different capitalization - fi + # Traditional location. install -d ${D}${datadir}/ovmf + install -m 0755 ${WORKDIR}/ovmf/OVMF.fd ${D}${datadir}/ovmf/bios.bin
Quoted 3 lines
Now that I think about it. Installing here does not sever any purpose. Thus, I think this can be removed by perhaps doing do_install[noexec] = "1"
I was trying not to break traditional usage patterns. If we keep the "bios" runqemu parameters, then we should also keep the bios.bin file.
Quoted 11 lines
meta/recipes-core/ovmf/ovmf_git.bb do_install_class-native() { · line 127
Quoted 7 lines
meta/recipes-core/ovmf/ovmf_git.bb +2
-4+} - FIXED_GCCVER=$(fixup_target_tools ${GCC_VER}) - build_dir="${S}/Build/Ovmf$OVMF_DIR_SUFFIX/RELEASE_${FIXED_GCCVER}" - install -m 0755 ${build_dir}/FV/OVMF.fd \ - ${D}${datadir}/ovmf/bios.bin +inherit deployI am not sure if there is a right way for inheriting in bitbake. However, a quick grep -n inherit reveals that the majority of the recipes put their inheritances towards the top of the recipe.
Agreed, that seems to be more common, although there are also examples where "inherit deploy" is directly in front of "do_deploy". I chose the latter because it was a more localized change, but will change it in rev2.
Signature · 6 lines
Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.
Re: [PATCH 6/9] ovmf_git.bb: enable Secure Boot
In reply to Ricardo NeriQuoted 7 lines · Ricardo Neri
Quoted 3 lines · Patrick Ohly
The recipe now compiles OVMF twice, once without Secure Boot, once with. This is the same approach as in
https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/edk2.specBesides the fact that Fedora does it, is there a particular reason to build twice?
The ${build_dir}/FV/OVMF.fd file changes depending on the configuration. There's only one such file after a build.
Quoted 3 lines
On my side, I am able to build with secure boot with a
single build. Also, the Ubuntu documentation does not mention that two builds are needed [1].
Can you build with and without secure boot in a single build? I wasn't sure how to achieve that, so I just copied what Fedora does.
Quoted 7 lines
Also, I think it would be nice if we could choose between to not have secure boot at all for OVMF. Maybe this could be achieved by having a common ovmf.inc and two ovmf_git.bb and ovmf_sb_git.bb with the different the specific things to support secure boot or not. Maybe all that is needed in the secure boot recipe are the extra variables for OpenSSL and a prepend to do_compile_class-target with the OpenSSL patching. Something to ponder.
I think I would prefer to have a single recipe with a PACKAGECONFIG for secure boot. Having different recipes doesn't scale when adding more such options. If you agree, then I'll add that.
Quoted 8 lines
meta/recipes-core/ovmf/ovmf_git.bb do_compile_class-target() { · line 138
Quoted 3 lines
meta/recipes-core/ovmf/ovmf_git.bb +3
-0+ ( cd ${S}/CryptoPkg/Library/OpensslLib/ && ./Install.sh ) + ${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.fdAt this point both ${WORKDIR}/ovmf/OVMF.secboot.fd and ${WORKDIR}/ovmf/OVMF.fd will be linked to the same OVMF.fd with secure boot support. Maybe this could be fixed by copying the files rather than creating a symbolic link.
This is intentionally a hardlink, not a symbolic link, exactly because of the problem you mentioned ;-)
Signature · 6 lines
Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.
Re: [PATCH 3/9] ovmf: explicitly depend on nasm-native
In reply to a message not in the archiveQuoted 5 lines · Ricardo
meta/recipes-core/ovmf/ovmf_git.bb DEPENDS_class-native="util-linux-native iasl-native ossp-uuid-native" · line 24
Quoted 2 lines · Patrick Ohly
meta/recipes-core/ovmf/ovmf_git.bb +2
-0+DEPENDS_append = " nasm-native" +Is this dependency needed for both native and target builds? If not, it can be done with
DEPENDS_class...
I'm not sure anymore. As it doesn't matter in practice because ovmf depends on ovmf-native and thys nasm-native is built either way, I'd prefer to keep it as-is.
Signature · 6 lines
Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.
Re: [PATCH 8/9] runqemu: support UEFI with OVMF firmware
In reply to Patrick OhlyQuoted 24 lines · Patrick Ohly
Quoted 10 lines · Ricardo Neri
Review
Quoted 8 lines · Patrick Ohly
+ # File name of a OVMF BIOS file, to be added with -drive
if=pflash.
+ # Found in the same places as the rootfs, with or without one
of(quoted diff) +4
-0+ # these suffices: qcow2, bin. + # Setting one also adds "-vga std" because that is all that + # OVMF supports. + self.ovmf_bios = ''Quoted 2 lines
runqemu has the options biosdir and biosfilename. Although the log for these options was lost when the script was migrated to python,
You probably mean this:
http://git.openembedded.org/openembedded-core/commit/?id=d302f5683dd736ac4cd4b601a046d22000d41e68
http://git.openembedded.org/openembedded-core/commit/?id=29c9e6f44541b7f8731e21e9d1a0adca9da28e37Quoted 5 lines
the
motivation of adding these options was to use OVMF. It uses the -L and -bios options of qemu. To my knowledge, the only custom bios at the moment is OVMF. Thus, you would ponder either removing or tweaking these options with your approach; which makes more sense to me.
Quoted 8 lines
I have no personal opinion about the usefulness of the "biosdir" and "biosfilename" options. Just looking at what they do, they might have value also when not using OVMF (for example, the "VGA BIOS" that is mentioned in the first commit). But if no-one is actually using these options, then they should indeed be removed to simplify runqemu.
The problem just is to determine whether they are used :-/ As I don't know, I'd prefer to keep them for now and remove them separately.
This makes sense.
Quoted 10 lines
Regarding the approach that I proposed for the "ovmf" file(s): what's your opinion about that? I was a bit worried that too much "magic" is involved here (special keyword that expands to files and sets -vga), but it is convenient and quite naturally supports additional use cases (explicitly selecting files at non-standard locations, separate code and variable files).
Regarding that last argument: in the current patch series, only the combined ovmf.fd gets deployed and I argued that this is sufficient.
It would be certainly enough for me :) as in most of my use cases I always test brand new images without any variables in it. Also, you kindly included facilitiesto lockdown the image. I can't speak for other people but this is more than enough for me. If you pursue this path, perhaps you can include a big warning in the recipe saying that people will lose their variables if they rebuild OVMF. On the other hand...
Quoted 5 lines
To
test that supporting separate code and variables also works, I've implemented that locally so that ovmf.fd ovmf_secboot.fd, ovmf_code.fd, ovmf_secboot_code.fd and ovmf_vars.fd get deployed and runqemu supports more than one "ovmf" parameter - this worked nicely. Full change below.
... Now that you have took the time to prototype the solution, we could put it to use.
Quoted 26 lines
Now that I've implemented it, I wonder whether it would be worth submitting that as part of rev2 of this patch series. Any opinions?
meta/recipes-core/ovmf/ovmf_git.bb +3
-0@@ -125,6 +125,8 @@ do_compile_class-target() { rm -rf ${S}/Build/Ovmf$OVMF_DIR_SUFFIX ${S}/OvmfPkg/build.sh $PARALLEL_JOBS -a $OVMF_ARCH -b RELEASE -t ${FIXED_GCCVER} 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 # See CryptoPkg/Library/OpensslLib/Patch-HOWTO.txt and # https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/ for@@ -137,6 +139,7 @@ do_compile_class-target() { ( cd ${S}/CryptoPkg/Library/OpensslLib/ && ./Install.sh ) ${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.code.secboot.fd for i in Shell.efi EnrollDefaultKeys.efi; do ln ${build_dir}/${OVMF_ARCH}/$i ${WORKDIR}/ovmf/$i done
meta/recipes-core/ovmf/ovmf_git.bb do_deploy() { · line 177
Quoted 7 lines
meta/recipes-core/ovmf/ovmf_git.bb +2
-2@@ -170,8 +173,9 @@ do_deploy() { } do_deploy_class-target() { # For use with "runqemu ovmf". - qemu-img convert -f raw -O qcow2 ${WORKDIR}/ovmf/OVMF.fd ${DEPLOYDIR}/ovmf.qcow2 - qemu-img convert -f raw -O qcow2 ${WORKDIR}/ovmf/OVMF.secboot.fd ${DEPLOYDIR}/ovmf.secboot.qcow2 + for i in OVMF OVMF.secboot OVMF.code OVMF.vars OVMF.code.secboot; do + qemu-img convert -f raw -O qcow2 ${WORKDIR}/ovmf/$i.fd ${DEPLOYDIR}/`echo $i | tr A-Z a-z`.qcow2
Will this preserve any previous OVMF_vars.fd that might exist in the directory.
Quoted 71 lines
meta/recipes-core/ovmf/ovmf_git.bb +1
-0+ done } addtask do_deploy after do_compile before do_buildscripts/runqemu +16
-16@@ -163,12 +163,12 @@ class BaseConfig(object): self.clean_nfs_dir = False self.nfs_server = '' self.rootfs = '' - # File name of a OVMF BIOS file, to be added with -drive if=pflash. + # File name(s) of a OVMF BIOS file or variable store, to be added with -drive if=pflash. # Found in the same places as the rootfs, with or without one of # these suffices: qcow2, bin. # Setting one also adds "-vga std" because that is all that # OVMF supports. - self.ovmf_bios = '' + self.ovmf_bios = [] self.qemuboot = '' self.qbconfload = False self.kernel = ''@@ -376,13 +376,13 @@ class BaseConfig(object): self.qemu_opt_script += ' %s' % arg[len('qemuparams='):] elif arg.startswith('bootparams='): self.kernel_cmdline_script += ' %s' % arg[len('bootparams='):] - elif os.path.basename(arg).startswith('ovmf'): - self.ovmf_bios = arg elif os.path.exists(arg) or (re.search(':', arg) and re.search('/', arg)): self.check_arg_path(os.path.abspath(arg)) - elif re.search('-image-', arg): + elif re.search('-image-', arg) or arg.endswith('-image'): # Lazy rootfs self.rootfs = arg + elif os.path.basename(arg).startswith('ovmf'): + self.ovmf_bios.append(arg) else: # At last, assume is it the MACHINE if (not unknown_arg) or unknown_arg == arg:@@ -482,18 +482,18 @@ class BaseConfig(object): raise Exception("Can't find rootfs: %s" % self.rootfs) def check_ovmf(self): - """Check and set full path for OVMF BIOS file.""" + """Check and set full path for OVMF BIOS file(s).""" - if self.ovmf_bios is None or os.path.exists(self.ovmf_bios): - return - - for suffix in ('qcow2', 'bin'): - ovmf_bios = '%s/%s.%s' % (self.get('DEPLOY_DIR_IMAGE'), self.ovmf_bios, suffix) - if os.path.exists(ovmf_bios): - self.ovmf_bios = ovmf_bios - return - - raise Exception("Can't find OVMF BIOS: %s" % self.ovmf_bios) + for index, ovmf in enumerate(self.ovmf_bios): + if os.path.exists(ovmf): + continue + for suffix in ('qcow2', 'bin'): + path = '%s/%s.%s' % (self.get('DEPLOY_DIR_IMAGE'), ovmf, suffix) + if os.path.exists(path): + self.ovmf_bios[index] = path + break + else: + raise Exception("Can't find OVMF BIOS: %s" % ovmf) def check_kernel(self): """Check and set kernel, dtb"""
scripts/runqemu class BaseConfig(object): · line 698
Quoted 5 lines
scripts/runqemu +1
-1@@ -695,7 +695,7 @@ class BaseConfig(object): else: print('ROOTFS: [%s]' % self.rootfs) if self.ovmf_bios: - print('OVMF: [%s]' % self.ovmf_bios) + print('OVMF: %s' % self.ovmf_bios)
Is there a reason to remove the brackets here?
Quoted 8 lines
scripts/runqemu +0
-0print('CONFFILE: [%s]' % self.qemuboot) print('')@@ -939,9 +939,10 @@ class BaseConfig(object): self.qemu_opt = "%s %s %s %s" % (qemu_bin, self.get('NETWORK_CMD'), self.get('ROOTFS_OPTIONS'), self.get('QB_OPT_APPEND'))
scripts/runqemu class BaseConfig(object): · line 948
Quoted 10 lines
scripts/runqemu +3
-2+ for ovmf in self.ovmf_bios: + format = ovmf.rsplit('.', 1)[-1] + self.qemu_opt += ' -drive if=pflash,format=%s,file=%s' % (format, ovmf) if self.ovmf_bios: - format = self.ovmf_bios.rsplit('.', 1)[-1] - self.qemu_opt += ' -drive if=pflash,format=%s,file=%s' % (format, self.ovmf_bios) # OVMF only supports normal VGA, i.e. we need to override a -vga vmware # that gets added for example for normal qemux86. self.qemu_opt += ' -vga std'
I think this solution looks good as having separate file does not pose an extra hassle in the user: the recipe builds all that is needed and runqemu takes all that it needs. If in the future people shows an interest in having unified images, maybe that can be added as another PACKAGECONFIG?
Also, the usage of runqemu needs to be updated as well. Perhaps the usage can include a note stating that code and vars are are split but no extra action is needed.
Thanks and BR,
Ricardo
Quoted 1 line
Re: [PATCH 4/9] ovmf: deploy firmware in image directory
In reply to Patrick OhlyQuoted 10 lines · Patrick Ohly
Quoted 9 lines · Ricardo Neri
Quoted 8 lines
do_install_class-target() {
meta/recipes-core/ovmf/ovmf_git.bb +2
-4- OVMF_DIR_SUFFIX="X64" - if [ "${TARGET_ARCH}" != "x86_64" ] ; then - OVMF_DIR_SUFFIX="Ia32" # Note the different capitalization - fi + # Traditional location. install -d ${D}${datadir}/ovmf + install -m 0755 ${WORKDIR}/ovmf/OVMF.fd ${D}${datadir}/ovmf/bios.bin
Quoted 6 lines
Quoted 3 lines
Now that I think about it. Installing here does not sever any purpose. Thus, I think this can be removed by perhaps doing do_install[noexec] = "1"
I was trying not to break traditional usage patterns. If we keep the "bios" runqemu parameters, then we should also keep the bios.bin file.
I think OVMF is not a traditional recipe. There are two use cases to ponder. 1) a Yocto Project disk image wants to include OVMF along with qemu to run a VM from the YP image. 2) we want to run a YP image in a host system. I am not sure if someone is interested in 1) and I think your use case and LUV's is 2). I think that putting things in the deploy directory makes more sense because, as you said, these images will be written to. I reckon the the "bios" parameters in runqemu should look there. This is not a must for this patchset but something nice to have.
Thanks and BR,
Ricardo
Re: [PATCH 6/9] ovmf_git.bb: enable Secure Boot
In reply to Patrick OhlyQuoted 12 lines · Patrick Ohly
Quoted 7 lines · Ricardo Neri
Quoted 3 lines · Patrick Ohly
The recipe now compiles OVMF twice, once without Secure Boot, once with. This is the same approach as in
https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/edk2.specBesides the fact that Fedora does it, is there a particular reason to build twice?
The ${build_dir}/FV/OVMF.fd file changes depending on the configuration. There's only one such file after a build.
Quoted 6 lines
Quoted 3 lines
On my side, I am able to build with secure boot with a
single build. Also, the Ubuntu documentation does not mention that two builds are needed [1].Can you build with and without secure boot in a single build? I wasn't sure how to achieve that, so I just copied what Fedora does.
Oh I see, I didn't understand in your commit message that you intend to keep the secure boot and the non-secure boot images. Then it makes sense to build twice.
Quoted 9 lines
Quoted 8 lines
Also, I think it would be nice if we could choose between to not have secure boot at all for OVMF. Maybe this could be achieved by having a common ovmf.inc and two ovmf_git.bb and ovmf_sb_git.bb with the different the specific things to support secure boot or not. Maybe all that is needed in the secure boot recipe are the extra variables for OpenSSL and a prepend to do_compile_class-target with the OpenSSL patching. Something to ponder.
Quoted 3 lines
I think I would prefer to have a single recipe with a PACKAGECONFIG for secure boot. Having different recipes doesn't scale when adding more such options. If you agree, then I'll add that.
Yes, I agree that a PACKAGECONFIG makes more sense.
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
meta/recipes-core/ovmf/ovmf_git.bb +3
-0+ ( cd ${S}/CryptoPkg/Library/OpensslLib/ && ./Install.sh ) + ${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
Quoted 7 lines
Quoted 4 lines
At this point both ${WORKDIR}/ovmf/OVMF.secboot.fd and ${WORKDIR}/ovmf/OVMF.fd will be linked to the same OVMF.fd with secure boot support. Maybe this could be fixed by copying the files rather than creating a symbolic link.
This is intentionally a hardlink, not a symbolic link, exactly because of the problem you mentioned ;-)
Oh, a hardlink. I see now. Thanks for clarifying.
Quoted 1 line
Re: [PATCH 8/9] runqemu: support UEFI with OVMF firmware
In reply to Ricardo NeriQuoted 38 lines · Ricardo Neri
Quoted 5 lines · Patrick Ohly
To
test that supporting separate code and variables also works, I've implemented that locally so that ovmf.fd ovmf_secboot.fd, ovmf_code.fd, ovmf_secboot_code.fd and ovmf_vars.fd get deployed and runqemu supports more than one "ovmf" parameter - this worked nicely. Full change below.... Now that you have took the time to prototype the solution, we could put it to use.
Quoted 28 lines
Now that I've implemented it, I wonder whether it would be worth submitting that as part of rev2 of this patch series. Any opinions?
meta/recipes-core/ovmf/ovmf_git.bb +3
-0@@ -125,6 +125,8 @@ do_compile_class-target() { rm -rf ${S}/Build/Ovmf$OVMF_DIR_SUFFIX ${S}/OvmfPkg/build.sh $PARALLEL_JOBS -a $OVMF_ARCH -b RELEASE -t ${FIXED_GCCVER} 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 # See CryptoPkg/Library/OpensslLib/Patch-HOWTO.txt and # https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/ for@@ -137,6 +139,7 @@ do_compile_class-target() { ( cd ${S}/CryptoPkg/Library/OpensslLib/ && ./Install.sh ) ${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.code.secboot.fd for i in Shell.efi EnrollDefaultKeys.efi; do ln ${build_dir}/${OVMF_ARCH}/$i ${WORKDIR}/ovmf/$i done@@ -170,8 +173,9 @@ do_deploy() { } do_deploy_class-target() {
Quoted 8 lines
meta/recipes-core/ovmf/ovmf_git.bb do_deploy() { · line 177
Quoted 5 lines
meta/recipes-core/ovmf/ovmf_git.bb +2
-2# For use with "runqemu ovmf". - qemu-img convert -f raw -O qcow2 ${WORKDIR}/ovmf/OVMF.fd ${DEPLOYDIR}/ovmf.qcow2 - qemu-img convert -f raw -O qcow2 ${WORKDIR}/ovmf/OVMF.secboot.fd ${DEPLOYDIR}/ovmf.secboot.qcow2 + for i in OVMF OVMF.secboot OVMF.code OVMF.vars OVMF.code.secboot; do + qemu-img convert -f raw -O qcow2 ${WORKDIR}/ovmf/$i.fd ${DEPLOYDIR}/`echo $i | tr A-Z a-z`.qcow2Will this preserve any previous OVMF_vars.fd that might exist in the directory.
No, it will overwrite ovmf.vars.qcow2 and any variables stored in that get lost. That is consistent with rebuilding the disk image: a user who wants to have a "persistent" virtual machine must copy the relevant file and then use the full file paths. In this case, that means invoking runqemu with the file path to the copy of ovmf.vars.qcow2 instead of just "ovmf.vars".
Quoted 5 lines
meta/recipes-core/ovmf/ovmf_git.bb do_deploy() { · line 179
Quoted 3 lines
meta/recipes-core/ovmf/ovmf_git.bb +1
-1if self.ovmf_bios: - print('OVMF: [%s]' % self.ovmf_bios) + print('OVMF: %s' % self.ovmf_bios)Is there a reason to remove the brackets here?
self.ovmf_bios is a list, so formatting it as string will add the brackets. I found that more readable than the (from a semantic point of view more correct) double brackets: [['.../ovmf.code.qcow2', '.../ovmf.vars.qcow2']]
Quoted 11 lines
meta/recipes-core/ovmf/ovmf_git.bb do_deploy() {
Quoted 11 lines
meta/recipes-core/ovmf/ovmf_git.bb +3
-2+ for ovmf in self.ovmf_bios: + format = ovmf.rsplit('.', 1)[-1] + self.qemu_opt += ' -drive if=pflash,format=%s,file=%s' % (format, ovmf) if self.ovmf_bios: - format = self.ovmf_bios.rsplit('.', 1)[-1] - self.qemu_opt += ' -drive if=pflash,format=%s,file=%s' % (format, self.ovmf_bios) # OVMF only supports normal VGA, i.e. we need to override a -vga vmware # that gets added for example for normal qemux86. self.qemu_opt += ' -vga std'
Quoted 3 lines
I think this solution looks good as having separate file does not pose an extra hassle in the user: the recipe builds all that is needed and runqemu takes all that it needs.
But not automatically. "runqemu ovmf" would expand "ovmf" to tmp/deploy/images/.../ovmf.qcow2 and thus use the combined file while "runqemu ovmf.code ovmf.vars" tells runqemu that it is supposed to use two flash drives, one with the code and one with the variables.
Quoted 3 lines
If in the future people shows an
interest in having unified images, maybe that can be added as another PACKAGECONFIG?
As the unified code+vars is slightly easier to use, I'd prefer to keep it around and just offer both. That's not such a big deal in terms of performance and disk usage.
Signature · 6 lines
Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.
Re: [PATCH 4/9] ovmf: deploy firmware in image directory
In reply to Ricardo NeriQuoted 18 lines · Ricardo Neri
Quoted 10 lines · Patrick Ohly
Quoted 9 lines · Ricardo Neri
Quoted 8 lines
do_install_class-target() {
meta/recipes-core/ovmf/ovmf_git.bb +2
-4- OVMF_DIR_SUFFIX="X64" - if [ "${TARGET_ARCH}" != "x86_64" ] ; then - OVMF_DIR_SUFFIX="Ia32" # Note the different capitalization - fi + # Traditional location. install -d ${D}${datadir}/ovmf + install -m 0755 ${WORKDIR}/ovmf/OVMF.fd ${D}${datadir}/ovmf/bios.binQuoted 6 lines
Quoted 3 lines
Now that I think about it. Installing here does not sever any purpose. Thus, I think this can be removed by perhaps doing do_install[noexec] = "1"
I was trying not to break traditional usage patterns. If we keep the "bios" runqemu parameters, then we should also keep the bios.bin file.
Quoted 8 lines
I think OVMF is not a traditional recipe. There are two use cases to ponder. 1) a Yocto Project disk image wants to include OVMF along with qemu to run a VM from the YP image. 2) we want to run a YP image in a host system. I am not sure if someone is interested in 1) and I think your use case and LUV's is 2). I think that putting things in the deploy directory makes more sense because, as you said, these images will be written to. I reckon the the "bios" parameters in runqemu should look there. This is not a must for this patchset but something nice to have.
Okay, so let's remove that "traditional location" already in this patch set. I still want to keep the "bios" parameters in runqemu (because they might have some other uses), but for OVMF, the only supported approach will be via the "ovmf" parameters and the deploy directory.
Signature · 6 lines
Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.