public inbox for linux-efi@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>,
	linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
	x86@kernel.org, hdegoede@redhat.com
Subject: Re: [PATCH v2 0/7] x86/efi/mixed: Decouple from legacy decompressor
Date: Fri, 21 Feb 2025 16:42:51 +0100	[thread overview]
Message-ID: <Z7ie-zG0cJFX0MOz@gmail.com> (raw)
In-Reply-To: <CAMj1kXHOqMM5uGxLTYuEf9KrxY5WzYvwo847JzoB-Qa2SN67Sg@mail.gmail.com>


* Ard Biesheuvel <ardb@kernel.org> wrote:

> On Mon, 10 Feb 2025 at 18:50, Ard Biesheuvel <ardb+git@google.com> wrote:
> >
> > From: Ard Biesheuvel <ardb@kernel.org>
> >
> > Since commit
> >
> >   a1b87d54f4e4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot")
> >
> > booting via the EFI stub no longer relies on the legacy decompressor,
> > and instead, the kernel proper is decompressed by code executing in the
> > context of the EFI boot services, and subsequently invoked directly.
> >
> > The only remaining dependency is the EFI mixed mode startup code, which
> > makes a detour via the legacy decompressor's 32-bit entrypoint, in order
> > to obtain a 1:1 mapping of memory, which is a prerequisite for 64-bit
> > execution on x86.
> >
> > This detour requires some fiddly setup on the part of the mixed mode
> > startup code, which has to stash the firmware stack pointer and boot
> > arguments in memory, and create a fake struct boot_params to trick the
> > code in startup_32 to behave as intended.
> >
> > This dependency also impedes reuse of the EFI stub code in other
> > contexts, such as generic EFI zboot, which will reuse the EFI stub but
> > not the legacy decompressor.
> >
> > So remove this dependency, by replacing this detour with a minimal
> > reimplementation of the 1:1 mapping code. With some further cleanup
> > applied on top, the line count drops substantially, but without loss of
> > functionality. The resulting code can operate independently from the
> > legacy decompressor, and is therefore moved out of arch/x86/boot/ and
> > into the EFI libstub/ directory.
> >
> > Changes since v1 [0]:
> > - Create new long mode GDT that extends the firmware's 32-bit only GDT
> >   so that preserving/restoring data segment selectors or swapping out
> >   GDTs and IDTs is no longer needed at all.
> > - Rebase onto v6.14-rc1
> >
> > [0] https://lore.kernel.org/all/20250108182218.1453754-8-ardb+git@google.com/
> >
> > Ard Biesheuvel (7):
> >   x86/efistub: Merge PE and handover entrypoints
> >   x86/efi/mixed: Check CPU compatibility without relying on verify_cpu()
> >   x86/efi/mixed: Factor out and clean up long mode entry
> >   x86/efi/mixed: Set up 1:1 mapping of lower 4GiB in the stub
> >   x86/efi/mixed: Remove dependency on legacy startup_32 code
> >   x86/efi/mixed: Simplify and document thunking logic
> >   x86/efi/mixed: Move mixed mode startup code into libstub
> >
> 
> Unless anyone minds, I'd like to queue this up in the EFI tree.
> 
> Boris, Ingo?

Sure!

Acked-by: Ingo Molnar <mingo@kernel.org>

Thanks,

	Ingo

      parent reply	other threads:[~2025-02-21 15:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-10 17:49 [PATCH v2 0/7] x86/efi/mixed: Decouple from legacy decompressor Ard Biesheuvel
2025-02-10 17:49 ` [PATCH v2 1/7] x86/efistub: Merge PE and handover entrypoints Ard Biesheuvel
2025-02-10 17:49 ` [PATCH v2 2/7] x86/efi/mixed: Check CPU compatibility without relying on verify_cpu() Ard Biesheuvel
2025-02-10 17:49 ` [PATCH v2 3/7] x86/efi/mixed: Factor out and clean up long mode entry Ard Biesheuvel
2025-02-10 17:49 ` [PATCH v2 4/7] x86/efi/mixed: Set up 1:1 mapping of lower 4GiB in the stub Ard Biesheuvel
2025-02-10 17:49 ` [PATCH v2 5/7] x86/efi/mixed: Remove dependency on legacy startup_32 code Ard Biesheuvel
2025-02-10 17:49 ` [PATCH v2 6/7] x86/efi/mixed: Simplify and document thunking logic Ard Biesheuvel
2025-02-10 17:49 ` [PATCH v2 7/7] x86/efi/mixed: Move mixed mode startup code into libstub Ard Biesheuvel
2025-02-20 11:29 ` [PATCH v2 0/7] x86/efi/mixed: Decouple from legacy decompressor Ard Biesheuvel
2025-02-20 12:48   ` Borislav Petkov
2025-02-20 12:54     ` Ard Biesheuvel
2025-02-20 13:38       ` Hans de Goede
2025-02-27 10:57         ` Ard Biesheuvel
2025-02-21 15:42   ` Ingo Molnar [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z7ie-zG0cJFX0MOz@gmail.com \
    --to=mingo@kernel.org \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=hdegoede@redhat.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox