Re: Analysis of slow distro boots in check-avocado (BootLinuxAarch64.test_virt_tcg*)

[Philippe Mathieu-Daudé]

On 23/2/22 11:10, Alex Bennée wrote:
> Gerd Hoffmann <kraxel@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).