<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/firmware/efi/libstub, branch linux-6.3.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.3.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.3.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2023-07-11T17:39:51Z</updated>
<entry>
<title>efi/libstub: Disable PCI DMA before grabbing the EFI memory map</title>
<updated>2023-07-11T17:39:51Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2023-06-27T07:33:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1df929db46b8f15dce5adafc2e62f88395fd8755'/>
<id>urn:sha1:1df929db46b8f15dce5adafc2e62f88395fd8755</id>
<content type='text'>
[ Upstream commit 2e28a798c3092ea42b968fa16ac835969d124898 ]

Currently, the EFI stub will disable PCI DMA as the very last thing it
does before calling ExitBootServices(), to avoid interfering with the
firmware's normal operation as much as possible.

However, the stub will invoke DisconnectController() on all endpoints
downstream of the PCI bridges it disables, and this may affect the
layout of the EFI memory map, making it substantially more likely that
ExitBootServices() will fail the first time around, and that the EFI
memory map needs to be reloaded.

This, in turn, increases the likelihood that the slack space we
allocated is insufficient (and we can no longer allocate memory via boot
services after having called ExitBootServices() once), causing the
second call to GetMemoryMap (and therefore the boot) to fail. This makes
the PCI DMA disable feature a bit more fragile than it already is, so
let's make it more robust, by allocating the space for the EFI memory
map after disabling PCI DMA.

Fixes: 4444f8541dad16fe ("efi: Allow disabling PCI busmastering on bridges during boot")
Reported-by: Glenn Washburn &lt;development@efficientek.com&gt;
Acked-by: Matthew Garrett &lt;mjg59@srcf.ucam.org&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>efi/libstub: randomalloc: Return EFI_OUT_OF_RESOURCES on failure</title>
<updated>2023-03-23T14:15:45Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2023-03-07T23:21:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0b1d9debe30304f35c1211e6dcdca1935ce67240'/>
<id>urn:sha1:0b1d9debe30304f35c1211e6dcdca1935ce67240</id>
<content type='text'>
The logic in efi_random_alloc() will iterate over the memory map twice,
once to count the number of candidate slots, and another time to locate
the chosen slot after randomization.

If there is insufficient memory to do the allocation, the second loop
will run to completion without actually having located a slot, but we
currently return EFI_SUCCESS in this case, as we fail to initialize
status to the appropriate error value of EFI_OUT_OF_RESOURCES.

Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
<entry>
<title>efi/libstub: Use relocated version of kernel's struct screen_info</title>
<updated>2023-03-23T11:27:18Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2023-03-22T00:11:18Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=fc3608aaa5751318837e4bbe0282b3836bca5080'/>
<id>urn:sha1:fc3608aaa5751318837e4bbe0282b3836bca5080</id>
<content type='text'>
In some cases, we expose the kernel's struct screen_info to the EFI stub
directly, so it gets populated before even entering the kernel.  This
means the early console is available as soon as the early param parsing
happens, which is nice. It also means we need two different ways to pass
this information, as this trick only works if the EFI stub is baked into
the core kernel image, which is not always the case.

Huacai reports that the preparatory refactoring that was needed to
implement this alternative method for zboot resulted in a non-functional
efifb earlycon for other cases as well, due to the reordering of the
kernel image relocation with the population of the screen_info struct,
and the latter now takes place after copying the image to its new
location, which means we copy the old, uninitialized state.

So let's ensure that the same-image version of alloc_screen_info()
produces the correct screen_info pointer, by taking the displacement of
the loaded image into account.

Reported-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
Tested-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
Link: https://lore.kernel.org/linux-efi/20230310021749.921041-1-chenhuacai@loongson.cn/
Fixes: 42c8ea3dca094ab8 ("efi: libstub: Factor out EFI stub entrypoint into separate file")
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
<entry>
<title>efi/libstub: zboot: Add compressed image to make targets</title>
<updated>2023-03-21T14:20:56Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2023-03-21T14:17:57Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=97fd768e501fd5d377cb0bf46a35bad2cd21c153'/>
<id>urn:sha1:97fd768e501fd5d377cb0bf46a35bad2cd21c153</id>
<content type='text'>
Avoid needlessly rebuilding the compressed image by adding the file
'vmlinuz' to the 'targets' Kbuild make variable.

Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
<entry>
<title>efi/libstub: smbios: Drop unused 'recsize' parameter</title>
<updated>2023-03-18T10:44:57Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2023-02-28T18:33:14Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f59a7ec1e69fc23946175b8c0d7e0fd21f94f8c9'/>
<id>urn:sha1:f59a7ec1e69fc23946175b8c0d7e0fd21f94f8c9</id>
<content type='text'>
We no longer use the recsize argument for locating the string table in
an SMBIOS record, so we can drop it from the internal API.

Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
<entry>
<title>arm64: efi: Use SMBIOS processor version to key off Ampere quirk</title>
<updated>2023-03-18T10:44:56Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2023-02-28T16:00:49Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=eb684408f3ea4856639675d6465f0024e498e4b1'/>
<id>urn:sha1:eb684408f3ea4856639675d6465f0024e498e4b1</id>
<content type='text'>
Instead of using the SMBIOS type 1 record 'family' field, which is often
modified by OEMs, use the type 4 'processor ID' and 'processor version'
fields, which are set to a small set of probe-able values on all known
Ampere EFI systems in the field.

Fixes: 550b33cfd4452968 ("arm64: efi: Force the use of ...")
Tested-by: Andrea Righi &lt;andrea.righi@canonical.com&gt;
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
<entry>
<title>efi/libstub: smbios: Use length member instead of record struct size</title>
<updated>2023-03-18T10:37:56Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2023-02-28T18:23:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=34343eb06afc04af9178a9883d9354dc12beede0'/>
<id>urn:sha1:34343eb06afc04af9178a9883d9354dc12beede0</id>
<content type='text'>
The type 1 SMBIOS record happens to always be the same size, but there
are other record types which have been augmented over time, and so we
should really use the length field in the header to decide where the
string table starts.

Fixes: 550b33cfd4452968 ("arm64: efi: Force the use of ...")
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
<entry>
<title>efi/libstub: arm64: Remap relocated image with strict permissions</title>
<updated>2023-03-10T13:11:39Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2023-03-10T11:55:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3c60f67b4bd1bc01fa9194e9dc925ac6cb56156c'/>
<id>urn:sha1:3c60f67b4bd1bc01fa9194e9dc925ac6cb56156c</id>
<content type='text'>
After relocating the executable image, use the EFI memory attributes
protocol to remap the code and data regions with the appropriate
permissions.

Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
<entry>
<title>efi/libstub: zboot: Mark zboot EFI application as NX compatible</title>
<updated>2023-03-10T13:11:39Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2023-03-10T11:15:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c7d9e628b8ff4d52a365a441bdacb3209ee83c81'/>
<id>urn:sha1:c7d9e628b8ff4d52a365a441bdacb3209ee83c81</id>
<content type='text'>
Now that the zboot loader will invoke the EFI memory attributes protocol
to remap the decompressed code and rodata as read-only/executable, we
can set the PE/COFF header flag that indicates to the firmware that the
application does not rely on writable memory being executable at the
same time.

Cc: &lt;stable@vger.kernel.org&gt; # v6.2+
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'efi-next-for-v6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi</title>
<updated>2023-02-23T22:41:48Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2023-02-23T22:41:48Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=06e1a81c4806d0b7f75f9d742ebf410718244e03'/>
<id>urn:sha1:06e1a81c4806d0b7f75f9d742ebf410718244e03</id>
<content type='text'>
Pull EFI updates from Ard Biesheuvel:
 "A healthy mix of EFI contributions this time:

   - Performance tweaks for efifb earlycon (Andy)

   - Preparatory refactoring and cleanup work in the efivar layer, which
     is needed to accommodate the Snapdragon arm64 laptops that expose
     their EFI variable store via a TEE secure world API (Johan)

   - Enhancements to the EFI memory map handling so that Xen dom0 can
     safely access EFI configuration tables (Demi Marie)

   - Wire up the newly introduced IBT/BTI flag in the EFI memory
     attributes table, so that firmware that is generated with ENDBR/BTI
     landing pads will be mapped with enforcement enabled

   - Clean up how we check and print the EFI revision exposed by the
     firmware

   - Incorporate EFI memory attributes protocol definition and wire it
     up in the EFI zboot code (Evgeniy)

     This ensures that these images can execute under new and stricter
     rules regarding the default memory permissions for EFI page
     allocations (More work is in progress here)

   - CPER header cleanup (Dan Williams)

   - Use a raw spinlock to protect the EFI runtime services stack on
     arm64 to ensure the correct semantics under -rt (Pierre)

   - EFI framebuffer quirk for Lenovo Ideapad (Darrell)"

* tag 'efi-next-for-v6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: (24 commits)
  firmware/efi sysfb_efi: Add quirk for Lenovo IdeaPad Duet 3
  arm64: efi: Make efi_rt_lock a raw_spinlock
  efi: Add mixed-mode thunk recipe for GetMemoryAttributes
  efi: x86: Wire up IBT annotation in memory attributes table
  efi: arm64: Wire up BTI annotation in memory attributes table
  efi: Discover BTI support in runtime services regions
  efi/cper, cxl: Remove cxl_err.h
  efi: Use standard format for printing the EFI revision
  efi: Drop minimum EFI version check at boot
  efi: zboot: Use EFI protocol to remap code/data with the right attributes
  efi/libstub: Add memory attribute protocol definitions
  efi: efivars: prevent double registration
  efi: verify that variable services are supported
  efivarfs: always register filesystem
  efi: efivars: add efivars printk prefix
  efi: Warn if trying to reserve memory under Xen
  efi: Actually enable the ESRT under Xen
  efi: Apply allowlist to EFI configuration tables when running under Xen
  efi: xen: Implement memory descriptor lookup based on hypercall
  efi: memmap: Disregard bogus entries instead of returning them
  ...
</content>
</entry>
</feed>
