On 23/2/22 11:10, Alex Bennée wrote:
Gerd Hoffmann <kra...@redhat.com> writes:
Hi,
If you want to boot a guest using EDK2, you should use the images
build by your distribution (/usr/share/qemu/edk2-aarch64-code.fd),
not these images.
Then we should add edk2-aarch64 and edk2-ovmf to lcitool, to have
the distrib images in our generated Docker images.
Cleber, you added this test in commit 6fd52d671d ("Acceptance test:
add "boot_linux" tests"), can you have a look?
Well, it's not *that* simple. Names are not consistent across
distributions. I think if we want go that route we have to inspect
the *.json files in /usr/share/qemu/firmware to find the correct
distro firmware images.
Also note that at least fedora ships both verbose and non-verbose
images ...
kraxel@sirius ~# rpm -ql edk2-aarch64
[ ... ]
/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw
/usr/share/edk2/aarch64/QEMU_EFI-silent-pflash.raw
/usr/share/edk2/aarch64/QEMU_EFI.fd
/usr/share/edk2/aarch64/QEMU_EFI.silent.fd
/usr/share/edk2/aarch64/QEMU_VARS.fd
[ ... ]
/usr/share/qemu/firmware/60-edk2-aarch64.json
/usr/share/qemu/firmware/70-edk2-aarch64-verbose.json
... so maybe it is an option to use the distro images for the bios
tables test cases too.
Debian isn't quite so free with it's use of disk space although:
10:09:19 [root@zen:~] # dpkg -L qemu-efi-aarch64
/.
/usr
/usr/share
/usr/share/AAVMF
/usr/share/AAVMF/AAVMF_CODE.fd
/usr/share/AAVMF/AAVMF_VARS.fd
/usr/share/doc
/usr/share/doc/qemu-efi-aarch64
/usr/share/doc/qemu-efi-aarch64/changelog.Debian.gz
/usr/share/doc/qemu-efi-aarch64/copyright
/usr/share/qemu
/usr/share/qemu/firmware
/usr/share/qemu/firmware/60-edk2-aarch64.json
/usr/share/qemu-efi-aarch64
/usr/share/qemu-efi-aarch64/QEMU_EFI.fd
10:09:25 [root@zen:~] # md5sum /usr/share/AAVMF/AAVMF_CODE.fd
/usr/share/qemu-efi-aarch64/QEMU_EFI.fd
573b65b6e04981abb5b10afc8f30feea /usr/share/AAVMF/AAVMF_CODE.fd
99812e842b6b40add0d8f7766e0aac9e /usr/share/qemu-efi-aarch64/QEMU_EFI.fd
10:09:37 [root@zen:~] # ls -lh /usr/share/AAVMF/AAVMF_CODE.fd
/usr/share/qemu-efi-aarch64/QEMU_EFI.fd
-rw-r--r-- 1 root root 64M Aug 18 2021 /usr/share/AAVMF/AAVMF_CODE.fd
-rw-r--r-- 1 root root 2.0M Aug 18 2021
/usr/share/qemu-efi-aarch64/QEMU_EFI.fd
I think the QEMU_EFI.fd is the firmware and AAVF_CODE is the same
firmware but packaged in the "right" size of flash file.
However if we are to use the distro version (or at least favour it) do
we need to start encoding searches through common paths?
I'm also sympathetic to Peter's point that distros might just end up packaging
what we give them in pc-bios and we'll be back to square one. I'd favour
pc-bios having both a edk2-aarch64-code.fd and a edk2-aarch64-code-debug.fd.
Distro have security teams with crypto knowledge who track CVE vulns
and integrate fixes, often embedding their own certificates in the
UEFI image. They certainly don't use that old/unsecure version
QEMU provides (edk2-stable202008, current is edk2-stable202111).