[GIT,PULL] EFI updates for v6.15

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

* 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

* 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