On Sat, 27 May 2023 at 21:40, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Sat, May 27, 2023 at 11:42 AM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > Yes, that makes the most sense. If the existing virtual machine BIOS > > has a hardcoded check that the EFI stub version is 1.0 even if it does > > not boot via EFI to begin with, I don't see how we can reasonably > > treat this as a regression that needs fixing on the Linux side. > > Well, we consider firmware issues to be the same as any hardware > issue. If firmware has a bug that requires us to do things certain > ways, that's really no different from hardware that requires some > insane init sequence. > > So why not just say that LINUX_EFISTUB_MINOR_VERSION should be 0, and > just add the comment that versioning doesn't work? > Fair enough. Or we could try bumping it from v1.1 to v2.0 (or v3.0 if we make it a bit mask). Akihiro, would you mind checking if changing the major/minor to any of these values results in the same problem? Unfortunately, the only data point we have is that a non-EFI bootloader (which is unlikely to carry a PE/COFF loader) needs the byte at that specific offset to be 0x0, and we really have no idea why, or whether we could hit this in other ways (i.e., by changing the PE/COFF header to comply with new MS requirements for secure boot, which is another thing that is in progress) > I'm not sure why this was tied into always enabling the initrd command > line loader. > For x86, it doesn't actually make a difference, but on other architectures, the command line initrd= loader could be disabled, but that possibility was removed. The idea was that by bumping the version to v1.1 at the same time, generic EFI loaders would be able to identify this capability without arch specific conditionals in the logic. Currently, GRUB and systemd-stub check this version field, but only for v1.0 or higher. Upstream GRUB switched to this generic version of the EFI loader just this week, but does not actually use initrd= at all for EFI boot (on any architecture). > Numbered version checks are a fundamentally broken and stupid concept > anyway. Don't do them. Just leave it at zero, and maybe some day there > is a sane model that actually has a bitfield of capabilities and > requirements. > Yeah, maybe you're right. Currently, only a single feature is tied to LINUX_EFISTUB_MAJOR_VERSION==1 (LoadFile2 support for initrd loading), and this PE/COFF version field has no meaning to UEFI firmware itself, so we could simply treat these fields as bit masks if we wanted to (and setting the initrd command line loader bit for x86 would be redundant anyway) But not being able to freely set such a bit because some rarely used non-EFI BIOS implementation imposes requirements on the contents of the EFI specific image header is rather disappointing.
