Linking with gold fails due to an internal error in gold. The ovmf
linker is gcc, which has a -fuse-ld=bfd option to choose the linker
which (for ovmf) is known to work.
Like the choice of the compilers, this is done in ovmf-native. To keep
that recipe independent of DISTRO_FEATURES, choosing bfd is done
unconditionally.
(From OE-Core rev: 7ee548b9f6f2893caf6b5ade8c892f2968d4ec47)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For the native tools, a static patch inserted gcc/g++/ld/ar while later
adding BUILD_LDFLAGS and BUILD_CFLAGS with sed. Now it's all done with sed,
which has the advantage that it uses the actual compile variables. However,
in practice those are the same.
More importantly, picking the build tools for the target was
broken. ovmf-native tried to insert TARGET_PREFIX into the tools
definition file, but that variable is empty in a native recipe. As a
result, "gcc" was used instead of "${HOST_PREFIX}gcc", leading to an
undesirable dependency on the host compiler and potentially
(probably?!) causing some of the build issues that were seen for ovmf.
The new approach is to override the tool selection in ovmf-native so
that the HOST_PREFIX env variable is used, which then gets exported
during do_compile for the target.
While at it, Python code that gets appened to do_patch only to call
shell functions gets replaced with the do_patch[postfuncs] mechanism.
Incremental builds now always use the tools definition from the
current ovmf-native; previously, only the initial build copied the
template file.
Probably the entire split into ovmf-native and ovmf could be
removed. This merely hasn't been attempted yet.
(From OE-Core rev: 23a12d87a6e82f80f4ccc1a01c707faa89ff7abd)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The VfrCompile tool has a hard-coded maximum length for path names
which turned out to be too small by around 20 characters in the
Yocto autobuilder setup. Increasing the maximum by a factor of 4
is relatively easy and makes the problem less likely.
(From OE-Core rev: ea296ab42a7a65055657b950d8248d94f0ac56f1)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch was added to meta-luv for kernel testing purposes and
probably is not relevant for OE-core.
(From OE-Core rev: 240e96e6196c32ddabb0c1aff3ee83458c98a9bd)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When booting a qemu virtual machine with ovmf.secboot, it comes up
with no keys installed and thus Secure Boot disabled. To lock down
the machine like a typical PC, one has to enroll the same keys
that PC vendors normally install, i.e. the ones from Microsoft.
This can be done manually (see
https://wiki.ubuntu.com/SecurityTeam/SecureBoot and
https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_into_UEFI_Secure_Boot_White_Paper.pdf) or automatically with the EnrollDefaultKeys.efi helper
from the Fedora ovmf rpm.
To use this with qemu:
$ bitbake ovmf-shell-image
...
$ runqemu serial nographic qemux86 ovmf-shell-image wic ovmf.secboot
...
UEFI Interactive Shell v2.1
EDK II
UEFI v2.60 (EDK II, 0x00010000)
Mapping table
FS0: Alias(s):HD2b:;BLK4:
PciRoot(0x0)/Pci(0x5,0x0)/HD(1,GPT,06AEF759-3982-4AF6-B517-70BA6304FC1C,0x800,0x566C)
BLK0: Alias(s):
PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0)
BLK1: Alias(s):
PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x1)
BLK2: Alias(s):
PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
BLK3: Alias(s):
PciRoot(0x0)/Pci(0x5,0x0)
Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
Shell> fs0:EnrollDefaultKeys.efi
info: SetupMode=1 SecureBoot=0 SecureBootEnable=0 CustomMode=0 VendorKeys=1
info: SetupMode=0 SecureBoot=1 SecureBootEnable=1 CustomMode=0 VendorKeys=0
info: success
Shell> reset
Remember that this will modify
deploy/images/qemux86/ovmf.secboot.qcow2, so make a copy and use the
full path of that copy instead of the "ovmf" argument if needed.
The ovmf-shell-image contains an EFI shell, which is what got started
here directly. After enrolling the keys, Secure Boot is active and the
same image cannot be booted anymore, so the BIOS goes through the
normal boot targets (including network boot, which can take a while to
time out), and ends up in the internal EFI shell. Trying to invoke
bootia32.efi (the shell from the image) or EnrollDefaultKeys.efi then
fails:
Shell> bootia32.efi
Command Error Status: Security Violation
The main purpose at the moment is to test that Secure Boot enforcement
really works. If we had a way to sign generated images, that part could
also be tested by booting in a locked down qemu instance.
0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch is
from
https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch?id=b1781931894bf2057464e634beed68b1e3218c9e
with one line changed to fix
https://bugzilla.redhat.com/show_bug.cgi?id=132502:
"EFI_STATUS Status = EFI_SUCCESS;" in EnrollListOfX509Certs() lacked
the initializer.
(From OE-Core rev: 1913ace7d0898b5a23a2dbdc574ab1d8648927c5)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When enabled via PACCKAGECONFIG = "secureboot" (off by default because
of the extra work and license change), the recipe 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.
ovmf.secboot.code.qcow2 is provided for those who want separate code
and variable flash drives. The normal ovmf.vars.qcow2 can be used with
it.
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
(From OE-Core rev: d493f0b4760808f880a0fd6dedf918a3b85006b7)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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:
| 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
(From OE-Core rev: be307609a067b7d23dc2cd8e39e3a35f770bebc7)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 firmware file. "ovmf.secboot.qcow2" is meant to be used for the
Secure Boot enabled firmware.
qcow2 is used because it is needed for "savevm" snapshots of a virtual
machine.
With code and variables stored in the same ovmf.qcow2 it is not
possible to update the firmware code without also overwriting the
variables. For users who care about persistent variables, the code and
variables are also provided as separate files, in ovmf.code.qcow2 and
ovmf.vars.qcow2.
The traditional usage of OVMF via the qemu bios parameter ("biosdir"
and/or "biosfilename" in runqemu) is no longer recommended, and
therefore this recipe no longer provides the bios.bin file. Instead,
OVMF is meant to be used as flash drive in qemu. See the "runqemu:
support UEFI with OVMF firmware" patch for details on how to use OVMF
that way.
(From OE-Core rev: 6f84653e34b75a821fbf31b9f1aa912858e27f43)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes a build issue when nasm was not build already because of
something else.
(From OE-Core rev: 92198bdda7add49f2c76ce55ab1f310e2128bf8f)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is an unmodified copy of
github.com/01org/luv-yocto/meta-luv/recipes-core/ovmf revision
4be4329.
(From OE-Core rev: 49cdce8716ded0b612069d7614c3efe7724e5b40)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Patrick Ohly
meta-luv