All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.