- LINUX_EFISTUB_MAJOR_VERSION is bumped from 1 (0b1) to 3 (0b11).
The value is now a bitfield. The next version will be 7 (0b111).
- LINUX_EFISTUB_MINOR_VERSION is pinned to 0x0, because Apple's
VZLinuxBootLoader [1] cannot boot a kernel with other minor version value [2],
even though it does not use UEFI. Tested with macOS 13.4 (x86_64).
[1] https://developer.apple.com/documentation/virtualization/vzlinuxbootloader
[2] https://lore.kernel.org/linux-efi/CAG8fp8Teu4G9JuenQrqGndFt2Gy+V4YgJ=hN1xX7AD940YKf3A@mail.gmail.com/
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217485
Signed-off-by: Akihiro Suda <[email protected]>
---
include/linux/pe.h | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/include/linux/pe.h b/include/linux/pe.h
index 5e1e11540870..ee5ade19b7eb 100644
--- a/include/linux/pe.h
+++ b/include/linux/pe.h
@@ -27,9 +27,25 @@
* On x86, LoadImage() and StartImage() can be omitted if the EFI handover
* protocol is implemented, which can be inferred from the version,
* handover_offset and xloadflags fields in the bootparams structure.
+ *
+ * Linux EFI stub v1.1 unconditionally enabled initrd command line loader,
+ * which was previously gated by CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER.
+ *
+ * Linux EFI stub v3.0 changed the major version to be a bitfield (0b11).
+ * The rightmost bit means that it is compatible with v1.0 at least.
+ * The second rightmost bit means that initrd command line loader is enabled.
+ * So, there is no v2.0 (0b10), and the next version will be v7.0 (0b111).
+ */
+#define LINUX_EFISTUB_MAJOR_VERSION 0x3
+
+/*
+ * LINUX_EFISTUB_MINOR_VERSION is pinned to 0x0, because Apple's
+ * VZLinuxBootLoader cannot boot a kernel with other minor version value, even
+ * though it does not use UEFI. Tested with macOS 13.4 (x86_64).
+ *
+ * https://lore.kernel.org/linux-efi/CAG8fp8Teu4G9JuenQrqGndFt2Gy+V4YgJ=hN1xX7AD940YKf3A@mail.gmail.com/
*/
-#define LINUX_EFISTUB_MAJOR_VERSION 0x1
-#define LINUX_EFISTUB_MINOR_VERSION 0x1
+#define LINUX_EFISTUB_MINOR_VERSION 0x0
/*
* LINUX_PE_MAGIC appears at offset 0x38 into the MS-DOS header of EFI bootable
--
2.39.2
On Sun, 28 May 2023 at 09:59, Akihiro Suda <[email protected]> wrote:
>
> - LINUX_EFISTUB_MAJOR_VERSION is bumped from 1 (0b1) to 3 (0b11).
> The value is now a bitfield.
>
OK
> The next version will be 7 (0b111).
How so? If this is going to be a monotonically increasing sequence
after all, it is still not a bit mask, and this change defeats the
purpose.
> - LINUX_EFISTUB_MINOR_VERSION is pinned to 0x0, because Apple's
> VZLinuxBootLoader [1] cannot boot a kernel with other minor version value [2],
> even though it does not use UEFI. Tested with macOS 13.4 (x86_64).
>
> [1] https://developer.apple.com/documentation/virtualization/vzlinuxbootloader
> [2] https://lore.kernel.org/linux-efi/CAG8fp8Teu4G9JuenQrqGndFt2Gy+V4YgJ=hN1xX7AD940YKf3A@mail.gmail.com/
>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217485
> Signed-off-by: Akihiro Suda <[email protected]>
I'll queue this as a fix, but I'm going to tweak the comment (and the
commit log) a bit, if you don't mind
I'd appreciate it if you still report this as a bug with Apple, though.
Thanks,
Ard.
> ---
> include/linux/pe.h | 20 ++++++++++++++++++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/pe.h b/include/linux/pe.h
> index 5e1e11540870..ee5ade19b7eb 100644
> --- a/include/linux/pe.h
> +++ b/include/linux/pe.h
> @@ -27,9 +27,25 @@
> * On x86, LoadImage() and StartImage() can be omitted if the EFI handover
> * protocol is implemented, which can be inferred from the version,
> * handover_offset and xloadflags fields in the bootparams structure.
> + *
> + * Linux EFI stub v1.1 unconditionally enabled initrd command line loader,
> + * which was previously gated by CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER.
> + *
> + * Linux EFI stub v3.0 changed the major version to be a bitfield (0b11).
> + * The rightmost bit means that it is compatible with v1.0 at least.
> + * The second rightmost bit means that initrd command line loader is enabled.
> + * So, there is no v2.0 (0b10), and the next version will be v7.0 (0b111).
> + */
> +#define LINUX_EFISTUB_MAJOR_VERSION 0x3
> +
> +/*
> + * LINUX_EFISTUB_MINOR_VERSION is pinned to 0x0, because Apple's
> + * VZLinuxBootLoader cannot boot a kernel with other minor version value, even
> + * though it does not use UEFI. Tested with macOS 13.4 (x86_64).
> + *
> + * https://lore.kernel.org/linux-efi/CAG8fp8Teu4G9JuenQrqGndFt2Gy+V4YgJ=hN1xX7AD940YKf3A@mail.gmail.com/
> */
> -#define LINUX_EFISTUB_MAJOR_VERSION 0x1
> -#define LINUX_EFISTUB_MINOR_VERSION 0x1
> +#define LINUX_EFISTUB_MINOR_VERSION 0x0
>
> /*
> * LINUX_PE_MAGIC appears at offset 0x38 into the MS-DOS header of EFI bootable
> --
> 2.39.2
> > The next version will be 7 (0b111).
>
> How so? If this is going to be a monotonically increasing sequence
> after all, it is still not a bit mask, and this change defeats the
> purpose.
Sorry, I forgot to append ", if it will retain compatibility with 0b11".
> I'll queue this as a fix, but I'm going to tweak the comment (and the
> commit log) a bit, if you don't mind
Thanks, please feel free to tweak that.
> I'd appreciate it if you still report this as a bug with Apple, though.
Reported via https://www.apple.com/feedback/macos.html
2023年5月29日(月) 3:48 Ard Biesheuvel <[email protected]>:
>
> On Sun, 28 May 2023 at 09:59, Akihiro Suda <[email protected]> wrote:
> >
> > - LINUX_EFISTUB_MAJOR_VERSION is bumped from 1 (0b1) to 3 (0b11).
> > The value is now a bitfield.
> >
>
> OK
>
> > The next version will be 7 (0b111).
>
> How so? If this is going to be a monotonically increasing sequence
> after all, it is still not a bit mask, and this change defeats the
> purpose.
>
> > - LINUX_EFISTUB_MINOR_VERSION is pinned to 0x0, because Apple's
> > VZLinuxBootLoader [1] cannot boot a kernel with other minor version value [2],
> > even though it does not use UEFI. Tested with macOS 13.4 (x86_64).
> >
> > [1] https://developer.apple.com/documentation/virtualization/vzlinuxbootloader
> > [2] https://lore.kernel.org/linux-efi/CAG8fp8Teu4G9JuenQrqGndFt2Gy+V4YgJ=hN1xX7AD940YKf3A@mail.gmail.com/
> >
> > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217485
> > Signed-off-by: Akihiro Suda <[email protected]>
>
> I'll queue this as a fix, but I'm going to tweak the comment (and the
> commit log) a bit, if you don't mind
>
> I'd appreciate it if you still report this as a bug with Apple, though.
>
> Thanks,
> Ard.
>
> > ---
> > include/linux/pe.h | 20 ++++++++++++++++++--
> > 1 file changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/pe.h b/include/linux/pe.h
> > index 5e1e11540870..ee5ade19b7eb 100644
> > --- a/include/linux/pe.h
> > +++ b/include/linux/pe.h
> > @@ -27,9 +27,25 @@
> > * On x86, LoadImage() and StartImage() can be omitted if the EFI handover
> > * protocol is implemented, which can be inferred from the version,
> > * handover_offset and xloadflags fields in the bootparams structure.
> > + *
> > + * Linux EFI stub v1.1 unconditionally enabled initrd command line loader,
> > + * which was previously gated by CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER.
> > + *
> > + * Linux EFI stub v3.0 changed the major version to be a bitfield (0b11).
> > + * The rightmost bit means that it is compatible with v1.0 at least.
> > + * The second rightmost bit means that initrd command line loader is enabled.
> > + * So, there is no v2.0 (0b10), and the next version will be v7.0 (0b111).
> > + */
> > +#define LINUX_EFISTUB_MAJOR_VERSION 0x3
> > +
> > +/*
> > + * LINUX_EFISTUB_MINOR_VERSION is pinned to 0x0, because Apple's
> > + * VZLinuxBootLoader cannot boot a kernel with other minor version value, even
> > + * though it does not use UEFI. Tested with macOS 13.4 (x86_64).
> > + *
> > + * https://lore.kernel.org/linux-efi/CAG8fp8Teu4G9JuenQrqGndFt2Gy+V4YgJ=hN1xX7AD940YKf3A@mail.gmail.com/
> > */
> > -#define LINUX_EFISTUB_MAJOR_VERSION 0x1
> > -#define LINUX_EFISTUB_MINOR_VERSION 0x1
> > +#define LINUX_EFISTUB_MINOR_VERSION 0x0
> >
> > /*
> > * LINUX_PE_MAGIC appears at offset 0x38 into the MS-DOS header of EFI bootable
> > --
> > 2.39.2
> > I'll queue this as a fix, but I'm going to tweak the comment (and the
> > commit log) a bit, if you don't mind
Thank you for rewriting my comments, but the new comments seem
slightly incorrect:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=36e4fc57fc1619f462e669e939209c45763bc8f5
> efi: Bump stub image version for macOS HVF compatibility
The commit is about Virtualization.framework, not about
Hypervisor.framework (HVF).
Virtualization.framework = high-level VMM, similar to QEMU
(/usr/bin/qemu-system-*)
Hypervisor.framework = low-level VMM, similar to kvm.ko
> The macOS hypervisor framework includes a host-side VMM called VZLinuxBootLoader
VZLinuxBootLoader is a part of Virtualization.framework, not
Hypervisor.framework.
Also, VZLinuxBootLoader is not a VMM; it is just an API for loading
vmlinuz into Virtualization.framework.
(similar to the `-kernel` and the `-initrd` flags of QEMU)
> On x86, it incorporates a BIOS style loader that does not implement or expose EFI to the loaded kernel.
AFAICS, it does not seem to use real mode BIOS.
2023年5月29日(月) 9:51 Akihiro Suda <[email protected]>:
>
> > > The next version will be 7 (0b111).
> >
> > How so? If this is going to be a monotonically increasing sequence
> > after all, it is still not a bit mask, and this change defeats the
> > purpose.
>
> Sorry, I forgot to append ", if it will retain compatibility with 0b11".
>
> > I'll queue this as a fix, but I'm going to tweak the comment (and the
> > commit log) a bit, if you don't mind
>
> Thanks, please feel free to tweak that.
>
> > I'd appreciate it if you still report this as a bug with Apple, though.
>
> Reported via https://www.apple.com/feedback/macos.html
>
>
> 2023年5月29日(月) 3:48 Ard Biesheuvel <[email protected]>:
> >
> > On Sun, 28 May 2023 at 09:59, Akihiro Suda <[email protected]> wrote:
> > >
> > > - LINUX_EFISTUB_MAJOR_VERSION is bumped from 1 (0b1) to 3 (0b11).
> > > The value is now a bitfield.
> > >
> >
> > OK
> >
> > > The next version will be 7 (0b111).
> >
> > How so? If this is going to be a monotonically increasing sequence
> > after all, it is still not a bit mask, and this change defeats the
> > purpose.
> >
> > > - LINUX_EFISTUB_MINOR_VERSION is pinned to 0x0, because Apple's
> > > VZLinuxBootLoader [1] cannot boot a kernel with other minor version value [2],
> > > even though it does not use UEFI. Tested with macOS 13.4 (x86_64).
> > >
> > > [1] https://developer.apple.com/documentation/virtualization/vzlinuxbootloader
> > > [2] https://lore.kernel.org/linux-efi/CAG8fp8Teu4G9JuenQrqGndFt2Gy+V4YgJ=hN1xX7AD940YKf3A@mail.gmail.com/
> > >
> > > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217485
> > > Signed-off-by: Akihiro Suda <[email protected]>
> >
> > I'll queue this as a fix, but I'm going to tweak the comment (and the
> > commit log) a bit, if you don't mind
> >
> > I'd appreciate it if you still report this as a bug with Apple, though.
> >
> > Thanks,
> > Ard.
> >
> > > ---
> > > include/linux/pe.h | 20 ++++++++++++++++++--
> > > 1 file changed, 18 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/include/linux/pe.h b/include/linux/pe.h
> > > index 5e1e11540870..ee5ade19b7eb 100644
> > > --- a/include/linux/pe.h
> > > +++ b/include/linux/pe.h
> > > @@ -27,9 +27,25 @@
> > > * On x86, LoadImage() and StartImage() can be omitted if the EFI handover
> > > * protocol is implemented, which can be inferred from the version,
> > > * handover_offset and xloadflags fields in the bootparams structure.
> > > + *
> > > + * Linux EFI stub v1.1 unconditionally enabled initrd command line loader,
> > > + * which was previously gated by CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER.
> > > + *
> > > + * Linux EFI stub v3.0 changed the major version to be a bitfield (0b11).
> > > + * The rightmost bit means that it is compatible with v1.0 at least.
> > > + * The second rightmost bit means that initrd command line loader is enabled.
> > > + * So, there is no v2.0 (0b10), and the next version will be v7.0 (0b111).
> > > + */
> > > +#define LINUX_EFISTUB_MAJOR_VERSION 0x3
> > > +
> > > +/*
> > > + * LINUX_EFISTUB_MINOR_VERSION is pinned to 0x0, because Apple's
> > > + * VZLinuxBootLoader cannot boot a kernel with other minor version value, even
> > > + * though it does not use UEFI. Tested with macOS 13.4 (x86_64).
> > > + *
> > > + * https://lore.kernel.org/linux-efi/CAG8fp8Teu4G9JuenQrqGndFt2Gy+V4YgJ=hN1xX7AD940YKf3A@mail.gmail.com/
> > > */
> > > -#define LINUX_EFISTUB_MAJOR_VERSION 0x1
> > > -#define LINUX_EFISTUB_MINOR_VERSION 0x1
> > > +#define LINUX_EFISTUB_MINOR_VERSION 0x0
> > >
> > > /*
> > > * LINUX_PE_MAGIC appears at offset 0x38 into the MS-DOS header of EFI bootable
> > > --
> > > 2.39.2
On Fri, 2 Jun 2023 at 22:30, Akihiro Suda <[email protected]> wrote:
>
> > > I'll queue this as a fix, but I'm going to tweak the comment (and the
> > > commit log) a bit, if you don't mind
>
> Thank you for rewriting my comments, but the new comments seem
> slightly incorrect:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=36e4fc57fc1619f462e669e939209c45763bc8f5
>
> > efi: Bump stub image version for macOS HVF compatibility
>
> The commit is about Virtualization.framework, not about
> Hypervisor.framework (HVF).
>
> Virtualization.framework = high-level VMM, similar to QEMU
> (/usr/bin/qemu-system-*)
> Hypervisor.framework = low-level VMM, similar to kvm.ko
>
> > The macOS hypervisor framework includes a host-side VMM called VZLinuxBootLoader
>
> VZLinuxBootLoader is a part of Virtualization.framework, not
> Hypervisor.framework.
> Also, VZLinuxBootLoader is not a VMM; it is just an API for loading
> vmlinuz into Virtualization.framework.
> (similar to the `-kernel` and the `-initrd` flags of QEMU)
>
Apologies for these mistakes. Unfortunately, this patch has been
merged now so there is nothing we can do about it.
> > On x86, it incorporates a BIOS style loader that does not implement or expose EFI to the loaded kernel.
>
> AFAICS, it does not seem to use real mode BIOS.
>
I never mentioned real mode, did I?
> > > On x86, it incorporates a BIOS style loader that does not implement or expose EFI to the loaded kernel.
> >
> > AFAICS, it does not seem to use real mode BIOS.
> >
>
> I never mentioned real mode, did I?
Sorry, I just misinterpreted "BIOS style loader".
2023年6月3日(土) 7:52 Ard Biesheuvel <[email protected]>:
>
> On Fri, 2 Jun 2023 at 22:30, Akihiro Suda <[email protected]> wrote:
> >
> > > > I'll queue this as a fix, but I'm going to tweak the comment (and the
> > > > commit log) a bit, if you don't mind
> >
> > Thank you for rewriting my comments, but the new comments seem
> > slightly incorrect:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=36e4fc57fc1619f462e669e939209c45763bc8f5
> >
> > > efi: Bump stub image version for macOS HVF compatibility
> >
> > The commit is about Virtualization.framework, not about
> > Hypervisor.framework (HVF).
> >
> > Virtualization.framework = high-level VMM, similar to QEMU
> > (/usr/bin/qemu-system-*)
> > Hypervisor.framework = low-level VMM, similar to kvm.ko
> >
> > > The macOS hypervisor framework includes a host-side VMM called VZLinuxBootLoader
> >
> > VZLinuxBootLoader is a part of Virtualization.framework, not
> > Hypervisor.framework.
> > Also, VZLinuxBootLoader is not a VMM; it is just an API for loading
> > vmlinuz into Virtualization.framework.
> > (similar to the `-kernel` and the `-initrd` flags of QEMU)
> >
>
> Apologies for these mistakes. Unfortunately, this patch has been
> merged now so there is nothing we can do about it.
>
> > > On x86, it incorporates a BIOS style loader that does not implement or expose EFI to the loaded kernel.
> >
> > AFAICS, it does not seem to use real mode BIOS.
> >
>
> I never mentioned real mode, did I?