Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAG8fp8Te=oT1JJhTpOZvgWJrgcTq2DXan8UOVZ=KYCYNa8cKog@mail.gmail.com>
 <CAMj1kXG0q-pJEnvqJxxpecVqJcB2jk3rj7S4KNp728THM=de3Q@mail.gmail.com> <CAG8fp8Tnfb5tt3Eea4+=zznZLxBfqwha_wkQcPDvU4QhcSckEw@mail.gmail.com>
In-Reply-To: <CAG8fp8Tnfb5tt3Eea4+=zznZLxBfqwha_wkQcPDvU4QhcSckEw@mail.gmail.com>
From:   Akihiro Suda <suda.kyoto@gmail.com>
Date:   Sat, 3 Jun 2023 05:29:49 +0900
Message-ID: <CAG8fp8QbQqDVxEvzeyijbkfU5HoAwbRH0VptMK4-oPnJ7-0Ljg@mail.gmail.com>
Subject: Re: [PATCH] efi: bump efistub version from 1.1 to 3.0 for
 VZLinuxBootLoader compatibility
To:     Ard Biesheuvel <ardb@kernel.org>
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-efi@vger.kernel.org, Linux x86 <x86@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

> > 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=3D36e4fc57fc1619f462e669e939209c45763bc8f5

> efi: Bump stub image version for macOS HVF compatibility

The commit is about Virtualization.framework, not about
Hypervisor.framework (HVF).

Virtualization.framework =3D high-level VMM, similar to QEMU
(/usr/bin/qemu-system-*)
Hypervisor.framework     =3D low-level  VMM, similar to kvm.ko

> The macOS hypervisor framework includes a host-side VMM called VZLinuxBoo=
tLoader

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 ex=
pose EFI to the loaded kernel.

AFAICS, it does not seem to use real mode BIOS.


2023=E5=B9=B45=E6=9C=8829=E6=97=A5(=E6=9C=88) 9:51 Akihiro Suda <suda.kyoto=
@gmail.com>:
>
> > > 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=E5=B9=B45=E6=9C=8829=E6=97=A5(=E6=9C=88) 3:48 Ard Biesheuvel <ardb@k=
ernel.org>:
> >
> > On Sun, 28 May 2023 at 09:59, Akihiro Suda <suda.kyoto@gmail.com> 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/vzlinuxb=
ootloader
> > > [2] https://lore.kernel.org/linux-efi/CAG8fp8Teu4G9JuenQrqGndFt2Gy+V4=
YgJ=3DhN1xX7AD940YKf3A@mail.gmail.com/
> > >
> > > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=3D217485
> > > Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
> >
> > 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 ha=
ndover
> > >   * 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 l=
oader,
> > > + * which was previously gated by CONFIG_EFI_GENERIC_STUB_INITRD_CMDL=
INE_LOADER.
> > > + *
> > > + * Linux EFI stub v3.0 changed the major version to be a bitfield (0=
b11).
> > > + * 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 (0=
b111).
> > > + */
> > > +#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 v=
alue, even
> > > + * though it does not use UEFI. Tested with macOS 13.4 (x86_64).
> > > + *
> > > + * https://lore.kernel.org/linux-efi/CAG8fp8Teu4G9JuenQrqGndFt2Gy+V4=
YgJ=3DhN1xX7AD940YKf3A@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 E=
FI bootable
> > > --
> > > 2.39.2