Fix build on loongarch64 - #215
Open
sunhaiyong1978 wants to merge 436 commits into
Open
Conversation
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>
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>
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>
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>
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>
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>
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.
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>
fixes bz#2223437 Signed-off-by: Marta Lewandowska <mlewando@redhat.com>
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>
This is a trivial sign comparison fix. Signed-off-by: Peter Jones <pjones@redhat.com>
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>
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Peter Jones <pjones@redhat.com>
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>
Signed-off-by: Peter Jones <pjones@redhat.com>
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>
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); | ^~~~~~~~~~~~~~~~~~~
Signed-off-by: Peter Jones <pjones@redhat.com>
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 *)’
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}
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>
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>
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>
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.
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>
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>
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>
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>
…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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
…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>
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>
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>
Signed-off-by: Leo Sandoval <lsandova@redhat.com>
Signed-off-by: Leo Sandoval <lsandova@redhat.com>
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>
Add support for UKIs using the efi keyword in BLS snippets. Signed-off-by: Marta Lewandowska <mlewando@redhat.com>
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>
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>
grub-core/kern/dl.c grub-core/kern/loongarch64/dl.c: add grub_arch_dl_min_alignment for loongarch64 grub-core/kern/loongarch64/efi/startup.S: Define start. grub-core/loader/efi/chainloader.c grub-core/loader/efi/linux.c: defined GRUB_PE32_MACHINE_LOONGARCH64. include/grub/fdt.h: add __loongarch__ condition. grub-core/include/grub/loongarch64/efi/memory.h: defined GRUB_EFI_MAX_ALLOCATION_ADDRESS grub-core/Makefile.core.def: add backtrace mod for loongarch64. Signed-off-by: Sun Haiyong <sunhaiyong@zdbr.net>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
grub-core/kern/dl.c
grub-core/kern/loongarch64/dl.c:
add grub_arch_dl_min_alignment for loongarch64
grub-core/kern/loongarch64/efi/startup.S: Define start.
grub-core/loader/efi/chainloader.c
grub-core/loader/efi/linux.c:
defined GRUB_PE32_MACHINE_LOONGARCH64.
include/grub/fdt.h: add loongarch condition.
grub-core/include/grub/loongarch64/efi/memory.h:
defined GRUB_EFI_MAX_ALLOCATION_ADDRESS
grub-core/Makefile.core.def:
add backtrace mod for loongarch64.
Signed-off-by: Sun Haiyong sunhaiyong@zdbr.net