Hello Maintainers, I'd like ovmf-ia32 to install a file useable by QEMU's -bios option. Currently the package only installs OVMF32_CODE_4M.secboot.fd and OVMF32_VARS_4M.fd, but I believe I need a file that combines both code and vars. According to the wiki[1], I believe I can use the existing files using "-drive if=pflash,..." options, but that is not a great option for me. I've been using the file RELEASEIA32_OVMF.fd file from an edk2-nightly build repo[2] successfully, so I know this is possible. And it looks like its just building using the upstream build system. Let me know if I can help with testing. Thanks, Glenn [1] https://wiki.debian.org/SecureBoot/VirtualMachine [2] https://github.com/retrage/edk2-nightly
severity 997913 wishlist thanks Can you elaborate more on your use case? While we do provide such an image for X64, that is for backwards-compatibility only. -dann
On Thu, 28 Oct 2021 07:46:11 -0600 dann frazier <dannf@dannf.org> wrote: I'm working on GRUB2's test suite and it has tests that use QEMU for many of its tests. Specifically, I need the combined firmware file when testing the i386-efi target. Perhaps, I don't need a binary with combined code and vars. On the ARM and ARM64 EFI targets, I can pass the AAVMF32_CODE.fd to -bios just fine. So perhaps the IA32 firmware is built in such a way that the code file requires the vars, but could be build to not require it? IOW, why can't I just send the firmware CODE file to QEMU using -bios like I can with ARM and ARM64? Also, I don't need the secure boot feature of the firmware. The wiki leaves me with the suspicion that I may need to configure some of the firmware variables before I can boot successfully. Perhaps that would only be the case if I were wanting to boot with secure boot enabled. I'm also curious about the 4M in the file name. My guess is that it indicates a build option. Could this be part of the equation? Glenn
edk2's autopkgtest has a testing framework that tests OVMF32, and all the other archs, using -pflash. It also does tests with GRUB images (e.g. making sure signed versions work w/ SecureBoot enabled, unsigned versions do not). Let me know if it'd be useful to collaborate on that framework. Here's the main bit: https://salsa.debian.org/qemu-team/edk2/-/blob/debian/debian/python/UEFI/Qemu.py Why? I mean, why can't that testing use a throw-away pflash image for VARS like we do in edk2 autopkgtesting? I don't know if or why OVMF*_CODE doesn't work with -bios. Separate CODE/VARS is the most flexible build (and what people should use in production), so that's what we provide. I'd need to be convinced that there's a good reason to increase the size of the ovmf-ia32 deb for all users to support -bios mode. Please read through the README.Debian file (latest one from unstable). If that doesn't answer the above 2 points, let me know so I can clarify it there. -dann
On Thu, 28 Oct 2021 12:00:09 -0600 dann frazier <dannf@dannf.org> wrote: Thanks for the reference, this will be helpful in converting grub tests to use the pflash instead of -bios option. I'm wondering by the paths are hard-coded, when it seems that the purpose of the json files in /usr/share/qemu/firmware is to provide these paths. I'm guessing this code assumes a debian system and that the paths won't change much. Using the json files in the grub tests is more problematic because they are in bash. And yes, I could use jq, but I'm reluctant to add another dependency. I'm still mulling it over. Ok, actually, I can use the pflash. I was wanting to avoid that because it makes things more complicated. I thought it might be easier to get the combined file included and that it might be useful to others. I have now tesed using pflash and it does work. The issue is that I'd like to have the tests use paths standardized across distros. When using -bios, the -L option can be used to add to a search path to find the firmware file. Of course, this doesn't work if the filenames of the firmware aren't standardized. For ARM/ARM64, it looks like debian's path for the code and vars is fairly standard across distros, and to a lesser extent x86_64, but for i386 it looks like filenames and where they are on the filesystem vary widely. I'm seeing now that a good resolution to my issue may lie at the conjunction of QEMU, OVMF, and distro packaging. The best of both worlds would be to get a version of OVMF*_CODE that works with -bios. According to this (old?) document[1], builds using -D SECURE_BOOT_ENABLE, which I presume is the case here, must use pflash. So perhaps the best of both worlds isn't possible now. Is a build without secureboot equivalent to the file released in the original bug report? Yes the pflash mechanism is more flexible, and thus good to have, but the -bios option was nice because it was easier to use from a user perspective. Perhaps, QEMU really needs a -uefi option that's like the -bios option, which would set everything up based on defaults and looking through a search path like -bios. (yes, not a Debian issue) For my purposes, I don't need a writable vars, which I've tested by setting readonly to "on" for the vars pflash. So while adding extra flexibility, it also adds extra complexity (ie another point of failure). I'm not sure what you might need to be convinced, but I notice that both Arch and Fedora are shipping a 32-bit OVMF with and without secureboot. I'm not seeing that in the ovmf-ia32 package (version 2021.08-3). Which packages should that be in? Glenn [1] https://www.virtualbox.org/svn/vbox/trunk/src/VBox/Devices/EFI/Firmware/OvmfPkg/README
(sorry for the late response) That's a good point, parsing the descriptors would be more portable (and also let us test the descriptors). Yes to both Yes, we do build w/ SECURE_BOOT_ENABLE, so that makes sense. RELEASEIA32_OVMF.fd? Yeah, that'd be my guess. My concern is about increasing the size of the package to satisfy a use case that already has an alternative - and TBH - the extra time it takes to test build edk2 w/ yet another image. The ease of using -bios vs. -pflash w/ qemu isn't overly convincing - qemu's syntax is complicated and tools like libvirt can abstract those But I'm not strongly opposed - if it would make testing GRUB on Debian more convenient, that may be a good enough reason to do it. I should fix that. We're only providing that file in the ovmf package, even though it also describes the images in the ovmf-ia32 package. -dann