<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/firmware/efi/libstub, branch linux-6.15.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.15.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.15.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2025-06-19T13:39:51Z</updated>
<entry>
<title>efi/libstub: Describe missing 'out' parameter in efi_load_initrd</title>
<updated>2025-06-19T13:39:51Z</updated>
<author>
<name>Hans Zhang</name>
</author>
<published>2025-05-06T16:31:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=49993db7103c70d9f4cf5d060431b96fe5011118'/>
<id>urn:sha1:49993db7103c70d9f4cf5d060431b96fe5011118</id>
<content type='text'>
[ Upstream commit c8e1927e7f7d63721e32ec41d27ccb0eb1a1b0fc ]

The function efi_load_initrd() had a documentation warning due to
the missing description for the 'out' parameter. Add the parameter
description to the kernel-doc comment to resolve the warning and
improve API documentation.

Fixes the following compiler warning:
drivers/firmware/efi/libstub/efi-stub-helper.c:611: warning: Function parameter or struct member 'out' not described in 'efi_load_initrd'

Fixes: f4dc7fffa987 ("efi: libstub: unify initrd loading between architectures")
Signed-off-by: Hans Zhang &lt;18255117159@163.com&gt;
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'efi-next-for-v6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi</title>
<updated>2025-03-29T18:36:19Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2025-03-29T18:36:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1fa753c7b5b91c31a8efc80d74acbbfb391a9e7c'/>
<id>urn:sha1:1fa753c7b5b91c31a8efc80d74acbbfb391a9e7c</id>
<content type='text'>
Pull EFI updates from Ard Biesheuvel:

 - 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

* tag 'efi-next-for-v6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi:
  efi/libstub: Avoid legacy decompressor zlib/zstd wrappers
  efi/libstub: Avoid CopyMem/SetMem EFI services after ExitBootServices
  efi: efibc: change kmalloc(size * count, ...) to kmalloc_array()
  efivarfs: Revert "allow creation of zero length files"
  x86/efi/mixed: Move mixed mode startup code into libstub
  x86/efi/mixed: Simplify and document thunking logic
  x86/efi/mixed: Remove dependency on legacy startup_32 code
  x86/efi/mixed: Set up 1:1 mapping of lower 4GiB in the stub
  x86/efi/mixed: Factor out and clean up long mode entry
  x86/efi/mixed: Check CPU compatibility without relying on verify_cpu()
  x86/efistub: Merge PE and handover entrypoints
</content>
</entry>
<entry>
<title>efi/libstub: Avoid legacy decompressor zlib/zstd wrappers</title>
<updated>2025-03-14T11:36:11Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2024-11-20T19:36:03Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0dc1754e16b4c14ae42f6cf59f319331d885f0f6'/>
<id>urn:sha1:0dc1754e16b4c14ae42f6cf59f319331d885f0f6</id>
<content type='text'>
Remove EFI zboot's dependency on the decompression wrappers used by the
legacy decompressor boot code, which can only process the input in one
go, and this will not work for upcoming support for embedded ELF images.
They also do some odd things like providing a barebones malloc()
implementation, which is not needed in a hosted environment such as the
EFI boot services.

So instead, implement GZIP deflate and ZSTD decompression in terms of
the underlying libraries. Support for other compression algoritms has
already been dropped.

Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
<entry>
<title>efi/libstub: Avoid physical address 0x0 when doing random allocation</title>
<updated>2025-03-14T11:21:29Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2025-03-14T11:03:33Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=cb16dfed0093217a68c0faa9394fa5823927e04c'/>
<id>urn:sha1:cb16dfed0093217a68c0faa9394fa5823927e04c</id>
<content type='text'>
Ben reports spurious EFI zboot failures on a system where physical RAM
starts at 0x0. When doing random memory allocation from the EFI stub on
such a platform, a random seed of 0x0 (which means no entropy source is
available) will result in the allocation to be placed at address 0x0 if
sufficient space is available.

When this allocation is subsequently passed on to the decompression
code, the 0x0 address is mistaken for NULL and the code complains and
gives up.

So avoid address 0x0 when doing random allocation, and set the minimum
address to the minimum alignment.

Cc: &lt;stable@vger.kernel.org&gt;
Reported-by: Ben Schneider &lt;ben@bens.haus&gt;
Tested-by: Ben Schneider &lt;ben@bens.haus&gt;
Reviewed-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
<entry>
<title>efi/libstub: Avoid CopyMem/SetMem EFI services after ExitBootServices</title>
<updated>2025-03-13T10:52:05Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2025-02-27T17:35:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=74d613e046e418ed512b265aa2ef8a27a761fb4d'/>
<id>urn:sha1:74d613e046e418ed512b265aa2ef8a27a761fb4d</id>
<content type='text'>
Given that memset/memcpy are intrinsics, the compiler might insert calls
to these routines unexpectedly, including in code that executes after
ExitBootServices(). In this case, the respective boot services are no
longer accessible, and calling them will cause a crash.

So fall back to a bytewise copy/store if this happens to occur, even
though no such occurrences are known to exist in the kernel currently.

Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'x86-mixed-mode' into efi/next</title>
<updated>2025-03-07T11:30:53Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2025-03-07T11:29:59Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=48140f8bcab451eefda3b55460ba1c918fb34983'/>
<id>urn:sha1:48140f8bcab451eefda3b55460ba1c918fb34983</id>
<content type='text'>
</content>
</entry>
<entry>
<title>x86/efi/mixed: Move mixed mode startup code into libstub</title>
<updated>2025-02-21T15:54:39Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2025-01-07T17:16:59Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=fb84cefd4ce77c3d63cd3d23adaa7faaef3737cc'/>
<id>urn:sha1:fb84cefd4ce77c3d63cd3d23adaa7faaef3737cc</id>
<content type='text'>
The EFI mixed mode code has been decoupled from the legacy decompressor,
in order to be able to reuse it with generic EFI zboot images for x86.

Move the source file into the libstub source directory to facilitate
this.

Acked-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
<entry>
<title>x86/efistub: Merge PE and handover entrypoints</title>
<updated>2025-02-21T15:54:05Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2025-01-26T07:46:30Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=dac628e9563640e2de7878decc03a508b1ba319a'/>
<id>urn:sha1:dac628e9563640e2de7878decc03a508b1ba319a</id>
<content type='text'>
The difference between the PE and handover entrypoints in the EFI stub
is that the former allocates a struct boot_params whereas the latter
expects one from the caller. Currently, these are two completely
separate entrypoints, duplicating some logic and both relying of
efi_exit() to return straight back to the firmware on an error.

Simplify this by making the PE entrypoint call the handover entrypoint
with NULL as the argument for the struct boot_params parameter. This
makes the code easier to follow, and removes the need to support two
different calling conventions in the mixed mode asm code.

While at it, move the assignment of boot_params_ptr into the function
that actually calls into the legacy decompressor, which is where its
value is required.

Acked-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
<entry>
<title>efi: Avoid cold plugged memory for placing the kernel</title>
<updated>2025-02-04T13:08:22Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2025-02-01T17:21:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ba69e0750b0362870294adab09339a0c39c3beaf'/>
<id>urn:sha1:ba69e0750b0362870294adab09339a0c39c3beaf</id>
<content type='text'>
UEFI 2.11 introduced EFI_MEMORY_HOT_PLUGGABLE to annotate system memory
regions that are 'cold plugged' at boot, i.e., hot pluggable memory that
is available from early boot, and described as system RAM by the
firmware.

Existing loaders and EFI applications running in the boot context will
happily use this memory for allocating data structures that cannot be
freed or moved at runtime, and this prevents the memory from being
unplugged. Going forward, the new EFI_MEMORY_HOT_PLUGGABLE attribute
should be tested, and memory annotated as such should be avoided for
such allocations.

In the EFI stub, there are a couple of occurrences where, instead of the
high-level AllocatePages() UEFI boot service, a low-level code sequence
is used that traverses the EFI memory map and carves out the requested
number of pages from a free region. This is needed, e.g., for allocating
as low as possible, or for allocating pages at random.

While AllocatePages() should presumably avoid special purpose memory and
cold plugged regions, this manual approach needs to incorporate this
logic itself, in order to prevent the kernel itself from ending up in a
hot unpluggable region, preventing it from being unplugged.

So add the EFI_MEMORY_HOTPLUGGABLE macro definition, and check for it
where appropriate.

Cc: stable@vger.kernel.org
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
<entry>
<title>efi: libstub: Use '-std=gnu11' to fix build with GCC 15</title>
<updated>2025-01-22T11:57:45Z</updated>
<author>
<name>Nathan Chancellor</name>
</author>
<published>2025-01-22T01:11:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8ba14d9f490aef9fd535c04e9e62e1169eb7a055'/>
<id>urn:sha1:8ba14d9f490aef9fd535c04e9e62e1169eb7a055</id>
<content type='text'>
GCC 15 changed the default C standard version to C23, which should not
have impacted the kernel because it requests the gnu11 standard via
'-std=' in the main Makefile. However, the EFI libstub Makefile uses its
own set of KBUILD_CFLAGS for x86 without a '-std=' value (i.e., using
the default), resulting in errors from the kernel's definitions of bool,
true, and false in stddef.h, which are reserved keywords under C23.

  ./include/linux/stddef.h:11:9: error: expected identifier before ‘false’
     11 |         false   = 0,
  ./include/linux/types.h:35:33: error: two or more data types in declaration specifiers
     35 | typedef _Bool                   bool;

Set '-std=gnu11' in the x86 cflags to resolve the error and consistently
use the same C standard version for the entire kernel. All other
architectures reuse KBUILD_CFLAGS from the rest of the kernel, so this
issue is not visible for them.

Cc: stable@vger.kernel.org
Reported-by: Kostadin Shishmanov &lt;kostadinshishmanov@protonmail.com&gt;
Closes: https://lore.kernel.org/4OAhbllK7x4QJGpZjkYjtBYNLd_2whHx9oFiuZcGwtVR4hIzvduultkgfAIRZI3vQpZylu7Gl929HaYFRGeMEalWCpeMzCIIhLxxRhq4U-Y=@protonmail.com/
Reported-by: Jakub Jelinek &lt;jakub@redhat.com&gt;
Closes: https://lore.kernel.org/Z4467umXR2PZ0M1H@tucnak/
Signed-off-by: Nathan Chancellor &lt;nathan@kernel.org&gt;
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
</feed>
