Skip to content

grub-get-kernel-settings: Treate kernel-uki-dtbloader as default kernel (fedora-45) - #213

Open
jwrdegoede wants to merge 436 commits into
rhboot:fedora-45from
jwrdegoede:rhbz2463620-f45
Open

grub-get-kernel-settings: Treate kernel-uki-dtbloader as default kernel (fedora-45)#213
jwrdegoede wants to merge 436 commits into
rhboot:fedora-45from
jwrdegoede:rhbz2463620-f45

Conversation

@jwrdegoede

@jwrdegoede jwrdegoede commented May 30, 2026

Copy link
Copy Markdown
Contributor

kernel-uki-dtbloader is a drop-in replacement for kernel-core, it even conflicts with kernel-core since it uses identical filenames under /boot.

Before this patch grub-get-kernel-settings handled kernel-uki-dtbloader as a special kernel variant, causing GRUB_NON_STANDARD_KERNEL=true to get set which leads to /lib/kernel/install.d/20-grub.install setting GRUB_UPDATE_DEFAULT_KERNEL=false which results in skipping the grub2-set-default call later on during kernel-install.

As a result of this users of Fedora 44+ ARM64 live media which uses kernel-uki-dtbloader would still get the old kernel on reboot after installing kernel updates (Bug 2463620 - GRUB environment variable saved_entry not updated when installing UKI kernel on F44 aarch64).

Resolve this by treating kernel-uki-dtbloader as default kernel, just like how kernel-core is handled.

Note on the next rebase of rhboot/grub this may be merged into commit c5baa5c ("Add grub-get-kernel-settings and use it in 10_linux")

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2463620
Fixes: c5baa5c ("Add grub-get-kernel-settings and use it in 10_linux")

I'll also submit a https://src.fedoraproject.org/rpms/grub2/ PR for this with the dist-git bits.

Laszlo Ersek and others added 30 commits February 10, 2025 11:41
Laszlo Ersek @lsandov1
grub_dl_set_mem_attrs(): fix format string
099a502 
The grub_dprintf() call for printing the message

  updating attributes for GOT and trampolines

passes the argument "mod->name", but the format string doesn't accept that
argument.

Print the module name too.

Example output:

> kern/dl.c:736: updating attributes for GOT and trampolines ("video_fb")

Fixes: ad1b904 (nx: set page permissions for loaded modules.)
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Laszlo Ersek @lsandov1
grub_dl_set_mem_attrs(): add self-check for the tramp/GOT sizes
8e0e969 
On aarch64 UEFI, we currently have a crasher:

  grub_dl_load_core()
    grub_dl_load_core_noinit()

      /* independent allocation: must remain writable */
      mod = grub_zalloc();

      /* allocates module image with incorrect tail alignment */
      grub_dl_load_segments()

      /* write-protecting the module image makes "mod" read-only! */
      grub_dl_set_mem_attrs()
        grub_update_mem_attrs()

    grub_dl_init()
      /* page fault, crash */
      mod->next = ...;

- Commit 887f1d8 ("modules: load module sections at page-aligned
  addresses", 2023-02-08) forgot to page-align the allocation of the
  trampolines and GOT areas of grub2 modules, in grub_dl_load_segments().

- Commit ad1b904 ("nx: set page permissions for loaded modules.",
  2023-02-08) calculated a common bounding box for the trampolines and GOT
  areas in grub_dl_set_mem_attrs(), rounded the box size up to a whole
  multiple of EFI page size ("arch_addralign"), and write-protected the
  resultant page range.

Consequently, grub_dl_load_segments() places the module image in memory
such that its tail -- the end of the trampolines and GOT areas -- lands at
the head of a page whose tail in turn contains independent memory
allocations, such as "mod". grub_dl_set_mem_attrs() will then unwittingly
write-protect these other allocations too.

But "mod" must remain writable: we assign "mod->next" in grub_dl_init()
subsequently. Currently we crash there with a page fault / permission
fault.

(The crash is not trivial to hit: the tramp/GOT areas are irrelevant on
x86_64, plus the page protection depends on the UEFI platform firmware
providing EFI_MEMORY_ATTRIBUTE_PROTOCOL. In practice, the crash is
restricted to aarch64 edk2 (ArmVirtQemu) builds containing commit
1c4dfadb4611, "ArmPkg/CpuDxe: Implement EFI memory attributes protocol",
2023-03-16.)

Example log before the patch:

> kern/dl.c:736: updating attributes for GOT and trampolines ("video_fb")
> kern/efi/mm.c:927: set +rx -w on 0x13b88b000-0x13b88bfff before:rwx after:r-x
> kern/dl.c:744: done updating module memory attributes for "video_fb"
> kern/dl.c:639: flushing 0xe4f0 bytes at 0x13b87d000
> kern/arm64/cache.c:42: D$ line size: 64
> kern/arm64/cache.c:43: I$ line size: 64
> kern/dl.c:839: module name: video_fb
> kern/dl.c:840: init function: 0x0
> kern/dl.c:865: Initing module video_fb
>
> Synchronous Exception at 0x000000013B8A76EC
> PC 0x00013B8A76EC
>
>   X0 0x000000013B88B960   X1 0x0000000000000000   X2 0x000000013F93587C   X3 0x0000000000000075
>
>   SP 0x00000000470745C0  ELR 0x000000013B8A76EC  SPSR 0x60000205  FPSR 0x00000000
>  ESR 0x9600004F          FAR 0x000000013B88B9D0
>
>  ESR : EC 0x25  IL 0x1  ISS 0x0000004F
>
> Data abort: Permission fault, third level

Note the following:

- The whole 4K page at 0x1_3B88_B000 is write-protected.

- The "video_fb" module actually lives at [0x1_3B87_D000, 0x1_3B88_B4F0)
  -- left-inclusive, right-exclusive --; that is, in the last page (at
  0x1_3B88_B000), it only occupies the first 0x4F0 bytes.

- The instruction at 0x1_3B8A_76EC faults. Not shown here, but it is a
  store instruction, which writes to the field at offset 0x70 of the
  structure pointed-to by the X0 register. This is the "mod->next"
  assignment from grub_dl_init().

- The faulting address is therefore (X0 + 0x70), i.e., 0x1_3B88_B9D0. This
  is indeed the value held in the FAR register.

- The faulting address 0x1_3B88_B9D0 falls in the above-noted page (at
  0x1_3B88_B000), namely at offset 0x9D0. This is *beyond* the first 0x4F0
  bytes that the very tail of the "video_fb" module occupies at the front
  of that page.

For now, add a self-check that reports this bug (and prevents the crash by
skipping the write protection).

Example log after the patch:

> kern/dl.c:742:BUG: trying to protect pages outside of module allocation
> ("video_fb"): module base 0x13b87d000, size 0xe4f0; tramp/GOT base
> 0x13b88b000, size 0x1000

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Laszlo Ersek @lsandov1
grub_dl_load_segments(): page-align the tramp/GOT areas too
4e76235 
The tramp/GOT write-protection in grub_dl_set_mem_attrs() requires that
the tramp/GOT areas of the module image *not* share a page with any other
memory allocations. Page-align the tramp/GOT areas, while satisfying their
intrinsic alignment requirements too.

Fixes: 887f1d8 (modules: load module sections at page-aligned addresses)
Fixes: ad1b904 (nx: set page permissions for loaded modules.)
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
@nfrayer @lsandov1
emu: Add switch-root to grub-emu
281ca41 
If the kernel running grub emu is the same as the one we want to
boot, it makes sense that we just switch-root instead of kexec
the same kernel again by doing grub2-emu --switch-root

Signed-off-by: Nicolas Frayer <nfrayer@redhat.com>
@marta-lewandowska @lsandov1
util: Enable default kernel for updates
c8481a9 
Several kernel variants can be installed on a system in parallel.
In order to allow the user to choose which kernel will be set to
default after an update, re-enable grub's usage of DEFAULTKERNEL as
set in /etc/sysconfig/kernel

Signed-off-by: Marta Lewandowska <mlewando@redhat.com>
@keng-yu @lsandov1
efi/http: change uint32_t to uintn_t
610a6cd 
Modify UINT32 to UINTN in EFI_HTTP_MESSAGE to
be UEFI 2.9 compliant.

Signed-off-by: Keng-Yu Lin <kengyu@hpe.com>
Signed-off-by: Nicolas Frayer <nfrayer@redhat.com>
@LorbusChris @lsandov1
Add [Install] section to aux systemd units
ff49e0b 
Currently in Fedora, these services are statically enabled by symlinks,
with no other way to disable them than to manually delete those symlinks.
This is problematic in Fedora IoT, where grub-boot-success.timer is
not supposed to be enabled.

This change adds `[Install]` sections to all systemd units that are
currently enabled statically, so that they can be enabled dynamically
via presets or manually instead.
@vathpela @lsandov1
Fix missing #include in ofdisk.c
8d5f8d9 
Recently we started building with -Werror=implicit-function-declaration,
and discovered that ofdisk.c is missing an include to declare
grub_env_get().

This patch adds that #include.

Signed-off-by: Peter Jones <pjones@redhat.com>
@marta-lewandowska @lsandov1
add flag to only search root dev
10de467 
fixes bz#2223437

Signed-off-by: Marta Lewandowska <mlewando@redhat.com>
@vathpela @lsandov1
cryptdisk: fix incorrect sign comparison
790bef5 
grub_util_get_fd_size() returns a signed integer, but we're assigning it
to an unsigned integer and then testing against -1.  That's wrong.

This patch makes the variable a signed integer.

Signed-off-by: Peter Jones <pjones@redhat.com>
@vathpela @lsandov1
grub-install: fix a sign comparison error
d4c59ee 
This is a trivial sign comparison fix.

Signed-off-by: Peter Jones <pjones@redhat.com>
@vathpela @lsandov1
grub-mount: work around bad integer comparison.
d698add 
gcc says:

  util/grub-mount.c: In function ‘fuse_read’:
  util/grub-mount.c:273:11: error: comparison of integer expressions of different signedness: ‘off_t’ {aka ‘long int’} and ‘grub_off_t’ {aka ‘long unsigned int’} [-Werror=sign-compare]
    273 |   if (off > file->size)
        |           ^

This is happening because grub_off_t is unsigned but the system's off_t is
signed.

That's too much work to fix today, so this patch works around it with
tests and typecasting.

Signed-off-by: Peter Jones <pjones@redhat.com>
@vathpela @lsandov1
power: Fix use after free in get_slave_from_dm()
99a90cf 
Signed-off-by: Peter Jones <pjones@redhat.com>
@vathpela @lsandov1
Fix some sign comparison errors
e402916 
Signed-off-by: Peter Jones <pjones@redhat.com>
@vathpela @lsandov1
normal: Fix a discarded const.
eda0d04 
Signed-off-by: Peter Jones <pjones@redhat.com>
@vathpela @lsandov1
at_keyboard: mark grub_keyboard_controller_write unused
b5d1d1b 
It's used sometimes and not others by #ifdef, so mark it unused so the
compiler doesn't complain.

Signed-off-by: Peter Jones <pjones@redhat.com>
@vathpela @lsandov1
Fix another minor sign comparison error.
f8b0176 
Signed-off-by: Peter Jones <pjones@redhat.com>
@osteffenrh @lsandov1
Track explicit module dependencies in Makefile.core.def
d4f6f52 
Add a new keyword, "depends", to the module definition syntax
used in Makefile.core.def. This allows specifying explicit module
dependencies together with the module definition.

Make use of this new keyword in the bli module definition.

Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Oskari Pirhonen <xxc3ncoredxx@gmail.com>
@lsandov1
Revert "mm: Assert that we preserve header vs region alignment"
edaf268 
This reverts commit 1df8fe6.

This is temporal while we find the reason for

In file included from ../../include/grub/mm_private.h:23,
                 from ../../include/grub/relocator_private.h:24,
                 from ../../grub-core/lib/efi/relocator.c:20:
../../include/grub/mm_private.h: In function ‘grub_mm_size_sanity_check’:
../../include/grub/misc.h:36:56: error: duplicate case value
   36 | #define COMPILE_TIME_ASSERT(cond) switch (0) { case 1: case !(cond): ; }
      |                                                        ^~~~
../../include/grub/mm_private.h:105:3: note: in expansion of macro ‘COMPILE_TIME_ASSERT’
  105 |   COMPILE_TIME_ASSERT ((sizeof (struct grub_mm_region) %
      |   ^~~~~~~~~~~~~~~~~~~
../../include/grub/misc.h:36:48: note: previously used here
   36 | #define COMPILE_TIME_ASSERT(cond) switch (0) { case 1: case !(cond): ; }
      |                                                ^~~~
../../include/grub/mm_private.h:105:3: note: in expansion of macro ‘COMPILE_TIME_ASSERT’
  105 |   COMPILE_TIME_ASSERT ((sizeof (struct grub_mm_region) %
      |   ^~~~~~~~~~~~~~~~~~~
../../include/grub/misc.h:36:56: error: duplicate case value
   36 | #define COMPILE_TIME_ASSERT(cond) switch (0) { case 1: case !(cond): ; }
      |                                                        ^~~~
../../include/grub/mm_private.h:112:3: note: in expansion of macro ‘COMPILE_TIME_ASSERT’
  112 |   COMPILE_TIME_ASSERT (sizeof (struct grub_mm_header) == GRUB_MM_ALIGN);
      |   ^~~~~~~~~~~~~~~~~~~
../../include/grub/misc.h:36:48: note: previously used here
   36 | #define COMPILE_TIME_ASSERT(cond) switch (0) { case 1: case !(cond): ; }
      |                                                ^~~~
../../include/grub/mm_private.h:112:3: note: in expansion of macro ‘COMPILE_TIME_ASSERT’
  112 |   COMPILE_TIME_ASSERT (sizeof (struct grub_mm_header) == GRUB_MM_ALIGN);
      |   ^~~~~~~~~~~~~~~~~~~
@vathpela @lsandov1
make: use the _CPU variety of build flags for PROGRAM and LIBRARY
d021f07 
Signed-off-by: Peter Jones <pjones@redhat.com>
@vathpela @lsandov1
Work around extra_deps.lst issue
4de42eb
@lsandov1
include proper attribute for an EFI API call definition
75f176c 
Otherwise we observe the following issue

../../grub-core/net/efi/http.c: In function ‘efihttp_request’:
../../grub-core/net/efi/http.c:233:28: error: passing argument 3 of ‘b->create_event’ from incompatible pointer type [-Wincompatible-pointer-types]
  233 |                            grub_efi_http_request_callback, NULL,
      |                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                            |
      |                            void (*)(void *, void *)
../../grub-core/net/efi/http.c:233:28: note: expected ‘void (__attribute__((ms_abi)) *)(void *, void *)’ but argument is of type ‘void (*)(void *, void *)’
@lsandov1
cast grub_error status parameter
f74361b 
For some reason, the compiler concludes that the status variable is
ultimately a 'long unsigned int' but status is a 'unsigned' (not a
long) so temporally cast it to unsigned otherwise we see the following

../../grub-core/net/efi/http.c: In function ‘efihttp_request’:
../../grub-core/net/efi/http.c:251:39: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 5 has type ‘grub_efi_status_t’ {aka ‘long unsigned int’} [-Wformat=]
  251 |       return grub_error (GRUB_ERR_IO, "Fail to send a request! status=0x%x\n", status);
      |                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  ~~~~~~
      |                                                                                |
      |                                                                                grub_efi_status_t {aka long unsigned int}
@lsandov1
remove unused varible
7adb892 
Otherwise compiler complains with:

../../grub-core/commands/efi/connectefi.c:143:20: error: unused variable ‘j’ [-Werror=unused-variable]
  143 |           unsigned j;
      |                    ^

Signed-off-by: Leo Sandoval <lsandova@redhat.com>
@lsandov1
cast grub_net_bootp_packet pointer
daad817 
Otherwise compiler complains with:

../../grub-core/net/drivers/efi/efinet.c: In function ‘grub_efi_net_config_real’:
../../grub-core/net/drivers/efi/efinet.c:876:28: error: cannot convert to a pointer type
  876 |         dhcp_ack = (struct grub_net_bootp_packet *) pxe_mode->dhcp_ack;
      |                            ^~~~~~~~~~~~~~~~~~~~~
../../grub-core/net/drivers/efi/efinet.c:881:57: error: initialization of ‘struct grub_net_bootp_packet *’ from incompatible pointer type ‘grub_efi_pxe_packet_t *’ [-Wincompatible-pointer-types]
  881 |             struct grub_net_bootp_packet *proxy_offer = &pxe_mode->proxy_offer;
      |                                                         ^

Signed-off-by: Leo Sandoval <lsandova@redhat.com>
@lsandov1
libtasn1: fix string overflow warning
7a1d3d7 
Patched also at the libtasn1 project with commit

    c54e523d9dacdb7eec7f20964df12df9b80f467c
    Author:     Simo Sorce <simo@redhat.com>
    AuthorDate: Tue May 11 14:18:10 2021 -0400
    Commit:     Simo Sorce <simo@redhat.com>
    CommitDate: Tue May 11 14:26:04 2021 -0400

    Parent:     890a8a9 Fix resource leak (node)
    Contained:  master
    Follows:    v4.16.0 (48)
    Precedes:   v4.17.0 (5)

    Fix String overflow warning

    Scanner Output
    --------------
    rror: COMPILER_WARNING (CWE-758): [#def2]
    libtasn1-4.16.0/lib/element.c: scope_hint: In function '_asn1_append_sequence_set'
    libtasn1-4.16.0/lib/element.c:186:7: warning[-Wstringop-overflow=]: '_asn1_ltostr' accessing 22 bytes in a region of size 21
     #  186 |       _asn1_ltostr (n, temp + 1);
     #      |       ^~~~~~~~~~~~~~~~~~~~~~~~~~
    libtasn1-4.16.0/lib/element.c:186:7: note: referencing argument 2 of type 'char *'
    libtasn1-4.16.0/lib/element.c:30: included_from: Included from here.
    libtasn1-4.16.0/lib/parser_aux.h:70:7: note: in a call to function '_asn1_ltostr'
     #   70 | char *_asn1_ltostr (int64_t v, char str[LTOSTR_MAX_SIZE]);
     #      |       ^~~~~~~~~~~~
     #  184|         n++;
     #  185|         temp[0] = '?';
     #  186|->       _asn1_ltostr (n, temp + 1);
     #  187|       }
     #  188|     _asn1_set_name (p2, temp);

Signed-off-by: Leo Sandoval <lsandova@redhat.com>
Matthew Garrett @lsandov1
Add support for Linux EFI stub loading.
7cc4b08 
Also:

commit 71c843745f22f81e16d259e2e19c99bf3c1855c1
Author: Colin Watson <cjwatson@ubuntu.com>
Date:   Tue Oct 23 10:40:49 2012 -0400

Don't allow insmod when secure boot is enabled.

Hi,

Fedora's patch to forbid insmod in UEFI Secure Boot environments is fine
as far as it goes.  However, the insmod command is not the only way that
modules can be loaded.  In particular, the 'normal' command, which
implements the usual GRUB menu and the fully-featured command prompt,
will implicitly load commands not currently loaded into memory.  This
permits trivial Secure Boot violations by writing commands implementing
whatever you want to do and pointing $prefix at the malicious code.

I'm currently test-building this patch (replacing your current
grub-2.00-no-insmod-on-sb.patch), but this should be more correct.  It
moves the check into grub_dl_load_file.
@lsandov1
fix i386_pc on legacycfg module
c37f97e
@rw4s @lsandov1
Add secureboot support on efi chainloader
a510c5a 
Expand the chainloader to be able to verify the image by means of shim
lock protocol. The PE/COFF image is loaded and relocated by the
chainloader instead of calling LoadImage and StartImage UEFI boot
Service as they require positive verification result from keys enrolled
in KEK or DB. The shim will use MOK in addition to firmware enrolled
keys to verify the image.

The chainloader module could be used to load other UEFI bootloaders,
such as xen.efi, and could be signed by any of MOK, KEK or DB.

Based on https://build.opensuse.org/package/view_file/openSUSE:Factory/grub2/grub2-secureboot-chainloader.patch

Signed-off-by: Peter Jones <pjones@redhat.com>

Also:

commit cd7a8984d4fda905877b5bfe466339100156b3bc
Author: Raymund Will <rw@suse.com>
Date:   Fri Apr 10 01:45:02 2015 -0400

Use device part of chainloader target, if present.

Otherwise chainloading is restricted to '$root', which might not even
be readable by EFI!

v1. use grub_file_get_device_name() to get device name

Signed-off-by: Michael Chang <mchang@suse.com>
Signed-off-by: Peter Jones <pjones@redhat.com>

Also:

commit 0872a2310a0eeac4ecfe9e1b49dd2d72ab373039
Author: Peter Jones <pjones@redhat.com>
Date:   Fri Jun 10 14:06:15 2016 -0400

Rework even more of efi chainload so non-sb cases work right.

This ensures that if shim protocol is not loaded, or is loaded but shim
is disabled, we will fall back to a correct load method for the efi
chain loader.

Here's what I tested with this version:

results                             expected    actual
------------------------------------------------------------
sb + enabled + shim + fedora        success     success
sb + enabled + shim + win           success     success
sb + enabled + grub + fedora        fail        fail
sb + enabled + grub + win           fail        fail

sb + mokdisabled + shim + fedora    success     success
sb + mokdisabled + shim + win       success     success
sb + mokdisabled + grub + fedora    fail        fail
sb + mokdisabled + grub + win       fail        fail

sb disabled + shim + fedora         success     success*
sb disabled + shim + win            success     success*
sb disabled + grub + fedora         success     success
sb disabled + grub + win            success     success

nosb + shim + fedora                success     success*
nosb + shim + win                   success     success*
nosb + grub + fedora                success     success
nosb + grub + win                   success     success

* for some reason shim protocol is being installed in these cases, and I
  can't see why, but I think it may be this firmware build returning an
  erroneous value.  But this effectively falls back to the mokdisabled
  behavior, which works correctly, and the presence of the "grub" (i.e.
  no shim) tests effectively tests the desired behavior here.

Resolves: rhbz#1344512

Signed-off-by: Peter Jones <pjones@redhat.com>

Also:

commit ff7b1cb7f69487870211aeb69ff4f54470fbcb58
Author: Laszlo Ersek <lersek@redhat.com>
Date:   Mon Nov 21 15:34:00 2016 +0100

efi/chainloader: fix wrong sanity check in relocate_coff()

In relocate_coff(), the relocation entries are parsed from the original
image (not the section-wise copied image). The original image is
pointed-to by the "orig" pointer. The current check

  (void *)reloc_end < data

compares the addresses of independent memory allocations. "data" is a typo
here, it should be "orig".

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1347291
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Bogdan Costescu <bcostescu@gmail.com>
Tested-by: Juan Orti <j.orti.alcaine@gmail.com>

Also:

commit ab4ba9997ad4832449e54d930fa2aac6a160d0e9
Author: Laszlo Ersek <lersek@redhat.com>
Date:   Wed Nov 23 06:27:09 2016 +0100

efi/chainloader: truncate overlong relocation section

The UEFI Windows 7 boot loader ("EFI/Microsoft/Boot/bootmgfw.efi", SHA1
31b410e029bba87d2068c65a80b88882f9f8ea25) has inconsistent headers.

Compare:

> The Data Directory
> ...
> Entry 5 00000000000d9000 00000574 Base Relocation Directory [.reloc]

Versus:

> Sections:
> Idx Name      Size      VMA               LMA               File off ...
> ...
>  10 .reloc    00000e22  00000000100d9000  00000000100d9000  000a1800 ...

That is, the size reported by the RelocDir entry (0x574) is smaller than
the virtual size of the .reloc section (0xe22).

Quoting the grub2 debug log for the same:

> chainloader.c:595: reloc_dir: 0xd9000 reloc_size: 0x00000574
> chainloader.c:603: reloc_base: 0x7d208000 reloc_base_end: 0x7d208573
> ...
> chainloader.c:620: Section 10 ".reloc" at 0x7d208000..0x7d208e21
> chainloader.c:661:  section is not reloc section?
> chainloader.c:663:  rds: 0x00001000, vs: 00000e22
> chainloader.c:664:  base: 0x7d208000 end: 0x7d208e21
> chainloader.c:666:  reloc_base: 0x7d208000 reloc_base_end: 0x7d208573
> chainloader.c:671:  Section characteristics are 42000040
> chainloader.c:673:  Section virtual size: 00000e22
> chainloader.c:675:  Section raw_data size: 00001000
> chainloader.c:678:  Discarding section

After hexdumping "bootmgfw.efi" and manually walking its relocation blocks
(yes, really), I determined that the (smaller) RelocDir value is correct.
The remaining area that extends up to the .reloc section size (== 0xe22 -
0x574 == 0x8ae bytes) exists as zero padding in the file.

This zero padding shouldn't be passed to relocate_coff() for parsing. In
order to cope with it, split the handling of .reloc sections into the
following branches:

- original case (equal size): original behavior (--> relocation
  attempted),

- overlong .reloc section (longer than reported by RelocDir): truncate the
  section to the RelocDir size for the purposes of relocate_coff(), and
  attempt relocation,

- .reloc section is too short, or other checks fail: original behavior
  (--> relocation not attempted).

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1347291
Signed-off-by: Laszlo Ersek <lersek@redhat.com>

Also:

commit cc06f14
Author: Raymund Will <rw@suse.com>

chainloader: Define machine types for RISC-V

The commit "Add secureboot support on efi chainloader" didn't add machine
types for RISC-V, so this patch adds them.

Note, that grub-core/loader/riscv/linux.c is skipped because Linux is not
supported yet. This patch might need a new revision once that's the case.

Signed-off-by: David Abdurachmanov <david.abdurachmanov@sifive.com>
@vathpela @lsandov1
Make any of the loaders that link in efi mode honor secure boot.
4aefbd2 
And in this case "honor" means "even if somebody does link this in, they
won't register commands if SB is enabled."

Signed-off-by: Peter Jones <pjones@redhat.com>
Darrick J. Wong and others added 29 commits January 22, 2026 11:51
Darrick J. Wong @lsandov1
fs/xfs: Add new superblock features added in Linux 6.12/6.13
f2dde4c 
The Linux port of XFS added a few new features in 2024. The existing
GRUB driver doesn't attempt to read or write any of the new metadata,
so, all three can be added to the incompat allowlist.

On the occasion align XFS_SB_FEAT_INCOMPAT_NREXT64 value.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Hans de Goede @lsandov1
Revert "loader/efi: Fix RISC-V build"
af6e139 
This fully reverts commit ae0fba3.

This will break RISC-V builds, but further reverts in this series
will completely remove the troublesome parse_pe_header() function.

Note the modifed code is not used on x86 (#ifdef !x86).

This is part of a series of reverts to move non x86 vmlinuz loading back
to using EFI boot services load_image + start_image calls.

The current DYI approach breaks booting kernel EFI binaries which have
the stubble stub for automatic DTB loading.

Switching back to EFI boot services load_image + start_image fixes this
and also brings Fedora's grub inline with how upstream grub is loading
and booting kernels on arm64 platforms.

Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Hans de Goede @lsandov1
Revert "efi: Disallow fallback to legacy Linux loader when shim says …
4e2e44c 
…NX is required."

This fully reverts commit b899582.

Note this is actually a no-op since the modified linux_cmd() x86-only code
is not used on x86 at all, instead x86 uses the linux_cmd() function
from grub-core/loader/i386/efi/linux.c .

This is part of a series of reverts to move non x86 vmlinuz loading back
to using EFI boot services load_image + start_image calls.

The current DYI approach breaks booting kernel EFI binaries which have
the stubble stub for automatic DTB loading.

Switching back to EFI boot services load_image + start_image fixes this
and also brings Fedora's grub inline with how upstream grub is loading
and booting kernels on arm64 platforms.

Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Hans de Goede @lsandov1
Partial revert: "nx: set attrs in our kernel loaders"
94717f0 
This reverts a small part of commit be61be0.

The only reverted bits are the changes to grub_cmd_linux() these changes
call grub_efi_check_nx_image_support() and store the result into a local
variable, which is then never used. So reverting these changes is a no-op
as the removed code only reads a flag which is never used.

Also note that this version of grub_cmd_linux() is never used on x86,
which uses linux_cmd() from grub-core/loader/i386/efi/linux.c .

This is part of a series of reverts to move non x86 vmlinuz loading back
to using EFI boot services load_image + start_image calls.

This partial revert is done to make further reverts in this series cleaner.

The current DYI approach breaks booting kernel EFI binaries which have
the stubble stub for automatic DTB loading.

Switching back to EFI boot services load_image + start_image fixes this
and also brings Fedora's grub inline with how upstream grub is loading
and booting kernels on arm64 platforms.

Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Hans de Goede @lsandov1
Revert "loader/efi/linux.c: read the kernel image before header"
22152ed 
This fully reverts commit 9728e07.

Note that the modifed version of grub_cmd_linux() is never used on x86,
which uses linux_cmd() from grub-core/loader/i386/efi/linux.c .

This is part of a series of reverts to move non x86 vmlinuz loading back
to using EFI boot services load_image + start_image calls.

The current DYI approach breaks booting kernel EFI binaries which have
the stubble stub for automatic DTB loading.

Switching back to EFI boot services load_image + start_image fixes this
and also brings Fedora's grub inline with how upstream grub is loading
and booting kernels on arm64 platforms.

Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Hans de Goede @lsandov1
Revert "arm64: Use proper memory type for kernel allocation"
897111b 
This fully reverts commit ba84a3e.

Note the modifed code is not used on x86 (#ifdef !x86).

This is part of a series of reverts to move non x86 vmlinuz loading back
to using EFI boot services load_image + start_image calls.

The current DYI approach breaks booting kernel EFI binaries which have
the stubble stub for automatic DTB loading.

Switching back to EFI boot services load_image + start_image fixes this
and also brings Fedora's grub inline with how upstream grub is loading
and booting kernels on arm64 platforms.

Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Hans de Goede @lsandov1
Revert "Correct BSS zeroing on aarch64"
0798b0b 
This fully reverts commit 81dbbbc.

Note the modifed code is not used on x86 (#ifdef !x86).

This is part of a series of reverts to move non x86 vmlinuz loading back
to using EFI boot services load_image + start_image calls.

The current DYI approach breaks booting kernel EFI binaries which have
the stubble stub for automatic DTB loading.

Switching back to EFI boot services load_image + start_image fixes this
and also brings Fedora's grub inline with how upstream grub is loading
and booting kernels on arm64 platforms.

Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Hans de Goede @lsandov1
Revert "arm64: Fix EFI loader kernel image allocation"
2de54b1 
This fully reverts commit 3cfd4a1.

Note the modifed code is not used on x86 (#ifdef !x86).

This is part of a series of reverts to move non x86 vmlinuz loading back
to using EFI boot services load_image + start_image calls.

The current DYI approach breaks booting kernel EFI binaries which have
the stubble stub for automatic DTB loading.

Switching back to EFI boot services load_image + start_image fixes this
and also brings Fedora's grub inline with how upstream grub is loading
and booting kernels on arm64 platforms.

Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Hans de Goede @lsandov1
Revert "Add support for Linux EFI stub loading on arm architectures"
5e86b3c 
This fully reverts commit fa8f199.

Note that the modifed version of grub_cmd_linux() is never used on x86,
which uses linux_cmd() from grub-core/loader/i386/efi/linux.c .

This concludes the series of reverts to move non x86 vmlinuz loading back
to using EFI boot services load_image + start_image calls.

The current DYI approach breaks booting kernel EFI binaries which have
the stubble stub for automatic DTB loading.

Switching back to EFI boot services load_image + start_image fixes this
and also brings Fedora's grub inline with how upstream grub is loading
and booting kernels on arm64 platforms.

This also fixes 2 issues with the xen_hypervisor and xen_module commands:

1) With the now reverted move of setting loaded_image->load_options in
finalize_params() the commandline would no longer be set for the xen case.

2) The handover_offset variable passed by grub_efi_linux_boot is a global
variable set by the linux cmd and this would either be 0 or the value
from the last run linux cmd, neither of which is likely correct for
the xen case.

Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Hans de Goede @lsandov1
loader/efi/linux.c: Free mempath after use
0ca4056 
Fix grub_arch_efi_linux_boot_image () leaking the memory allocated for
mempath by freeing it after use.

Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Hans de Goede @lsandov1
loader/efi/linux.c: Unload image on errors
9f08e40 
Fix grub_arch_efi_linux_boot_image () not unloading the loaded image when
allocating memory for the commandline fails.

Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Hans de Goede @lsandov1
loader/efi/linux.c: Disable code not used on x86 when building for x86
5e9e7e4 
When building grub for x86_64-efi or i386-efi then loader/i386/efi/linux.c
already registers "linux" and "initrd" commands and those will be used
instead of those defined in the generic loader/efi/linux.c code.

Disable (#ifdef out) the unused code in loader/efi/linux.c when building
for x86. This also avoids registering the linux and initrd commands twice.

Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
@miray-tf @lsandov1
commands/test: Fix error in recursion depth calculation
67765ac 
The commit c68b7d2 (commands/test: Stack overflow due to unlimited
recursion depth) added recursion depth tests to the test command. But in
the error case it decrements the pointer to the depth value instead of
the value itself. Fix it.

Fixes: c68b7d2 (commands/test: Stack overflow due to unlimited recursion depth)

Signed-off-by: Thomas Frauendorfer | Miray Software <tf@miray.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
@miray-tf @lsandov1
kern/file: Call grub_dl_unref() after fs->fs_close()
449b9c7 
With commit 16f1968 (kern/file: Implement filesystem reference
counting) files hold a reference to their file systems.

When closing a file in grub_file_close() we should not expect
file->fs to stay valid after calling grub_dl_unref() on file->fs->mod.
So, grub_dl_unref() should be called after file->fs->fs_close().

Fixes: CVE-2025-54771
Fixes: 16f1968 (kern/file: Implement filesystem reference counting)

Reported-by: Thomas Frauendorfer | Miray Software <tf@miray.de>
Signed-off-by: Thomas Frauendorfer | Miray Software <tf@miray.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
@miray-tf @lsandov1
net/net: Unregister net_set_vlan command on unload
2c0b908 
The commit 954c48b (net/net: Add net_set_vlan command) added command
net_set_vlan to the net module. Unfortunately the commit only added the
grub_register_command() call on module load but missed the
grub_unregister_command() on unload. Let's fix this.

Fixes: CVE-2025-54770
Fixes: 954c48b (net/net: Add net_set_vlan command)

Reported-by: Thomas Frauendorfer | Miray Software <tf@miray.de>
Signed-off-by: Thomas Frauendorfer | Miray Software <tf@miray.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
@alecrbrown @lsandov1
gettext/gettext: Unregister gettext command on module unload
968eac9 
When the gettext module is loaded, the gettext command is registered but
isn't unregistered when the module is unloaded. We need to add a call to
grub_unregister_command() when unloading the module.

Fixes: CVE-2025-61662

Reported-by: Alec Brown <alec.r.brown@oracle.com>
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
@alecrbrown @lsandov1
normal/main: Unregister commands on module unload
e5103b5 
When the normal module is loaded, the normal and normal_exit commands
are registered but aren't unregistered when the module is unloaded. We
need to add calls to grub_unregister_command() when unloading the module
for these commands.

Fixes: CVE-2025-61663
Fixes: CVE-2025-61664

Reported-by: Alec Brown <alec.r.brown@oracle.com>
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
@alecrbrown @lsandov1
tests/lib/functional_test: Unregister commands on module unload
0b0b9ef 
When the functional_test module is loaded, both the functional_test and
all_functional_test commands are registered but only the all_functional_test
command is being unregistered since it was the last to set the cmd variable
that gets unregistered when the module is unloaded. To unregister both
commands, we need to create an additional grub_extcmd_t variable.

Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
@volticks @lsandov1
commands/usbtest: Use correct string length field
19640fe 
An incorrect length field is used for buffer allocation. This leads to
grub_utf16_to_utf8() receiving an incorrect/different length and possibly
causing OOB write. This makes sure to use the correct length.

Fixes: CVE-2025-61661

Reported-by: Jamie <volticks@gmail.com>
Signed-off-by: Jamie <volticks@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
@volticks @lsandov1
commands/usbtest: Ensure string length is sufficient in usb string pr…
fd2a33b 
…ocessing

If descstrp->length is less than 2 this will result in underflow in
"descstrp->length / 2 - 1" math. Let's fix the check to make sure the
value is sufficient.

Signed-off-by: Jamie <volticks@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
@lsandov1
verifiers: Allocate EFI pages instead of grub_malloc for verified buffer
f3330b6 
This way we are not restricted to the grub_malloc limit
GRUB_EFI_MAX_ALLOCATION_ADDRESS (0x7fffffff) and instead use the
broader limit GRUB_EFI_MAX_USABLE_ADDRESS (__UINTPTR_MAX__). The
reason behind this change is that initrd files keep growing and the
TPM verifier requires the whole file so it can be measured but
allocating through grub_malloc may lead to out-of-memory issues on
those systems with memory contrains e.g. ASUS, thus use direct EFI
page allocation instead.

Signed-off-by: Leo Sandoval <lsandova@redhat.com>
@lsandov1
term/serial.c: default efi0 as 'serial' port if present
c5594a6 
Currently the port 'com0' is the default which ultimately is register
as the 'serial' port. The following change follows the same logic but
prioritizes the 'efi0' before 'com0', effectively becoming the
'serial' port in case the former is present.

Signed-off-by: Leo Sandoval <lsandova@redhat.com>
@lsandov1
commands/tpm.c: include PCR check/enable/disable functions
cd63b2d 
Signed-off-by: Leo Sandoval <lsandova@redhat.com>
@lsandov1
commands/efi/tpm.c: check if PCR is enable before TPM measure
12f4c9c 
Signed-off-by: Leo Sandoval <lsandova@redhat.com>
@lsandov1
tpm.c: disable PCR8 measurements at the configuration step
03f08fe 
At the configuration step, we can disable PCR8 measurements through
the configure parameter `--with-pcr8-disabled=yes`.

Signed-off-by: Leo Sandoval <lsandova@redhat.com>
@marta-lewandowska @lsandov1
Add support for the efi keyword
b80270f 
Add support for UKIs using the efi keyword in BLS snippets.

Signed-off-by: Marta Lewandowska <mlewando@redhat.com>
@lsandov1
tpm: Disable any GRUB_STRING_PCR command measurement
e9a6459 
Currently when configure with the parameter `--with-pcr8-disabled`,
PCR8 (GRUB_STRING_PCR) is disabled at the `grub_tmp_verify_init`
function, but on images with embedded configurations, (embedded)
commands are being measured through the `grub_tpm_verify_string`
function which is called before the init one, thus PCR8 measurements
are still observed. The proposed change, disables PCR8 measurements at
the verify string function, effectively disabling any PCR8 measurement
during boot.

Signed-off-by: Leo Sandoval <lsandova@redhat.com>
@WenhuaChang @lsandov1
util/grub-editenv: remove stale env_block on unsupported filesystem
6d481bd 
The env_block variable is only valid when grub-editenv has filesystem
backed environment block support for the default grubenv location. If a
grubenv file is copied from such a setup to an unsupported filesystem or
non default path, the stale env_block entry may remain behind.

When updating the environment block in set_variables() and
unset_variables(), remove env_block if filesystem backed support is not
available. This keeps the file contents consistent with the current
grubenv location and avoids carrying stale env_block into unsupported
cases.

Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Leo Sandoval <lsandova@redhat.com>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Part-of: <https://gitlab.freedesktop.org/gnu-grub/grub/-/merge_requests/106>
Hans de Goede
grub-get-kernel-settings: Treate kernel-uki-dtbloader as default kernel
0b8c845 
kernel-uki-dtbloader is a drop-in replacement for kernel-core, it even
conflicts with kernel-core since it uses identical filenames under /boot.

Before this patch grub-get-kernel-settings handled kernel-uki-dtbloader as
a special kernel variant, causing GRUB_NON_STANDARD_KERNEL=true to get set
which leads to /lib/kernel/install.d/20-grub.install setting
GRUB_UPDATE_DEFAULT_KERNEL=false which results in skipping the
grub2-set-default call later on during kernel-install.

As a result of this users of Fedora 44+ ARM64 live media which uses
kernel-uki-dtbloader would still get the old kernel on reboot after
installing kernel updates (Bug 2463620 - GRUB environment variable
saved_entry not updated when installing UKI kernel on F44 aarch64).

Resolve this by treating kernel-uki-dtbloader as default kernel, just
like how kernel-core is handled.

Note on the next rebase of rhboot/grub this may be merged into
commit c5baa5c ("Add grub-get-kernel-settings and use it in 10_linux")

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2463620
Fixes: c5baa5c ("Add grub-get-kernel-settings and use it in 10_linux")
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.