> 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? Surprisingly, v2.0 and v3.0 boot, although v1.1, v2.1, v2.2, v3.1, etc. do not boot. Looks like Apple's vmlinuz loader only requires LINUX_EFISTUB_MINOR_VERSION to be 0x0 and does not care about LINUX_EFISTUB_MAJOR_VERSION. 2023年5月28日(日) 6:48 Ard Biesheuvel <ardb@xxxxxxxxxx>: > > 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.
