linux-kernel - Re: mix of ACPICA regression and EFISTUB regression (Was: kernel >= v6.2 no longer boots on Apple's Virtualization.framework (x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAG8fp8Teu4G9JuenQrqGndFt2Gy+V4YgJ=hN1xX7AD940YKf3A@mail.gmail.com>
Date:   Sun, 28 May 2023 16:02:40 +0900
From:   Akihiro Suda <suda.kyoto@...il.com>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Bagas Sanjaya <bagasdotme@...il.com>,
        linux-efi@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Regressions <regressions@...ts.linux.dev>,
        Linux x86 <x86@...nel.org>,
        Linux ACPI <linux-acpi@...r.kernel.org>,
        Linux ACPICA <acpica-devel@...ts.linuxfoundation.org>,
        Linux Stable <stable@...r.kernel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Jianmin Lv <lvjianmin@...ngson.cn>,
        Huacai Chen <chenhuacai@...ngson.cn>,
        Robert Moore <robert.moore@...el.com>
Subject: Re: mix of ACPICA regression and EFISTUB regression (Was: kernel >=
 v6.2 no longer boots on Apple's Virtualization.framework (x86_64); likely to
 be related to ACPICA)

> 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@...nel.org>:
>
> On Sat, 27 May 2023 at 21:40, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > On Sat, May 27, 2023 at 11:42 AM Ard Biesheuvel <ardb@...nel.org> 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.