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

["Philippe Mathieu-Daudé" <philippe.mathieu.daude@gmail.com>]

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).