<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/firmware/efi/libstub/Makefile, branch linux-6.9.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.9.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.9.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2024-02-22T23:38:51Z</updated>
<entry>
<title>treewide: update LLVM Bugzilla links</title>
<updated>2024-02-22T23:38:51Z</updated>
<author>
<name>Nathan Chancellor</name>
<email>nathan@kernel.org</email>
</author>
<published>2024-01-09T22:16:31Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2947a4567f3a79127d2d540384e7f042106c1a24'/>
<id>urn:sha1:2947a4567f3a79127d2d540384e7f042106c1a24</id>
<content type='text'>
LLVM moved their issue tracker from their own Bugzilla instance to GitHub
issues.  While all of the links are still valid, they may not necessarily
show the most up to date information around the issues, as all updates
will occur on GitHub, not Bugzilla.

Another complication is that the Bugzilla issue number is not always the
same as the GitHub issue number.  Thankfully, LLVM maintains this mapping
through two shortlinks:

  https://llvm.org/bz&lt;num&gt; -&gt; https://bugs.llvm.org/show_bug.cgi?id=&lt;num&gt;
  https://llvm.org/pr&lt;num&gt; -&gt; https://github.com/llvm/llvm-project/issues/&lt;mapped_num&gt;

Switch all "https://bugs.llvm.org/show_bug.cgi?id=&lt;num&gt;" links to the
"https://llvm.org/pr&lt;num&gt;" shortlink so that the links show the most up to
date information.  Each migrated issue links back to the Bugzilla entry,
so there should be no loss of fidelity of information here.

Link: https://lkml.kernel.org/r/20240109-update-llvm-links-v1-3-eb09b59db071@kernel.org
Signed-off-by: Nathan Chancellor &lt;nathan@kernel.org&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Acked-by: Fangrui Song &lt;maskray@google.com&gt;
Cc: Alexei Starovoitov &lt;ast@kernel.org&gt;
Cc: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Cc: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Cc: Mykola Lysenko &lt;mykolal@fb.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>riscv/efistub: Tighten ELF relocation check</title>
<updated>2024-01-23T13:31:33Z</updated>
<author>
<name>Ard Biesheuvel</name>
<email>ardb@kernel.org</email>
</author>
<published>2024-01-16T13:52:27Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d2baf8cc82c17459fca019a12348efcf86bfec29'/>
<id>urn:sha1:d2baf8cc82c17459fca019a12348efcf86bfec29</id>
<content type='text'>
The EFI stub makefile contains logic to ensure that the objects that
make up the stub do not contain relocations that require runtime fixups
(typically to account for the runtime load address of the executable)

On RISC-V, we also avoid GP based relocations, as they require that GP
is assigned the correct base in the startup code, which is not
implemented in the EFI stub.

So add these relocation types to the grep expression that is used to
carry out this check.

Link: https://lkml.kernel.org/r/42c63cb9-87d0-49db-9af8-95771b186684%40siemens.com
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
<entry>
<title>riscv/efistub: Ensure GP-relative addressing is not used</title>
<updated>2024-01-23T13:31:32Z</updated>
<author>
<name>Jan Kiszka</name>
<email>jan.kiszka@siemens.com</email>
</author>
<published>2024-01-12T18:37:29Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=afb2a4fb84555ef9e61061f6ea63ed7087b295d5'/>
<id>urn:sha1:afb2a4fb84555ef9e61061f6ea63ed7087b295d5</id>
<content type='text'>
The cflags for the RISC-V efistub were missing -mno-relax, thus were
under the risk that the compiler could use GP-relative addressing. That
happened for _edata with binutils-2.41 and kernel 6.1, causing the
relocation to fail due to an invalid kernel_size in handle_kernel_image.
It was not yet observed with newer versions, but that may just be luck.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Jan Kiszka &lt;jan.kiszka@siemens.com&gt;
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'riscv-for-linus-6.7-mw2' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux</title>
<updated>2023-11-10T17:23:17Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-11-10T17:23:17Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=56d428ae1c4e27fbe02cb554b2192cd66e4df05a'/>
<id>urn:sha1:56d428ae1c4e27fbe02cb554b2192cd66e4df05a</id>
<content type='text'>
Pull more RISC-V updates from Palmer Dabbelt:

 - Support for handling misaligned accesses in S-mode

 - Probing for misaligned access support is now properly cached and
   handled in parallel

 - PTDUMP now reflects the SW reserved bits, as well as the PBMT and
   NAPOT extensions

 - Performance improvements for TLB flushing

 - Support for many new relocations in the module loader

 - Various bug fixes and cleanups

* tag 'riscv-for-linus-6.7-mw2' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: (51 commits)
  riscv: Optimize bitops with Zbb extension
  riscv: Rearrange hwcap.h and cpufeature.h
  drivers: perf: Do not broadcast to other cpus when starting a counter
  drivers: perf: Check find_first_bit() return value
  of: property: Add fw_devlink support for msi-parent
  RISC-V: Don't fail in riscv_of_parent_hartid() for disabled HARTs
  riscv: Fix set_memory_XX() and set_direct_map_XX() by splitting huge linear mappings
  riscv: Don't use PGD entries for the linear mapping
  RISC-V: Probe misaligned access speed in parallel
  RISC-V: Remove __init on unaligned_emulation_finish()
  RISC-V: Show accurate per-hart isa in /proc/cpuinfo
  RISC-V: Don't rely on positional structure initialization
  riscv: Add tests for riscv module loading
  riscv: Add remaining module relocations
  riscv: Avoid unaligned access when relocating modules
  riscv: split cache ops out of dma-noncoherent.c
  riscv: Improve flush_tlb_kernel_range()
  riscv: Make __flush_tlb_range() loop over pte instead of flushing the whole tlb
  riscv: Improve flush_tlb_range() for hugetlb pages
  riscv: Improve tlb_flush()
  ...
</content>
</entry>
<entry>
<title>riscv: Optimize bitops with Zbb extension</title>
<updated>2023-11-09T18:15:52Z</updated>
<author>
<name>Xiao Wang</name>
<email>xiao.w.wang@intel.com</email>
</author>
<published>2023-10-31T06:45:53Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=457926b253200bd9bdfae9a016a3b1d1dc661d55'/>
<id>urn:sha1:457926b253200bd9bdfae9a016a3b1d1dc661d55</id>
<content type='text'>
This patch leverages the alternative mechanism to dynamically optimize
bitops (including __ffs, __fls, ffs, fls) with Zbb instructions. When
Zbb ext is not supported by the runtime CPU, legacy implementation is
used. If Zbb is supported, then the optimized variants will be selected
via alternative patching.

The legacy bitops support is taken from the generic C implementation as
fallback.

If the parameter is a build-time constant, we leverage compiler builtin to
calculate the result directly, this approach is inspired by x86 bitops
implementation.

EFI stub runs before the kernel, so alternative mechanism should not be
used there, this patch introduces a macro NO_ALTERNATIVE for this purpose.

Signed-off-by: Xiao Wang &lt;xiao.w.wang@intel.com&gt;
Reviewed-by: Charlie Jenkins &lt;charlie@rivosinc.com&gt;
Link: https://lore.kernel.org/r/20231031064553.2319688-3-xiao.w.wang@intel.com
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</content>
</entry>
<entry>
<title>x86/efi: Drop EFI stub .bss from .data section</title>
<updated>2023-09-15T09:18:40Z</updated>
<author>
<name>Ard Biesheuvel</name>
<email>ardb@kernel.org</email>
</author>
<published>2023-09-12T09:00:52Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=5f51c5d0e905608ba7be126737f7c84a793ae1aa'/>
<id>urn:sha1:5f51c5d0e905608ba7be126737f7c84a793ae1aa</id>
<content type='text'>
Now that the EFI stub always zero inits its BSS section upon entry,
there is no longer a need to place the BSS symbols carried by the stub
into the .data section.

Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Link: https://lore.kernel.org/r/20230912090051.4014114-18-ardb@google.com
</content>
</entry>
<entry>
<title>Merge patch series "riscv: Introduce KASLR"</title>
<updated>2023-09-08T18:25:13Z</updated>
<author>
<name>Palmer Dabbelt</name>
<email>palmer@rivosinc.com</email>
</author>
<published>2023-09-08T18:25:13Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f57805555834494e8cad729d01d86ba326d64959'/>
<id>urn:sha1:f57805555834494e8cad729d01d86ba326d64959</id>
<content type='text'>
Alexandre Ghiti &lt;alexghiti@rivosinc.com&gt; says:

The following KASLR implementation allows to randomize the kernel mapping:

- virtually: we expect the bootloader to provide a seed in the device-tree
- physically: only implemented in the EFI stub, it relies on the firmware to
  provide a seed using EFI_RNG_PROTOCOL. arm64 has a similar implementation
  hence the patch 3 factorizes KASLR related functions for riscv to take
  advantage.

The new virtual kernel location is limited by the early page table that only
has one PUD and with the PMD alignment constraint, the kernel can only take
&lt; 512 positions.

* b4-shazam-merge:
  riscv: libstub: Implement KASLR by using generic functions
  libstub: Fix compilation warning for rv32
  arm64: libstub: Move KASLR handling functions to kaslr.c
  riscv: Dump out kernel offset information on panic
  riscv: Introduce virtual kernel mapping KASLR

Link: https://lore.kernel.org/r/20230722123850.634544-1-alexghiti@rivosinc.com
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</content>
</entry>
<entry>
<title>riscv: libstub: Implement KASLR by using generic functions</title>
<updated>2023-09-06T02:49:31Z</updated>
<author>
<name>Alexandre Ghiti</name>
<email>alexghiti@rivosinc.com</email>
</author>
<published>2023-07-22T12:38:50Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b7ac4b8ee73d4fec0998664c9dd61f089d481044'/>
<id>urn:sha1:b7ac4b8ee73d4fec0998664c9dd61f089d481044</id>
<content type='text'>
We can now use arm64 functions to handle the move of the kernel physical
mapping: if KASLR is enabled, we will try to get a random seed from the
firmware, if not possible, the kernel will be moved to a location that
suits its alignment constraints.

Signed-off-by: Alexandre Ghiti &lt;alexghiti@rivosinc.com&gt;
Tested-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
Tested-by: Song Shuai &lt;songshuaishuai@tinylab.org&gt;
Reviewed-by: Sami Tolvanen &lt;samitolvanen@google.com&gt;
Tested-by: Sami Tolvanen &lt;samitolvanen@google.com&gt;
Link: https://lore.kernel.org/r/20230722123850.634544-6-alexghiti@rivosinc.com
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</content>
</entry>
<entry>
<title>arm64: libstub: Move KASLR handling functions to kaslr.c</title>
<updated>2023-09-06T02:49:29Z</updated>
<author>
<name>Alexandre Ghiti</name>
<email>alexghiti@rivosinc.com</email>
</author>
<published>2023-07-22T12:38:48Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=6b56beb5f6940f0b77cb520263651328a8378efa'/>
<id>urn:sha1:6b56beb5f6940f0b77cb520263651328a8378efa</id>
<content type='text'>
This prepares for riscv to use the same functions to handle the pĥysical
kernel move when KASLR is enabled.

Signed-off-by: Alexandre Ghiti &lt;alexghiti@rivosinc.com&gt;
Acked-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Tested-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
Tested-by: Song Shuai &lt;songshuaishuai@tinylab.org&gt;
Reviewed-by: Sami Tolvanen &lt;samitolvanen@google.com&gt;
Tested-by: Sami Tolvanen &lt;samitolvanen@google.com&gt;
Link: https://lore.kernel.org/r/20230722123850.634544-4-alexghiti@rivosinc.com
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'efi-next-for-v6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi</title>
<updated>2023-08-28T23:25:45Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-08-28T23:25:45Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d7dd9b449fac8616bafe9afb9c20948797d6a0ad'/>
<id>urn:sha1:d7dd9b449fac8616bafe9afb9c20948797d6a0ad</id>
<content type='text'>
Pull EFI updates from Ard Biesheuvel:
 "This primarily covers some cleanup work on the EFI runtime wrappers,
  which are shared between all EFI architectures except Itanium, and
  which provide some level of isolation to prevent faults occurring in
  the firmware code (which runs at the same privilege level as the
  kernel) from bringing down the system.

  Beyond that, there is a fix that did not make it into v6.5, and some
  doc fixes and dead code cleanup.

   - one bugfix for x86 mixed mode that did not make it into v6.5

   - first pass of cleanup for the EFI runtime wrappers

   - some cosmetic touchups"

* tag 'efi-next-for-v6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi:
  x86/efistub: Fix PCI ROM preservation in mixed mode
  efi/runtime-wrappers: Clean up white space and add __init annotation
  acpi/prmt: Use EFI runtime sandbox to invoke PRM handlers
  efi/runtime-wrappers: Don't duplicate setup/teardown code
  efi/runtime-wrappers: Remove duplicated macro for service returning void
  efi/runtime-wrapper: Move workqueue manipulation out of line
  efi/runtime-wrappers: Use type safe encapsulation of call arguments
  efi/riscv: Move EFI runtime call setup/teardown helpers out of line
  efi/arm64: Move EFI runtime call setup/teardown helpers out of line
  efi/riscv: libstub: Fix comment about absolute relocation
  efi: memmap: Remove kernel-doc warnings
  efi: Remove unused extern declaration efi_lookup_mapped_addr()
</content>
</entry>
</feed>
