[GIT PULL] EFI updates for v6.15

[GIT PULL] EFI updates for v6.15

[Ard Biesheuvel]

From: Ard Biesheuvel <ardb@kernel.org>

Hi Linus,

Please pull the EFI updates for this cycle. Details are in the tag.


The following changes since commit 7eb172143d5508b4da468ed59ee857c6e5e01da6:

  Linux 6.14-rc5 (2025-03-02 11:48:20 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-next-for-v6.15

for you to fetch changes up to 0dc1754e16b4c14ae42f6cf59f319331d885f0f6:

  efi/libstub: Avoid legacy decompressor zlib/zstd wrappers (2025-03-14 12:36:11 +0100)

----------------------------------------------------------------
EFI updates for v6.15

- Decouple mixed mode startup code from the traditional x86 decompressor

- Revert zero-length file hack in efivarfs

- Prevent EFI zboot from using the CopyMem/SetMem boot services after
  ExitBootServices()

- Update EFI zboot to use the ZLIB/ZSTD library interfaces directly

----------------------------------------------------------------
Ard Biesheuvel (11):
      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
      Merge branch 'x86-mixed-mode' into efi/next
      efivarfs: Revert "allow creation of zero length files"
      efi/libstub: Avoid CopyMem/SetMem EFI services after ExitBootServices
      efi/libstub: Avoid legacy decompressor zlib/zstd wrappers

Ethan Carter Edwards (1):
      efi: efibc: change kmalloc(size * count, ...) to kmalloc_array()

 arch/x86/boot/compressed/Makefile                  |   1 -
 arch/x86/boot/compressed/efi_mixed.S               | 341 ---------------------
 arch/x86/boot/compressed/head_64.S                 |   7 -
 drivers/firmware/efi/efibc.c                       |   2 +-
 drivers/firmware/efi/libstub/Makefile              |  10 +-
 drivers/firmware/efi/libstub/efistub.h             |   3 +
 drivers/firmware/efi/libstub/intrinsics.c          |  26 ++
 drivers/firmware/efi/libstub/x86-mixed.S           | 253 +++++++++++++++
 drivers/firmware/efi/libstub/x86-stub.c            |  52 ++--
 .../firmware/efi/libstub/zboot-decompress-gzip.c   |  68 ++++
 .../firmware/efi/libstub/zboot-decompress-zstd.c   |  49 +++
 drivers/firmware/efi/libstub/zboot.c               |  65 +---
 drivers/firmware/efi/libstub/zboot.lds             |   1 +
 fs/efivarfs/file.c                                 |  10 +-
 14 files changed, 452 insertions(+), 436 deletions(-)
 delete mode 100644 arch/x86/boot/compressed/efi_mixed.S
 create mode 100644 drivers/firmware/efi/libstub/x86-mixed.S
 create mode 100644 drivers/firmware/efi/libstub/zboot-decompress-gzip.c
 create mode 100644 drivers/firmware/efi/libstub/zboot-decompress-zstd.c

Re: [GIT PULL] EFI updates for v6.15

[Linus Torvalds]

On Fri, 28 Mar 2025 at 00:05, Ard Biesheuvel <ardb+git@google.com> wrote:
>
>  arch/x86/boot/compressed/efi_mixed.S               | 341 ---------------------
>  drivers/firmware/efi/libstub/x86-mixed.S           | 253 +++++++++++++++

I've pulled this, but I'm not super-happy about it.

We have been pretty successful in keeping assembler files in the arch/
directory, and I really think we should strive to continue that.

Do we have a few drivers that have arch-specific assembly code? Yes.
But it certainly isn't something to make more common.

And did we already do that zboot-header.S thing earlier? Also yes, but
that one is afaik actually architecture-neutral and doesn't have any
architecture *instructions* in it, it's just data layout afaik (and
no, I don't know why it was done as a '*.S' file)

IOW, I really wish you would move this back to arch/x86 somewhere. Please?

               Linus

Re: [GIT PULL] EFI updates for v6.15

[Ard Biesheuvel]

(cc Ingo)

On Sat, 29 Mar 2025 at 19:46, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Fri, 28 Mar 2025 at 00:05, Ard Biesheuvel <ardb+git@google.com> wrote:
> >
> >  arch/x86/boot/compressed/efi_mixed.S               | 341 ---------------------
> >  drivers/firmware/efi/libstub/x86-mixed.S           | 253 +++++++++++++++
>
> I've pulled this, but I'm not super-happy about it.
>
> We have been pretty successful in keeping assembler files in the arch/
> directory, and I really think we should strive to continue that.
>
> Do we have a few drivers that have arch-specific assembly code? Yes.
> But it certainly isn't something to make more common.
>
> And did we already do that zboot-header.S thing earlier? Also yes, but
> that one is afaik actually architecture-neutral and doesn't have any
> architecture *instructions* in it, it's just data layout afaik (and
> no, I don't know why it was done as a '*.S' file)
>
> IOW, I really wish you would move this back to arch/x86 somewhere. Please?
>

Fair enough. Note that this applies to la57toggle.S as well, which was
moved in a patch that went via the -tip tree this cycle.

It doesn't matter that much where the files live, as long as they are
disentangled from the traditional decompressor. (For C files, it is
important that they are built using the EFI stub's C flags, but for
asm files, that makes little difference)

Does arch/x86/lib sound like a reasonable place?

Re: [GIT PULL] EFI updates for v6.15

[Linus Torvalds]

On Sat, 29 Mar 2025 at 12:08, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> Does arch/x86/lib sound like a reasonable place?

Sounds entirely reasonable to me, with something like "efistub" in the
filename (perhaps even as a subdirectory if there's more than one or
two of these things).

               Linus

Re: [GIT PULL] EFI updates for v6.15

[pr-tracker-bot]

The pull request you sent on Fri, 28 Mar 2025 08:05:26 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-next-for-v6.15

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1fa753c7b5b91c31a8efc80d74acbbfb391a9e7c

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] EFI updates for v6.15

[Ingo Molnar]

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

> (cc Ingo)
> 
> On Sat, 29 Mar 2025 at 19:46, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > On Fri, 28 Mar 2025 at 00:05, Ard Biesheuvel <ardb+git@google.com> wrote:
> > >
> > >  arch/x86/boot/compressed/efi_mixed.S               | 341 ---------------------
> > >  drivers/firmware/efi/libstub/x86-mixed.S           | 253 +++++++++++++++
> >
> > I've pulled this, but I'm not super-happy about it.
> >
> > We have been pretty successful in keeping assembler files in the 
> > arch/ directory, and I really think we should strive to continue 
> > that.
> >
> > Do we have a few drivers that have arch-specific assembly code? 
> > Yes. But it certainly isn't something to make more common.
> >
> > And did we already do that zboot-header.S thing earlier? Also yes, 
> > but that one is afaik actually architecture-neutral and doesn't 
> > have any architecture *instructions* in it, it's just data layout 
> > afaik (and no, I don't know why it was done as a '*.S' file)
> >
> > IOW, I really wish you would move this back to arch/x86 somewhere. 
> > Please?
> >
> 
> Fair enough. Note that this applies to la57toggle.S as well, which 
> was moved in a patch that went via the -tip tree this cycle.
> 
> It doesn't matter that much where the files live, as long as they are 
> disentangled from the traditional decompressor. (For C files, it is 
> important that they are built using the EFI stub's C flags, but for 
> asm files, that makes little difference)
> 
> Does arch/x86/lib sound like a reasonable place?

So all of this is boot code (early EFI runtime calls), right? Please 
move anything fundamentally low level boot related to arch/x86/boot/. 
We can open up arch/x86/boot/efi/ or so, to decouple it from the 
decompressor.

Thanks,

	Ingo

Re: [GIT PULL] EFI updates for v6.15

[Ard Biesheuvel]

On Sun, 30 Mar 2025 at 10:10, Ingo Molnar <mingo@kernel.org> wrote:
>
>
> * Ard Biesheuvel <ardb@kernel.org> wrote:
>
> > (cc Ingo)
> >
> > On Sat, 29 Mar 2025 at 19:46, Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> > >
> > > On Fri, 28 Mar 2025 at 00:05, Ard Biesheuvel <ardb+git@google.com> wrote:
> > > >
> > > >  arch/x86/boot/compressed/efi_mixed.S               | 341 ---------------------
> > > >  drivers/firmware/efi/libstub/x86-mixed.S           | 253 +++++++++++++++
> > >
> > > I've pulled this, but I'm not super-happy about it.
> > >
> > > We have been pretty successful in keeping assembler files in the
> > > arch/ directory, and I really think we should strive to continue
> > > that.
> > >
> > > Do we have a few drivers that have arch-specific assembly code?
> > > Yes. But it certainly isn't something to make more common.
> > >
> > > And did we already do that zboot-header.S thing earlier? Also yes,
> > > but that one is afaik actually architecture-neutral and doesn't
> > > have any architecture *instructions* in it, it's just data layout
> > > afaik (and no, I don't know why it was done as a '*.S' file)
> > >
> > > IOW, I really wish you would move this back to arch/x86 somewhere.
> > > Please?
> > >
> >
> > Fair enough. Note that this applies to la57toggle.S as well, which
> > was moved in a patch that went via the -tip tree this cycle.
> >
> > It doesn't matter that much where the files live, as long as they are
> > disentangled from the traditional decompressor. (For C files, it is
> > important that they are built using the EFI stub's C flags, but for
> > asm files, that makes little difference)
> >
> > Does arch/x86/lib sound like a reasonable place?
>
> So all of this is boot code (early EFI runtime calls), right? Please
> move anything fundamentally low level boot related to arch/x86/boot/.
> We can open up arch/x86/boot/efi/ or so, to decouple it from the
> decompressor.
>

As you surely remember, one of the other issues I am trying to solve
is the use of C code in the early startup code of the kernel proper
that needs to tolerate being executed from the 1:1 mapping of RAM
(i.e., all the C files that use RIP_REL_REF() currently). This is
mainly related to SEV-SNP and 5-level paging.

So there is code that
- is conceptually part of the EFI stub but written in asm (x86-mixed.S)
- is shared between the EFI stub and the decompressor (la57toggle.S)
- is conceptually part of the EFI stub but shares code with the
decompressor (handling of unaccepted memory when populating the e820
memory map from the EFI one)
- is split between the decompressor/EFI stub and kernel proper
(SME/SEV-SNP initialization)
- is only needed by the decompressor (SEV-SNP handling of 'demand
paging' logic and TDX/SEV acceptance of memory that was just carved
out based on the e820 map rather than allocated via the EFI APIs)
- early startup code in the kernel proper that creates the (4 or 5
level) kernel virtual mapping while executing from the 1:1 mapping.

IOW, absolute chaos.

I have been trying to disentangle this from the EFI side, but the
5-level paging and SEV-SNP/TDX code clearly needs some attention too.

What the C code has in common here is that it needs to be built in a
special way, i.e., PIC codegen with all instrumentation/paravirt/etc
disabled. And ideally, each object needs to be checked to ensure that
no absolute relocations are present.

So what I would like to propose for this arch/x86/boot/<something>
subdirectory is to move all these source files there, and build a
static library that can be pulled into the kernel proper as well as
the decompressor, using C flags etc that ensure that all code it
contains is safe for execution from the 1:1 mapping. This is how the
EFI stub static library is built, and also how the code in
arch/arm64/kernel/pi/ is constructed to ensure that it can safely run
from a virtual mapping that doesn't match the one the linker used at
build time.

How does that sound?

Re: [GIT PULL] EFI updates for v6.15

[Ingo Molnar]

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

> So what I would like to propose for this arch/x86/boot/<something> 
> subdirectory is to move all these source files there, and build a 
> static library that can be pulled into the kernel proper as well as 
> the decompressor, using C flags etc that ensure that all code it 
> contains is safe for execution from the 1:1 mapping. This is how the 
> EFI stub static library is built, and also how the code in 
> arch/arm64/kernel/pi/ is constructed to ensure that it can safely run 
> from a virtual mapping that doesn't match the one the linker used at 
> build time.
> 
> How does that sound?

Sounds fantastic, related code should be together, like friends around 
a campfire.

Proposed locations, if it's 99% boot/init code (SYSTEM_BOOTING code):

	arch/x86/boot/efi/
	arch/x86/boot/efi/lib/
	arch/x86/boot/efilib/
	arch/x86/boot/lib/efi/

... or if there's a substantial runtime code (SYSTEM_RUNNING code):

	arch/x86/platform/efi/   # <--- already exists
	arch/x86/kernel/efi/

I'm a bit against the arch/x86/lib/ location for the simple reason
that the x86 library functions are usually simple self-contained 
regular-runtime facilities in C or asm with very little magic, which 
the EFI boot/stub code is as far away from as technologically possible. 
;-)

Look into arch/x86/lib/ and you'll see that EFI functionality doesn't 
really fit there.

Thanks,

	Ingo

Re: [GIT PULL] EFI updates for v6.15

[Ard Biesheuvel]

On Mon, 31 Mar 2025 at 18:55, Ingo Molnar <mingo@kernel.org> wrote:
>
>
> * Ard Biesheuvel <ardb@kernel.org> wrote:
>
> > So what I would like to propose for this arch/x86/boot/<something>
> > subdirectory is to move all these source files there, and build a
> > static library that can be pulled into the kernel proper as well as
> > the decompressor, using C flags etc that ensure that all code it
> > contains is safe for execution from the 1:1 mapping. This is how the
> > EFI stub static library is built, and also how the code in
> > arch/arm64/kernel/pi/ is constructed to ensure that it can safely run
> > from a virtual mapping that doesn't match the one the linker used at
> > build time.
> >
> > How does that sound?
>
> Sounds fantastic, related code should be together, like friends around
> a campfire.
>
> Proposed locations, if it's 99% boot/init code (SYSTEM_BOOTING code):
>
>         arch/x86/boot/efi/
>         arch/x86/boot/efi/lib/
>         arch/x86/boot/efilib/
>         arch/x86/boot/lib/efi/
>
> ... or if there's a substantial runtime code (SYSTEM_RUNNING code):
>
>         arch/x86/platform/efi/   # <--- already exists
>         arch/x86/kernel/efi/
>

It is all boot code, along with some lower level plumbing that may be
shared with the runtime code, but that shouldn't matter
(Alternatively, we could have two copies but let's only do that when
needed)

My primary concern is that some of this code is used by non-EFI boot
as well, so perhaps an efi/ subdirectory is not the best place.

> I'm a bit against the arch/x86/lib/ location for the simple reason
> that the x86 library functions are usually simple self-contained
> regular-runtime facilities in C or asm with very little magic, which
> the EFI boot/stub code is as far away from as technologically possible.
> ;-)
>

Fair point.

> Look into arch/x86/lib/ and you'll see that EFI functionality doesn't
> really fit there.
>

Again, EFI is only one aspect of this. The SEV-SNP startup code and
the early 5-level paging are used by non-EFI boot as well. But they
suffer from the same issue (C code that runs so early that it does not
tolerate ordinary non-PIC codegen with instrumentation etc)

Should we maybe classify this as startup code? And put it in
arch/x86/boot/startup or arch/x86/kernel/startup?

Re: [GIT PULL] EFI updates for v6.15

[Ingo Molnar]

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

> > Look into arch/x86/lib/ and you'll see that EFI functionality 
> > doesn't really fit there.
> 
> Again, EFI is only one aspect of this. The SEV-SNP startup code and 
> the early 5-level paging are used by non-EFI boot as well. But they 
> suffer from the same issue (C code that runs so early that it does 
> not tolerate ordinary non-PIC codegen with instrumentation etc)
> 
> Should we maybe classify this as startup code? And put it in 
> arch/x86/boot/startup or arch/x86/kernel/startup?

Yeah, so the canonical place for platform startup code is 
arch/x86/platform/, we could certainly open up arch/x86/platform/efi/ 
there too, in addition to arch/x86/boot/efi/.

Not that it's enforced consistently or historically: in principle we 
ought to have an arch/x86/platform/pc/ directory and move a lot of 
arch/x86/kernel/ there.

Plus the line is a bit fuzzy: as the system is brought up, exactly 
where is the line between boot loading and platform setup: everything 
up to the start_kernel() call is boot code? I don't think that's 
strictly true: for example x86_early_init_platform_quirks() is called 
before start_kernel(), and it's clearly platform setup code.

But in general, platform specific startup and runtime code's best home 
is arch/x86/platform/.

Thanks,

	Ingo

Re: [GIT PULL] EFI updates for v6.15

[Ard Biesheuvel]

On Tue, 1 Apr 2025 at 11:32, Ingo Molnar <mingo@kernel.org> wrote:
>
>
> * Ard Biesheuvel <ardb@kernel.org> wrote:
>
> > > Look into arch/x86/lib/ and you'll see that EFI functionality
> > > doesn't really fit there.
> >
> > Again, EFI is only one aspect of this. The SEV-SNP startup code and
> > the early 5-level paging are used by non-EFI boot as well. But they
> > suffer from the same issue (C code that runs so early that it does
> > not tolerate ordinary non-PIC codegen with instrumentation etc)
> >
> > Should we maybe classify this as startup code? And put it in
> > arch/x86/boot/startup or arch/x86/kernel/startup?
>
> Yeah, so the canonical place for platform startup code is
> arch/x86/platform/, we could certainly open up arch/x86/platform/efi/
> there too, in addition to arch/x86/boot/efi/.
>

But what about code that has nothing to do with EFI? That is what I am
asking about.

I don't have a strong preference for any of these locations, as long
as they are suitable for *all* startup code, not just code that is
conceptually part of EFI boot.

Re: [GIT PULL] EFI updates for v6.15

[Ingo Molnar]

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

> On Tue, 1 Apr 2025 at 11:32, Ingo Molnar <mingo@kernel.org> wrote:
> >
> >
> > * Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > > > Look into arch/x86/lib/ and you'll see that EFI functionality
> > > > doesn't really fit there.
> > >
> > > Again, EFI is only one aspect of this. The SEV-SNP startup code and
> > > the early 5-level paging are used by non-EFI boot as well. But they
> > > suffer from the same issue (C code that runs so early that it does
> > > not tolerate ordinary non-PIC codegen with instrumentation etc)
> > >
> > > Should we maybe classify this as startup code? And put it in
> > > arch/x86/boot/startup or arch/x86/kernel/startup?
> >
> > Yeah, so the canonical place for platform startup code is
> > arch/x86/platform/, we could certainly open up arch/x86/platform/efi/
> > there too, in addition to arch/x86/boot/efi/.
> >
> 
> But what about code that has nothing to do with EFI? That is what I 
> am asking about.

Would arch/x86/boot/startup/ or arch/x86/boot/init/ work? We can open 
up an efi/ subdirectory within it. (but flat would be fine too.)

It would be an improvement to concentrate such code into a single 
place, I think.

Thanks,

	Ingo

Re: [GIT PULL] EFI updates for v6.15

[Ard Biesheuvel]

On Tue, 1 Apr 2025 at 12:08, Ingo Molnar <mingo@kernel.org> wrote:
>
>
> * Ard Biesheuvel <ardb@kernel.org> wrote:
>
> > On Tue, 1 Apr 2025 at 11:32, Ingo Molnar <mingo@kernel.org> wrote:
> > >
> > >
> > > * Ard Biesheuvel <ardb@kernel.org> wrote:
> > >
> > > > > Look into arch/x86/lib/ and you'll see that EFI functionality
> > > > > doesn't really fit there.
> > > >
> > > > Again, EFI is only one aspect of this. The SEV-SNP startup code and
> > > > the early 5-level paging are used by non-EFI boot as well. But they
> > > > suffer from the same issue (C code that runs so early that it does
> > > > not tolerate ordinary non-PIC codegen with instrumentation etc)
> > > >
> > > > Should we maybe classify this as startup code? And put it in
> > > > arch/x86/boot/startup or arch/x86/kernel/startup?
> > >
> > > Yeah, so the canonical place for platform startup code is
> > > arch/x86/platform/, we could certainly open up arch/x86/platform/efi/
> > > there too, in addition to arch/x86/boot/efi/.
> > >
> >
> > But what about code that has nothing to do with EFI? That is what I
> > am asking about.
>
> Would arch/x86/boot/startup/ or arch/x86/boot/init/ work? We can open
> up an efi/ subdirectory within it. (but flat would be fine too.)
>
> It would be an improvement to concentrate such code into a single
> place, I think.
>

Yeah, that would help a lot.

I'll go with arch/x86/boot/startup/ for now.