efi: new 'connectefi' command #108

Signed-off-by: Peter Jones <[email protected]>

This makes us use pretty names in the titles we generate in grub2-mkconfig when GRUB_DISTRIBUTOR isn't set. Resolves: rhbz#996794 Signed-off-by: Peter Jones <[email protected]>

Resolves: rhbz#1065360 Signed-off-by: Peter Jones <[email protected]>

Related: rhbz#1148652 Signed-off-by: Peter Jones <[email protected]>

Users reported that newly installed kernels on their systems installed with grub-mkconfig would not appear on the grub boot list in order starting with the most recent. Added an option for rpm-based systems to use the rpm-sort library to sort kernels instead. Resolves rhbz#1124074 Signed-off-by: Robert Marshall <[email protected]> [pjones: fix --enable-rpm-sort configure option] Signed-off-by: Peter Jones <[email protected]> [thierry.vignaud: fix build with rpm-4.16] Signed-off-by: Thierry Vignaud <[email protected]>

…elsewhere. Resolves: rhbz#1215839 Signed-off-by: Peter Jones <[email protected]>

Provided a tool for users to reset the grub2 root user password without having to alter the grub.cfg. The hashed password now lives in a root-only-readable configuration file. Resolves: rhbz#985962 Signed-off-by: Robert Marshall <[email protected]> [pjones: fix the efidir in grub-setpassword and rename tool] Signed-off-by: Peter Jones <[email protected]> [luto: fix grub-setpassword -o's output path] Andy Lutomirski <[email protected]>

Sometimes we have to provision boxes across regions, such as California to Sweden. The http server has a 10 minute timeout, so if we can't get our 250mb image transferred fast enough our provisioning fails, which is not ideal. So add tcp window scaling on open connections and set the window size to 1mb. With this change we're able to get higher sustained transfers between regions and can transfer our image in well below 10 minutes. Without this patch we'd time out every time halfway through the transfer. Thanks, Signed-off-by: Josef Bacik <[email protected]>

Signed-off-by: Peter Jones <[email protected]>

This patch adds grub-get-kernel-settings, which reads the system kernel installation configuration from /etc/sysconfig/kernel, and outputs ${GRUB_...} variables suitable for evaluation by grub-mkconfig. Those variables are then used by 10_linux to choose whether or not to create debug stanzas. Resolves: rhbz#1226325

The netmask configured in firmware is not respected on ppc64 (big endian). When 255.255.252.0 is set as netmask in firmware, the following is the value of bootpath string in grub_ieee1275_parse_bootpath(). /vdevice/l-lan@30000002:speed=auto,duplex=auto,192.168.88.10,,192.168.89.113,192.168.88.1,5,5,255.255.252.0,512 The netmask in this bootpath is no problem, since it's a value specified in firmware. But, The value of 'subnet_mask.ipv4' was set with 0xfffffc00, and __builtin_ctz (~grub_le_to_cpu32 (subnet_mask.ipv4)) returned 16 (not 22). As a result, 16 was used for netmask wrongly. 1111 1111 1111 1111 1111 1100 0000 0000 # subnet_mask.ipv4 (=0xfffffc00) 0000 0000 1111 1100 1111 1111 1111 1111 # grub_le_to_cpu32 (subnet_mask.ipv4) 1111 1111 0000 0011 0000 0000 0000 0000 # ~grub_le_to_cpu32 (subnet_mask.ipv4) And, the count of zero with __builtin_ctz can be 16. This patch changes it as below. 1111 1111 1111 1111 1111 1100 0000 0000 # subnet_mask.ipv4 (=0xfffffc00) 0000 0000 1111 1100 1111 1111 1111 1111 # grub_le_to_cpu32 (subnet_mask.ipv4) 1111 1111 1111 1111 1111 1100 0000 0000 # grub_swap_bytes32(grub_le_to_cpu32 (subnet_mask.ipv4)) 0000 0000 0000 0000 0000 0011 1111 1111 # ~grub_swap_bytes32(grub_le_to_cpu32 (subnet_mask.ipv4)) The count of zero with __builtin_clz can be 22. (clz counts the number of one bits preceding the most significant zero bit)

This needs to be hooked up to --program-transform=, but I haven't had time. Signed-off-by: Peter Jones <[email protected]>

Since our bugs tell us that the xnu boot entries really just don't work most of the time, and they create piles of extra boot entries, because they can't quite figure out 32-vs-64 and other stuff like that. It's rediculous, and we should just boot their bootloader through the chainloader instead. So this patch does that. Resolves: rhbz#893179 Signed-off-by: Peter Jones <[email protected]>

This patch adds the ability to specify a different root on a btrfs filesystem too boot from other than the default one. btrfs-list-snapshots <dev> will list the subvolumes available on the filesystem. set btrfs_subvol=<path> and set btrfs_subvolid=<subvolid> will specify which subvolume to use and any pathnames provided with either of those variables set will start using that root. If the subvolume or subvolume id doesn't exist, then an error case will result. It is possible to boot into a separate GRUB instance by exporting the variable and loading the config file from the subvolume. Signed-off-by: Jeff Mahoney <[email protected]>

We should export btrfs_subvol and btrfs_subvolid to have both visible to subsidiary configuration files loaded using configfile. Signed-off-by: Michael Chang <[email protected]>

Signed-off-by: Michael Chang <[email protected]>

Ref: bsc#953538

Signed-off-by: Peter Jones <[email protected]>

This uses grub_efi_allocate_pool(), grub_efi_free_pool(), and grub_efi_free_pages() instead of open-coded efi_call_N() calls, so we get more reasonable type checking. Signed-off-by: Peter Jones <[email protected]>

This avoids syntax checkers getting confused about if it's llx or lx. Signed-off-by: Peter Jones <[email protected]>

This should never be trying this, and since we've consolidated the grubenv to always be on /boot/efi/EFI/fedora/, this code causes it to always make the wrong decision. Resolves: rhbz#1484474 Signed-off-by: Peter Jones <[email protected]>

Signed-off-by: Peter Jones <[email protected]>

On my laptop running at 2.4GHz, if I run a VM where tsc calibration using pmtimer will fail presuming a broken pmtimer, it takes ~51 seconds to do so (as measured with the stopwatch on my phone), with a tsc delta of 0x1cd1c85300, or around 125 billion cycles. If instead of trying to wait for 5-200ms to show up on the pmtimer, we try to wait for 5-200us, it decides it's broken in ~0x2626aa0 TSCs, aka ~2.4 million cycles, or more or less instantly. Additionally, this reading the pmtimer was returning 0xffffffff anyway, and that's obviously an invalid return. I've added a check for that and 0 so we don't bother waiting for the test if what we're seeing is dead pins with no response at all. If "debug" is includes "pmtimer", you will see one of the following three outcomes. If pmtimer gives all 0 or all 1 bits, you will see: kern/i386/tsc_pmtimer.c:77: pmtimer: 0xffffff bad_reads: 1 kern/i386/tsc_pmtimer.c:77: pmtimer: 0xffffff bad_reads: 2 kern/i386/tsc_pmtimer.c:77: pmtimer: 0xffffff bad_reads: 3 kern/i386/tsc_pmtimer.c:77: pmtimer: 0xffffff bad_reads: 4 kern/i386/tsc_pmtimer.c:77: pmtimer: 0xffffff bad_reads: 5 kern/i386/tsc_pmtimer.c:77: pmtimer: 0xffffff bad_reads: 6 kern/i386/tsc_pmtimer.c:77: pmtimer: 0xffffff bad_reads: 7 kern/i386/tsc_pmtimer.c:77: pmtimer: 0xffffff bad_reads: 8 kern/i386/tsc_pmtimer.c:77: pmtimer: 0xffffff bad_reads: 9 kern/i386/tsc_pmtimer.c:77: pmtimer: 0xffffff bad_reads: 10 kern/i386/tsc_pmtimer.c:78: timer is broken; giving up. This outcome was tested using qemu+kvm with UEFI (OVMF) firmware and these options: -machine pc-q35-2.10 -cpu Broadwell-noTSX If pmtimer gives any other bit patterns but is not actually marching forward fast enough to use for clock calibration, you will see: kern/i386/tsc_pmtimer.c:121: pmtimer delta is 0x0 (1904 iterations) kern/i386/tsc_pmtimer.c:124: tsc delta is implausible: 0x2626aa0 This outcome was tested using grub compiled with GRUB_PMTIMER_IGNORE_BAD_READS defined (so as not to trip the bad read test) using qemu+kvm with UEFI (OVMF) firmware, and these options: -machine pc-q35-2.10 -cpu Broadwell-noTSX If pmtimer actually works, you'll see something like: kern/i386/tsc_pmtimer.c:121: pmtimer delta is 0x0 (1904 iterations) kern/i386/tsc_pmtimer.c:124: tsc delta is implausible: 0x2626aa0 This outcome was tested using qemu+kvm with UEFI (OVMF) firmware, and these options: -machine pc-i440fx-2.4 -cpu Broadwell-noTSX I've also tested this outcome on a real Intel Xeon E3-1275v3 on an Intel Server Board S1200V3RPS using the SDV.RP.B8 "Release" build here: https://firmware.intel.com/sites/default/files/UEFIDevKit_S1200RP_vB8.zip Signed-off-by: Peter Jones <[email protected]>

GRUB now has BootLoaderSpec support, the user can choose to use this by setting GRUB_ENABLE_BLSCFG to true in /etc/default/grub. On this setup, the boot menu entries are not added to the grub.cfg, instead BLS config files are parsed by blscfg command and the entries created dynamically. A 10_linux_bls grub.d snippet to generate menu entries from BLS files is also added that can be used on platforms where the bootloader doesn't have BLS support and only can parse a normal grub configuration file. Portions of the 10_linux_bls were taken from the ostree-grub-generator script that's included in the OSTree project. Fixes to support multi-devices and generate a BLS section even if no kernels are found in the boot directory were proposed by Yclept Nemo and Tom Gundersen respectively. Signed-off-by: Peter Jones <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]>

The emu platform doesn't have a grub_backtrace() implementation, so this causes a build error. Don't attempt to call this when building grub-emu. Signed-off-by: Javier Martinez Canillas <[email protected]>

When using grub-emu, the linux and initrd commands are used as arguments to the kexec command line tool, to allow booting the selected menu entry.

Signed-off-by: Peter Jones <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> [jhlavac: Use ${etcdefaultgrub} instead of /etc/default/grub] Signed-off-by: Jan Hlavac <[email protected]>

Signed-off-by: Peter Jones <[email protected]>

This just makes copy+paste of our debug loading info easier. Signed-off-by: Peter Jones <[email protected]>

This makes a grub_dprintf() call during platform init and during module loading that tells us the virtual addresses of the .text and .data sections of grub-core/kernel.exec and any modules it loads. Specifically, it displays them in the gdb "add-symbol-file" syntax, with the presumption that there's a variable $grubdir that reflects the path to any such binaries. Signed-off-by: Peter Jones <[email protected]>

Commit 318ee04 ("make better backtraces") reworked the backtrace logic but the changes lead to the following build error on the grub-emu platform: grub_emu_lite-symlist.o:(.data+0xf08): undefined reference to `start' collect2: error: ld returned 1 exit status make[3]: *** [Makefile:25959: grub-emu-lite] Error 1 make[3]: *** Waiting for unfinished jobs.... cat kernel_syms.input | grep -v '^#' | sed -n \ -e '/EXPORT_FUNC *([a-zA-Z0-9_]*)/{s/.*EXPORT_FUNC *($[a-zA-Z0-9_]*$).*/defined kernel '""'\1/;p;}' \ -e '/EXPORT_VAR *([a-zA-Z0-9_]*)/{s/.*EXPORT_VAR *($[a-zA-Z0-9_]*$).*/defined kernel '""'\1/;p;}' \ | sort -u >kernel_syms.lst The problem is that start and _start symbols are exported unconditionally, but these aren't defined for grub-emu since is an emultaed platform so it doesn't have a startup logic. Don't attempt to export those for grub-emu. Signed-off-by: Javier Martinez Canillas <[email protected]>

This patch replaces fixed 6-byte link layer address with up to 32-byte variable sized address. This allows supporting Infiniband and Omni-Path fabric which use 20-byte address, but other network card types can also take advantage of this change. The network card driver is responsible for replacing L2 header provided by grub2 if needed. This approach is compatible with UEFI network stack which also allows up to 32-byte variable size link address. The BOOTP/DHCP packet format is limited to 16 byte client hardware address, if link address is more that 16-bytes then chaddr field in BOOTP it will be set to 0 as per rfc4390. Resolves: rhbz#1370642 Signed-off-by: Andrzej Kacprowski <[email protected]> [msalter: Fix max string calculation in grub_net_hwaddr_to_str] Signed-off-by: Mark Salter <[email protected]>

Allow specifying port numbers for http and tftp paths, and allow ipv6 addresses to be recognized with brackets around them, which is required to specify a port number Signed-off-by: Aaron Miller <[email protected]> [pjones: various bug fixes] Signed-off-by: Peter Jones <[email protected]>

Implement new net_bootp6 command for IPv6 network auto configuration via the DHCPv6 protocol (RFC3315). Signed-off-by: Michael Chang <[email protected]> Signed-off-by: Ken Lin <[email protected]> [pjones: Put back our code to add a local route] Signed-off-by: Peter Jones <[email protected]>

When grub2 image is booted from UEFI IPv6 PXE, the DHCPv6 Reply packet is cached in firmware buffer which can be obtained by PXE Base Code protocol. The network interface can be setup through the parameters in that obtained packet. Signed-off-by: Michael Chang <[email protected]> Signed-off-by: Ken Lin <[email protected]>

Update grub documentation for net_bootp6 command. Signed-off-by: Michael Chang <[email protected]> Signed-off-by: Ken Lin <[email protected]>

The vendor class identifier with the string "HTTPClient" is used to denote the packet as responding to HTTP boot request. In DHCP4 config, the filename for HTTP boot is the URL of the boot file while for PXE boot it is the path to the boot file. As a consequence, the next-server becomes obseleted because the HTTP URL already contains the server address for the boot file. For DHCP6 config, there's no difference definition in existing config as dhcp6.bootfile-url can be used to specify URL for both HTTP and PXE boot file. This patch adds processing for "HTTPClient" vendor class identifier in DHCPACK packet by treating it as HTTP format, not as the PXE format. Signed-off-by: Michael Chang <[email protected]> Signed-off-by: Ken Lin <[email protected]>

The PXE Base Code protocol used to obtain cached PXE DHCPACK packet is no longer provided for HTTP Boot. Instead, we have to get the HTTP boot information from the device path nodes defined in following UEFI Specification sections. 9.3.5.12 IPv4 Device Path 9.3.5.13 IPv6 Device Path 9.3.5.23 Uniform Resource Identifiers (URI) Device Path This patch basically does: include/grub/efi/api.h: Add new structure of Uniform Resource Identifiers (URI) Device Path grub-core/net/drivers/efi/efinet.c: Check if PXE Base Code is available, if not it will try to obtain the netboot information from the device path where the image booted from. The DHCPACK packet is recoverd from the information in device patch and feed into the same DHCP packet processing functions to ensure the network interface is setting up the same way it used to be. Signed-off-by: Michael Chang <[email protected]> Signed-off-by: Ken Lin <[email protected]>

In the URI device path node, any name rahter than address can be used for looking up the resources so that DNS service become needed to get answer of the name's address. Unfortunately the DNS is not defined in any of the device path nodes so that we use the EFI_IP4_CONFIG2_PROTOCOL and EFI_IP6_CONFIG_PROTOCOL to obtain it. These two protcols are defined the sections of UEFI specification. 27.5 EFI IPv4 Configuration II Protocol 27.7 EFI IPv6 Configuration Protocol include/grub/efi/api.h: Add new structure and protocol UUID of EFI_IP4_CONFIG2_PROTOCOL and EFI_IP6_CONFIG_PROTOCOL. grub-core/net/drivers/efi/efinet.c: Use the EFI_IP4_CONFIG2_PROTOCOL and EFI_IP6_CONFIG_PROTOCOL to obtain the list of DNS server address for IPv4 and IPv6 respectively. The address of DNS servers is structured into DHCPACK packet and feed into the same DHCP packet processing functions to ensure the network interface is setting up the same way it used to be. Signed-off-by: Michael Chang <[email protected]> Signed-off-by: Ken Lin <[email protected]>

References: fate#320130, bsc#1015589, bsc#1076132 Patch-Mainline: no V1: * Add preliminary support of UEFI networking protocols * Support UEFI HTTPS Boot V2: * Workaround http data access in firmware * Fix DNS device path parsing for efinet device * Relaxed UEFI Protocol requirement * Support Intel OPA (Omni-Path Architecture) PXE Boot V3: * Fix bufio in calculating address of next_buf * Check HTTP respond code * Use HEAD request method to test before GET * Finish HTTP transaction in one go * Fix bsc#1076132 Signed-off-by: Michael Chang <[email protected]> [pjones: make efi_netfs not duplicate symbols from efinet] Signed-off-by: Peter Jones <[email protected]>

Fixing a memory leak in case of error, and a integer overflow, leading to a heap overflow due to overly large chunk sizes. We need to check against some maximum value, otherwise values like 0xffffffff will eventually lead in the allocation functions to small sized buffers, since the len is rounded up to the next reasonable alignment. The following memcpy will then smash the heap, leading to RCE. This is no big issue for pure http boot, since its going to execute an untrusted kernel anyway, but it will break trusted boot scenarios, where only signed code is allowed to be executed. Signed-off-by: Michael Chang <[email protected]>

…ables To be able to automatically detect if the last boot was successful, We want to keep count of succesful / failed boots in some integer environment variable. This commit adds a grub-editenvt "incr" command to increment such integer value env. variables by 1 for use from various boot scripts. Signed-off-by: Hans de Goede <[email protected]>

On single-os systems we do not want to show the menu, unless something went wrong with the previous boot, in which case the user may need the menu to debug/fix the problem. This commit adds a new grub.d/00_menu_auto_hide file which emits a config snippet implementing this. I've chosen to do this in a separate grub.d file because chances of this going upstream are small and this way it will be easier to rebase. Since auto-hiding the menu requires detecting the previous boot was ok, we get fastboot support (where we don't check for a key at all) for free so this commit also adds support for this. The new config-file code uses the following variables: menu_auto_hide Set this to "1" to activate the new auto-hide feature Set this to "2" to auto-hide the menu even when multiple operating systems are installed. Note the menu will still auto show after booting an other os as that won't set boot_success. menu_show_once Set this to "1" to force showing the menu once. boot_success The OS sets this to "1" to indicate a successful boot. boot_indeterminate The OS increments this integer when rebooting after e.g. installing updates or a selinux relabel. fastboot If set to "1" and the conditions for auto-hiding the menu are met, the menu is not shown and all checks for keypresses are skipped, booting the default immediately. 30_os-prober.in changes somewhat inspired by: https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian/patches/quick_boot.patch Signed-off-by: Hans de Goede <[email protected]> --- Changes in v2: -Drop shutdown_success tests, there is no meaningful way for systemd to set this flag (by the time it knows all filesystems are unmounted or read-only -Drop fwsetup_once support, systemd already supports booting directly into the fwsetup by doing "systemctl reboot --firmware"

This commit adds a new grub-set-bootflag utility, which can be used to set known bootflags in the grubenv: boot_success or menu_show_once. grub-set-bootflag is different from grub-editenv in 2 ways: 1) It is intended to be executed by regular users so must be installed as suid root. As such it is written to not use any existing grubenv related code for easy auditing. It can't be executed through pkexec because we want to call it under gdm and pkexec does not work under gdm due the gdm user having /sbin/nologin as shell. 2) Since it can be executed by regular users it only allows setting (assigning a value of 1 to) bootflags which it knows about. Currently those are just boot_success and menu_show_once. This commit also adds a couple of example systemd and files which show how this can be used to set boot_success from a user-session: docs/grub-boot-success.service docs/grub-boot-success.timer The 2 grub-boot-success.systemd files should be placed in /lib/systemd/user and a symlink to grub-boot-success.timer should be added to /lib/systemd/user/timers.target.wants. Signed-off-by: Hans de Goede <[email protected]>

This is an example service file, for use from /lib/systemd/system/system-update.target.wants to increment the boot_indeterminate variable when doing offline updates. Signed-off-by: Hans de Goede <[email protected]>

Signed-off-by: Peter Jones <[email protected]>

This lets you write config files that don't know urls. Signed-off-by: Peter Jones <[email protected]>

This lets us have kernel.img be built with TARGET_CFLAGS but grub-mkimage and friends built with HOST_CFLAGS. That in turn lets us build with an ARM compiler that only has hard-float ABI versions of crt*.o and libgcc*, but still use soft float for grub.efi. Signed-off-by: Peter Jones <[email protected]>

…fierxx.c This makes it so you can treat grub-module-verifierxx.c as a file you can build directly, so syntax checkers like vim's "syntastic" plugin, which uses "gcc -x c -fsyntax-only" to build it, will work. One still has to do whatever setup is required to make it pick the right include dirs, which -W options we use, etc., but this makes it so you can do the checking on the file you're editing, rather than on a different file. v2: fix the typo in the #else clause in util/grub-module-verifierXX.c Signed-off-by: Peter Jones <[email protected]>

Trying to avoid all variants of: cat syminfo.lst | sort | gawk -f ../../grub-core/genmoddep.awk > moddep.lst || (rm -f moddep.lst; exit 1) grub_fdt_install in linux is not defined grub_fdt_load in linux is not defined grub_fdt_unload in linux is not defined grub_fdt_install in xen_boot is not defined grub_fdt_load in xen_boot is not defined grub_fdt_unload in xen_boot is not defined Signed-off-by: Peter Jones <[email protected]>

Signed-off-by: Peter Jones <[email protected]>

This sets a couple of variables. With the url http://www.example.com/foo/bar : http_path: /foo/bar http_url: http://www.example.com/foo/bar Signed-off-by: Peter Jones <[email protected]>

Signed-off-by: Peter Jones <[email protected]>

I'm really tired of half the tools I get to use having one and the other half having the other. Signed-off-by: Peter Jones <[email protected]>

This adds a command that shows you info about grub's version, the grub target platform, the compiler version, and if you built with --with-rpm-version=<string>, the rpm package version. Signed-off-by: Peter Jones <[email protected]>

Signed-off-by: Peter Jones <[email protected]>

On mustang, our memory map looks like: Type Physical start - end #Pages Size Attributes reserved 0000004000000000-00000040001fffff 00000200 2MiB UC WC WT WB conv-mem 0000004000200000-0000004393ffffff 00393e00 14654MiB UC WC WT WB ldr-code 0000004394000000-00000043f7ffffff 00064000 1600MiB UC WC WT WB BS-data 00000043f8000000-00000043f801ffff 00000020 128KiB UC WC WT WB conv-mem 00000043f8020000-00000043fa15bfff 0000213c 34032KiB UC WC WT WB ldr-code 00000043fa15c000-00000043fa2a1fff 00000146 1304KiB UC WC WT WB ldr-data 00000043fa2a2000-00000043fa3e8fff 00000147 1308KiB UC WC WT WB conv-mem 00000043fa3e9000-00000043fa3e9fff 00000001 4KiB UC WC WT WB ldr-data 00000043fa3ea000-00000043fa3eafff 00000001 4KiB UC WC WT WB ldr-code 00000043fa3eb000-00000043fa4affff 000000c5 788KiB UC WC WT WB BS-code 00000043fa4b0000-00000043fa59ffff 000000f0 960KiB UC WC WT WB RT-code 00000043fa5a0000-00000043fa5affff 00000010 64KiB RT UC WC WT WB RT-data 00000043fa5b0000-00000043fa5bffff 00000010 64KiB RT UC WC WT WB RT-code 00000043fa5c0000-00000043fa5cffff 00000010 64KiB RT UC WC WT WB ldr-data 00000043fa5d0000-00000043fa5d0fff 00000001 4KiB UC WC WT WB BS-code 00000043fa5d1000-00000043fa5ddfff 0000000d 52KiB UC WC WT WB reserved 00000043fa5de000-00000043fa60ffff 00000032 200KiB UC WC WT WB ACPI-rec 00000043fa610000-00000043fa6affff 000000a0 640KiB UC WC WT WB ACPI-nvs 00000043fa6b0000-00000043fa6bffff 00000010 64KiB UC WC WT WB ACPI-rec 00000043fa6c0000-00000043fa70ffff 00000050 320KiB UC WC WT WB RT-code 00000043fa710000-00000043fa72ffff 00000020 128KiB RT UC WC WT WB RT-data 00000043fa730000-00000043fa78ffff 00000060 384KiB RT UC WC WT WB RT-code 00000043fa790000-00000043fa79ffff 00000010 64KiB RT UC WC WT WB RT-data 00000043fa7a0000-00000043fa99ffff 00000200 2MiB RT UC WC WT WB RT-code 00000043fa9a0000-00000043fa9affff 00000010 64KiB RT UC WC WT WB RT-data 00000043fa9b0000-00000043fa9cffff 00000020 128KiB RT UC WC WT WB BS-code 00000043fa9d0000-00000043fa9d9fff 0000000a 40KiB UC WC WT WB reserved 00000043fa9da000-00000043fa9dbfff 00000002 8KiB UC WC WT WB conv-mem 00000043fa9dc000-00000043fc29dfff 000018c2 25352KiB UC WC WT WB BS-data 00000043fc29e000-00000043fc78afff 000004ed 5044KiB UC WC WT WB conv-mem 00000043fc78b000-00000043fca01fff 00000277 2524KiB UC WC WT WB BS-data 00000043fca02000-00000043fcea3fff 000004a2 4744KiB UC WC WT WB conv-mem 00000043fcea4000-00000043fcea4fff 00000001 4KiB UC WC WT WB BS-data 00000043fcea5000-00000043fd192fff 000002ee 3000KiB UC WC WT WB conv-mem 00000043fd193000-00000043fd2b0fff 0000011e 1144KiB UC WC WT WB BS-data 00000043fd2b1000-00000043ff80ffff 0000255f 38268KiB UC WC WT WB BS-code 00000043ff810000-00000043ff99ffff 00000190 1600KiB UC WC WT WB RT-code 00000043ff9a0000-00000043ff9affff 00000010 64KiB RT UC WC WT WB conv-mem 00000043ff9b0000-00000043ff9bffff 00000010 64KiB UC WC WT WB RT-data 00000043ff9c0000-00000043ff9effff 00000030 192KiB RT UC WC WT WB conv-mem 00000043ff9f0000-00000043ffa05fff 00000016 88KiB UC WC WT WB BS-data 00000043ffa06000-00000043ffffffff 000005fa 6120KiB UC WC WT WB MMIO 0000000010510000-0000000010510fff 00000001 4KiB RT MMIO 0000000010548000-0000000010549fff 00000002 8KiB RT MMIO 0000000017000000-0000000017001fff 00000002 8KiB RT MMIO 000000001c025000-000000001c025fff 00000001 4KiB RT This patch adds a requirement when we're trying to find the base of ram, that the memory we choose is actually /allocatable/ conventional memory, not merely write-combining. On this machine that means we wind up with an allocation around 0x4392XXXXXX, which is a reasonable address. This also changes grub_efi_allocate_pages_real() so that if 0 is allocated, it tries to allocate again starting with the same max address it did the first time, rather than interposing GRUB_EFI_MAX_USABLE_ADDRESS there, so that any per-platform constraints on its given address are maintained. Signed-off-by: Peter Jones <[email protected]>

- Don't limit allocations on 64-bit platforms to < 0x[37f]fffffff if we're using the "large" code model ; use __UINTPTR_MAX__. - Get the comparison right to check the address we've allocated. - Fix the allocation for the command line as well. *But*, when we did this some systems started failing badly; coudln't parse partition tables, etc. What's going on here is the disk controller is silently failing DMAs to addresses above 4GB, so we're trying to parse uninitialized (or HW zeroed) ram when looking for the partition table, etc. So to limit this, we make grub_malloc() pick addresses below 4GB on x86_64, but the direct EFI page allocation functions can get addresses above that. Additionally, we now try to locate kernel+initrd+cmdline+etc below 0x7fffffff, and if they're too big to fit any memory window there, then we try a higher address. Signed-off-by: Peter Jones <[email protected]>

Signed-off-by: Peter Jones <[email protected]>

Lots of machines apparently can't DMA correctly above 4GB during UEFI, so use bounce buffers for the initramfs read. Signed-off-by: Peter Jones <[email protected]>

This just helps the next patch be easier to read. Signed-off-by: Peter Jones <[email protected]>

This helps enable allocations above 4GB. Signed-off-by: Peter Jones <[email protected]>

This enables everything except the kernel itself to be above 4GB. Putting the kernel up there still doesn't work, because of the way params->code32_start is used. Signed-off-by: Peter Jones <[email protected]>

This makes the stack executable on most of the grub utilities, which is bad, and rpmdiff complains about it. Signed-off-by: Peter Jones <[email protected]>

Signed-off-by: Peter Jones <[email protected]>

This adds "increment" and "decrement" commands, and uses them to maintain our variables in 01_fallback_counter. It also simplifies the counter logic, so that there are no nested tests that conflict with each other. Apparently, this *really* wasn't tested well enough. Resolves: rhbz#1614637 Signed-off-by: Peter Jones <[email protected]> [lorbus: add comments and revert logic changes in 01_fallback_counting] Signed-off-by: Christian Glombek <[email protected]>

Currently if grub_strtoul(saved_entry_value, NULL, 0) does not return an error, we assume the value it has produced is a correct index into our menu entry list, and do not try to interpret the value as the "id" or "title" . In cases where "id" or "title" start with a numeral, this makes them impossible to use as selection criteria. This patch splits the search into three phases - matching id, matching title, and only once those have been exhausted, trying to interpret the ID as a numeral. In that case, we also require that the entire string is numeric, not merely a string with leading numeric characters. Resolves: rhbz#1640979 Signed-off-by: Peter Jones <[email protected]> [javierm: fix menu entry selection based on title] Signed-off-by: Javier Martinez Canillas <[email protected]>

The --users option is used to restrict the access to specific menu entries only to a set of users. But the option requires an argument to either be a constant or a variable that has been set. So for example the following: menuentry "May be run by superusers or users in $users" --users $users { linux /vmlinuz } Would fail if $users is not defined and grub would discard the menu entry. Instead, allow the --users option to have an optional argument and ignore the option if the argument was not set. Related: rhbz#1652434 Signed-off-by: Javier Martinez Canillas <[email protected]>

This adds "efi-export-env VARIABLE" and "efi-load-env", which manipulate the environment block stored in the EFI variable GRUB_ENV-91376aff-cba6-42be-949d-06fde81128e8. Signed-off-by: Peter Jones <[email protected]>

This makes it so you can do set debug to "all,-scripting,-lexer" and get the obvious outcome. Any negation present will take preference over that conditional, so "all,-scripting,scripting" is the same thing as "all,-scripting". Signed-off-by: Peter Jones <[email protected]>

When a submenu is created, only the exported variables are copied to the new menu context. But we want the variables to be global, so export lets export all variables to the new created submenu. Also, don't unset the default variable when a new submenu is created. Signed-off-by: Javier Martinez Canillas <[email protected]>

Also rename fallback and menu auto hide script to be executed before and after boot success reset script. In menu auto hide script, rename last_boot_ok var to menu_hide_ok

There's always an error printed even when the systemctl kexec command does succeed. That's because systemctl executes it asynchronously, but the emu loader seems to expect it to be synchronous and that should never return. Also, it's wrong to test if kexecute == 1 since we already know that's the case or otherwise the function wouldn't had called grub_fatal() earlier. Finally, systemctl kexec failing shouldn't be a fatal error since the emu loader fallbacks to executing the kexec command in case of a failure. Signed-off-by: Javier Martinez Canillas <[email protected]>

They just polute the output and should better be debug messages instead. Signed-off-by: Javier Martinez Canillas <[email protected]>

While it's true that for most loaders the boot command never returns, it may be the case that it does. For example the GRUB emulator boot command calls to systemctl kexec which in turn does an asynchonous call to kexec. So in this case GRUB will wrongly assume that the boot command fails and print a "Failed to boot both default and fallback entries" even when the kexec call later succeeds. Signed-off-by: Javier Martinez Canillas <[email protected]>

The fdt module isn't build for this platform, so adding the declarations with platform emu will lead to the following undefined reference errors: BUILDSTDERR: /usr/bin/ld: grub_emu_lite-symlist.o:(.data+0x500): undefined reference to `grub_fdt_add_subnode' BUILDSTDERR: /usr/bin/ld: grub_emu_lite-symlist.o:(.data+0x518): undefined reference to `grub_fdt_check_header' BUILDSTDERR: /usr/bin/ld: grub_emu_lite-symlist.o:(.data+0x530): undefined reference to `grub_fdt_check_header_nosize' BUILDSTDERR: /usr/bin/ld: grub_emu_lite-symlist.o:(.data+0x548): undefined reference to `grub_fdt_create_empty_tree' BUILDSTDERR: /usr/bin/ld: grub_emu_lite-symlist.o:(.data+0x560): undefined reference to `grub_fdt_find_subnode' BUILDSTDERR: /usr/bin/ld: grub_emu_lite-symlist.o:(.data+0x578): undefined reference to `grub_fdt_first_node' BUILDSTDERR: /usr/bin/ld: grub_emu_lite-symlist.o:(.data+0x590): undefined reference to `grub_fdt_get_nodename' BUILDSTDERR: /usr/bin/ld: grub_emu_lite-symlist.o:(.data+0x5a8): undefined reference to `grub_fdt_get_prop' BUILDSTDERR: /usr/bin/ld: grub_emu_lite-symlist.o:(.data+0x5c0): undefined reference to `grub_fdt_next_node' BUILDSTDERR: /usr/bin/ld: grub_emu_lite-symlist.o:(.data+0x5d8): undefined reference to `grub_fdt_set_prop' BUILDSTDERR: collect2: error: ld returned 1 exit status BUILDSTDERR: make[1]: *** [Makefile:27093: grub-emu-lite] Error 1 BUILDSTDERR: make[1]: *** Waiting for unfinished jobs.... Signed-off-by: Javier Martinez Canillas <[email protected]>

Signed-off-by: Peter Jones <[email protected]>

The risc-v architecture also uses Device Trees, but the symbols in the fdt header aren't defined for this arch which lead to following error: BUILDSTDERR: ../../grub-core/loader/efi/fdt.c: In function 'grub_fdt_load': BUILDSTDERR: ../../grub-core/loader/efi/fdt.c:48:39: warning: implicit declaration of function 'grub_fdt_get_totalsize' [-Wimplicit-function-declaration] BUILDSTDERR: 48 | size = GRUB_EFI_BYTES_TO_PAGES (grub_fdt_get_totalsize (fdt)); Signed-off-by: Javier Martinez Canillas <[email protected]>

We have stopped using pkexec for grub-set-bootflag, instead it is now installed suid root, update the comment accordingly. Signed-off-by: Hans de Goede <[email protected]>

Make the grubenv writing code in grub-set-bootflag more robust by writing the modified grubenv to a tmpfile first and then renaming the tmpfile over the old grubenv (following symlinks). Signed-off-by: Hans de Goede <[email protected]>

The "grub.d: Split out boot success reset from menu auto hide script" not only moved the code to clear boot_success and boot_indeterminate but for some reason also mixed in some broken changes to the boot_indeterminate handling. The boot_indeterminate var is meant to suppress the boot menu after a reboot from either a selinux-relabel or offline-updates. These 2 special boot scenarios do not set boot_success since there is no successfull interaction with the user. Instead they increment boot_indeterminate, and if it is 1 and only when it is 1, so the first reboot after a "special" boot we suppress the menu. To ensure that we do show the menu if we somehow get stuck in a "special" boot loop where we do special-boots without them incrementing boot_indeterminate, the code before the "grub.d: Split out boot success reset from menu auto hide script" commit would increment boot_indeterminate once when it is 1, so that even if the "special" boot reboot-loop immediately we would show the menu on the next boot. That commit broke this however, because it not only moves the code, it also changes it from only "incrementing" boot_indeterminate once to always incrementing it, except when boot_success == 1 (and we reset it). This broken behavior causes the following problem: 1. Boot a broken kernel, system hangs, power-cycle 2. boot_success now != 1, so we increment boot_indeterminate from 0 (unset!) to 1. User either simply tries again, or makes some changes but the end-result still is a system hang, power-cycle 3. Now boot_indeterminate==1 so we do not show the menu even though the previous boot failed -> BAD This commit fixes this by restoring the behavior of setting boot_indeterminate to 2 when it was 1 before. Fixes: "grub.d: Split out boot success reset from menu auto hide script" Signed-off-by: Hans de Goede <[email protected]>

The commit "Try to pick better locations for kernel and initrd" missed to define this macro for the RISC-V (riscv64) architecture, so add it there. Signed-off-by: David Abdurachmanov <[email protected]>

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 <[email protected]>

All other architectures have start symbol. Hopefully this resolves: BUILDSTDERR: ././grub-mkimage: error: undefined symbol start. Signed-off-by: David Abdurachmanov <[email protected]>

The python-unversioned-command package is not installed in the buildroot, but the bootstrap script expects the python command to be present if one is not defined. So building the package leads to the following error: ./autogen.sh: line 20: python: command not found This is harmless since gnulib is included as a source anyways, because the builders can't download. But still the issue should be fixed by forcing to use python3 that's the default in Fedora now. Signed-off-by: Javier Martinez Canillas <[email protected]>

The fw_path environment variable is used by http_configure() function to determine the HTTP path that should be used as prefix when using relative HTTP paths. And this is stored in the http_path environment variable. Later, that variable is looked up by grub_efihttp_open() to generate the complete path to be used in the HTTP request. But these variables are not exported, which means that are not global and so are only found in the initial context. This can cause commands like configfile that create a new context to fail because the fw_path and http_path variables will not be found. Resolves: rhbz#1616395 Signed-off-by: Javier Martinez Canillas <[email protected]>

According to RFC 2732 (https://www.ietf.org/rfc/rfc2732.txt), literal IPv6 addresses must be enclosed in square brackets. But GRUB currently does not do this and is causing HTTP servers to send Bad Request (400) responses. For example, the following is the HTTP stream when fetching a config file: HEAD /EFI/BOOT/grub.cfg HTTP/1.1 Host: 2000:dead:beef:a::1 Accept: */* User-Agent: UefiHttpBoot/1.0 HTTP/1.1 400 Bad Request Date: Thu, 05 Mar 2020 14:46:02 GMT Server: Apache/2.4.41 (Fedora) OpenSSL/1.1.1d Connection: close Content-Type: text/html; charset=iso-8859-1 and after enclosing the IPv6 address the HTTP request is successful: HEAD /EFI/BOOT/grub.cfg HTTP/1.1 Host: [2000:dead:beef:a::1] Accept: */* User-Agent: UefiHttpBoot/1.0 HTTP/1.1 200 OK Date: Thu, 05 Mar 2020 14:48:04 GMT Server: Apache/2.4.41 (Fedora) OpenSSL/1.1.1d Last-Modified: Thu, 27 Feb 2020 17:45:58 GMT ETag: "206-59f924b24b1da" Accept-Ranges: bytes Content-Length: 518 Resolves: rhbz#1732765 Signed-off-by: Javier Martinez Canillas <[email protected]>

The grub_efi_net_parse_address() function is not covering the case where a port number is specified in an IPv4 or IPv6 address, so will fail to parse the network address. For most cases the issue is harmless, because the function is only used to match an address with a network interface and if fails the default is used. But still is a bug that has to be fixed and it causes error messages to be printed like the following: error: net/efi/net.c:782:unrecognised network address '192.168.122.1:8080' error: net/efi/net.c:781:unrecognised network address '[2000:dead:beef:a::1]:8080' Resolves: rhbz#1732765 Signed-off-by: Javier Martinez Canillas <[email protected]>

The grub_efi_string_to_ip4_address() function wrongly assumes that an IPv6 address is an IPv4 address, because it doesn't take into account the case of a caller passing an IPv6 address as a string. This leads to the grub_efi_net_parse_address() function to fail and print the following error message: error: net/efi/net.c:785:unrecognised network address '2000:dead:beef:a::1' Resolves: rhbz#1732765 Signed-off-by: Javier Martinez Canillas <[email protected]>

Currently if parsing the address fails an error message is printed. But in most cases this isn't a fatal error since the grub_efi_net_parse_address() function is only used to match an address with a network interface to use. And if this fails, the default interface is used which is good enough for most cases. So instead of printing an error that would pollute the console just print a debug message if the address is not parsed correctly. A user can enable debug messages for the efinet driver to have information about the failure and the fact that the default interface is being used. Related: rhbz#1732765 Signed-off-by: Javier Martinez Canillas <[email protected]>

Make F8, which used to be the hotkey to show the Windows boot menu during boot for a long long time, also interrupt sleeps / stop the menu countdown. Signed-off-by: Javier Martinez Canillas <[email protected]>

Upstream GRUB uses the EFI LoadImage() and StartImage() to boot the Linux kernel. But our custom EFI loader that supports Secure Boot instead uses the EFI handover protocol (for x86) or jumping directly to the PE/COFF entry point (for aarch64). This is done to allow the bootloader to verify the images using the shim lock protocol to avoid booting untrusted binaries. Since the bootloader loads the kernel from the boot media instead of using LoadImage(), it is responsible to set the Loaded Image base address before booting the kernel. Otherwise the kernel EFI stub will complain that it was not set correctly and print the following warning message: EFI stub: ERROR: FIRMWARE BUG: efi_loaded_image_t::image_base has bogus value Resolves: rhbz#1814690 Signed-off-by: Javier Martinez Canillas <[email protected]>

Currently if the EFI firmware fails to do a TPM measurement for a file, the error will be propagated to the verifiers framework and so opening the file will not succeed. This mean that buggy firmwares will prevent the system to boot since the loader won't be able to open any file. But failing to do TPM measurements shouldn't be a fatal error and the system should still be able to boot. Signed-off-by: Javier Martinez Canillas <[email protected]>

The EFI linux loader allocates a bounce buffer to copy the initrd since in some machines doing DMA on addresses above 4GB is not possible during EFI. But the verifiers framework also allocates a buffer to copy the initrd in its grub_file_open() handler. It does this since the data to verify has to be passed as a single chunk to modules that use the verifiers framework. If the initrd image size is big there may not be enough memory in the heap to allocate two buffers of that size. This causes an allocation failure in the verifiers framework and leads to the initrd not being read. To prevent these allocation failures, let's reduce the maximum size of the bounce buffer used in the EFI loader. Since the data read can be copied to the actual initrd address in multilple chunks. Resolves: rhbz#1838633 Signed-off-by: Javier Martinez Canillas <[email protected]>

There are two different HTTP drivers that can be used when requesting an HTTP resource: the efi/http that uses the EFI_HTTP_PROTOCOL and the http that uses GRUB's HTTP and TCP/IP implementation. The efi/http driver appends a prefix that is defined in the variable http_path, but the http driver doesn't. So using this driver and attempting to fetch a resource using a relative path fails. Signed-off-by: Javier Martinez Canillas <[email protected]>

Somewhere along the way this got mis-merged to include a return without a value. Fix it up. Signed-off-by: Peter Jones <[email protected]>

Signed-off-by: Peter Jones <[email protected]>

In theory all of this data comes from the firmware stack and it should be safe, but it's better to be paranoid. Signed-off-by: Peter Jones <[email protected]>

These could be triggered by an extremely large number of arguments to the initrd command on 32-bit architectures, or a crafted filesystem with very large files on any architecture. Signed-off-by: Colin Watson <[email protected]>

If certificates that signed grub are installed into db, grub can be booted directly. It will then boot any kernel without signature validation. The booted kernel will think it was booted in secureboot mode and will implement lockdown, yet it could have been tampered. This version of the patch skips calling verification, when booted without secureboot. And is indented with gnu ident. CVE-2020-15705 Reported-by: Mathieu Trudel-Lapierre <[email protected]> Signed-off-by: Dimitri John Ledkov <[email protected]>

This will need to get folded back in the right place on the next rebase, but it's before "Make grub_strtol() "end" pointers have safer const qualifiers" currently, so for now I'm leaving it here instead of merging it back with the original patch. Signed-off-by: Peter Jones <[email protected]>

…er-menu=xxx" work with grub This commit adds a number of scripts / config files to make "systemctl reboot --boot-loader-menu=xxx" work with grub: 1. /lib/systemd/system/systemd-logind.service.d/10-grub.conf This sets SYSTEMD_REBOOT_TO_BOOT_LOADER_MENU in the env. for logind, indicating that the boot-loader which is used supports this feature, see: https://github.com/systemd/systemd/blob/master/docs/ENVIRONMENT.md 2. /lib/systemd/system/grub-systemd-integration.service /lib/systemd/system/reboot.target.wants/grub-systemd-integration.service -> ../grub-systemd-integration.service /usr/libexec/grub/grub-systemd-integration.sh The symlink in the .wants dir causes the added service file to be started by systemd just before rebooting the system. If /run/systemd/reboot-to-boot-loader-menu exist then the service will run the grub-systemd-integration.sh script. This script sets the new menu_show_once_timeout grubenv variable to the requested timeout in seconds. 3. /etc/grub.d/14_menu_show_once This new grub-mkconfig snippet adds the necessary code to the generated grub.conf to honor the new menu_show_once_timeout variable, and to automatically clear it after consuming it. Note the service and libexec script use grub-systemd-integration as name because in the future they may be used to add further integration with systemctl reboot --foo options, e.g. support for --boot-loader-entry=NAME. A few notes about upstreaming this patch from the rhboot grub2 fork: 1. I have deliberately put the grub.conf bits for this in a new / separate grub-mkconfig snippet generator for easy upstreaming 2. Even though the commit message mentions the .wants symlink for the .service I have been unable to come up with a clean way to do this at "make install" time, this should be fixed before upstreaming. Downstream notes: 1. Since make install does not add the .wants symlink, this needs to be done in grub2.spec %install 2. This is keeping support for the "old" Fedora specific menu_show_once env variable, which has a hardcoded timeout of 60 sec in 12_menu_auto_hide in place for now. This can be dropped (eventually) in a follow-up patch once GNOME has been converted to use the systemd dbus API equivalent of "systemctl reboot --boot-loader-menu=xxx". Signed-off-by: Hans de Goede <[email protected]>

Downstream RH / Fedora patch for compatibility with old, not (yet) regenerated grub.cfg files which miss the menu_show_once_timeout check. This older grubenv variable leads to a fixed timeout of 60 seconds. Note that the new menu_show_once_timeout will overrule these 60 seconds if both are set and the grub.cfg does have the menu_show_once_timeout check. Signed-off-by: Hans de Goede <[email protected]>

When keyboard controller acts in Translate mode (0x40 mask), then use set 1 since translation is done. Otherwise use the mode queried from the controller (usually set 2). Added "atkeyb" debugging messages in at_keyboard module as well. Resolves: rhbz#1897587 Tested on: - Asus N53SN (set 1 used) - Dell Precision (set 1 used) - HP Elitebook (set 2 used) - HP G5430 (set 1 used, keyboard in XT mode!) - Lenovo P71 & Lenovo T460s (set 2 used) - QEMU/KVM (set 1 used) Signed-off-by: Renaud Métrich <[email protected]>

For each platform, GRUB is shipped as a kernel image and a set of modules. These files are then used by the grub-install utility to install GRUB on a specific device. However, in order to support UEFI Secure Boot, the resulting EFI binary must be signed by a recognized private key. For this reason, for EFI platforms, most distributions also ship prebuilt EFI binaries signed by a distribution-specific private key. In this case, however, the grub-install utility should not be used because it would overwrite the signed EFI binary. The current fix is suboptimal because it preserves all EFI-related code. A better solution could be to modularize the code and provide a build-time option. Resolves: rhbz#1737444 Signed-off-by: Jan Hlavac <[email protected]>

…th absolute and relative timestamp Signed-off-by: Renaud Métrich <[email protected]>

…uccess Signed-off-by: Renaud Métrich <[email protected]>

… is in the environment and not empty Signed-off-by: Renaud Métrich <[email protected]>

Signed-off-by: Renaud Métrich <[email protected]>

Signed-off-by: Diego Domingos <[email protected]>

grub-ofpathname doesn't work with fibre channel because there is no function currently implemented for it. This patch enables it by prividing a function that looks for the port name, building the entire path for OF devices. Signed-off-by: Diego Domingos <[email protected]>

this patch enables the device mapper discovery on ofpath.c. Currently, when we are dealing with a device like /dev/dm-* the ofpath returns null since there is no function implemented to handle this case. This patch implements a function that will look into /sys/block/dm-* devices and search recursively inside slaves directory to find the root disk. Signed-off-by: Diego Domingos <[email protected]>

This seems required with HP DL380p Gen 8 systems. Indeed, with this system, we can see the following sequence: 1. controller is queried to get current configuration (returns 0x30 which is quite standard) 2. controller is queried to get the current keyboard set in used, using code 0xf0 (first part) 3. controller answers with 0xfa which means "ACK" (== ok) 4. then we send "0" to tell "we want to know which set your are supporting" 5. controller answers with 0xfa ("ACK") 6. controller should then give us 1, 2, 3 or 0x43, 0x41, 0x3f, but here it gives us 0xfe which means "NACK" Since there seems no way to determine the current set, and in fact the controller expects set2 to be used, we need to rely on an environment variable. Everything has been tested on this system: using 0xFE (resend command), making sure we wait for ACK in the 2 steps "write_mode", etc. Below is litterature I used to come up with "there is no other solution": - https://wiki.osdev.org/%228042%22_PS/2_Controller - http://www-ug.eecg.toronto.edu/msl/nios_devices/datasheets/PS2%20Keyboard%20Protocol.htm - http://www.s100computers.com/My%20System%20Pages/MSDOS%20Board/PC%20Keyboard.pdf

Add infrastructure to allow firmware to verify the integrity of grub by use of a Linux-kernel-module-style appended signature. We initially target powerpc-ieee1275, but the code should be extensible to other platforms. Usually these signatures are appended to a file without modifying the ELF file itself. (This is what the 'sign-file' tool does, for example.) The verifier loads the signed file from the file system and looks at the end of the file for the appended signature. However, on powerpc-ieee1275 platforms, the bootloader is often stored directly in the PReP partition as raw bytes without a file-system. This makes determining the location of an appended signature more difficult. To address this, we add a new ELF note. The name field of shall be the string "Appended-Signature", zero-padded to 4 byte alignment. The type field shall be 0x41536967 (the ASCII values for the string "ASig"). It must be the final section in the ELF binary. The description shall contain the appended signature structure as defined by the Linux kernel. The description will also be padded to be a multiple of 4 bytes. The padding shall be added before the appended signature structure (not at the end) so that the final bytes of a signed ELF file are the appended signature magic. A subsequent patch documents how to create a grub core.img validly signed under this scheme. Signed-off-by: Daniel Axtens <[email protected]> Signed-off-by: Rashmica Gupta <[email protected]> --- You can experiment with this code with a patched version of SLOF that verifies these signatures. You can find one at: https://github.com/daxtens/SLOF I will be proposing this for inclusion in a future Power Architecture Platform Reference (PAPR).

Before adding information about how grub is signed with an appended signature scheme, it's worth adding some information about how it can currently be signed for UEFI. Signed-off-by: Daniel Axtens <[email protected]>

Signing grub for firmware that verifies an appended signature is a bit fiddly. I don't want people to have to figure it out from scratch so document it here. Signed-off-by: Daniel Axtens <[email protected]>

Trying to start grub-emu with a module that calls grub_dl_set_persistent will crash because grub-emu fakes modules and passes NULL to the module init function. Provide an empty function for the emu case. Fixes: ee7808e (dl: Add support for persistent modules) Signed-off-by: Daniel Axtens <[email protected]>

rsa_pad does the PKCS#1 v1.5 padding for the RSA signature scheme. We want to use it in other RSA signature verification applications. I considered and rejected putting it in lib/crypto.c. That file doesn't currently require any MPI functions, but rsa_pad does. That's not so much of a problem for the grub kernel and modules, but crypto.c also gets built into all the grub utilities. So - despite the utils not using any asymmetric ciphers - we would need to built the entire MPI infrastructure in to them. A better and simpler solution is just to spin rsa_pad out into its own PKCS#1 v1.5 module. Signed-off-by: Daniel Axtens <[email protected]>

The way gcry_rsa and friends (the asymmetric ciphers) are loaded for the pgp module is a bit quirky. include/grub/crypto.h contains: extern struct gcry_pk_spec *grub_crypto_pk_rsa; commands/pgp.c contains the actual storage: struct gcry_pk_spec *grub_crypto_pk_rsa; And the module itself saves to the storage in pgp.c: GRUB_MOD_INIT(gcry_rsa) { grub_crypto_pk_rsa = &_gcry_pubkey_spec_rsa; } This is annoying: gcry_rsa now has a dependency on pgp! We want to be able to bring in gcry_rsa without bringing in PGP, so move the storage to crypto.c. Previously, gcry_rsa depended on pgp and mpi. Now it depends on crypto and mpi. As pgp depends on crypto, this doesn't add any new module dependencies using the PGP verfier. [FWIW, the story is different for the symmetric ciphers. cryptodisk and friends (zfs encryption etc) use grub_crypto_lookup_cipher_by_name() to get a cipher handle. That depends on grub_ciphers being populated by people calling grub_cipher_register. import_gcry.py ensures that the symmetric ciphers call it.] Signed-off-by: Daniel Axtens <[email protected]>

- Define SIZEOF_UNSIGNED_LONG_INT, it's the same as SIZEOF_UNSIGNED_LONG. - Define WORD_BIT, the size in bits of an int. This is a defined in the Single Unix Specification and in gnulib's limits.h. gnulib assumes it's 32 bits on all our platforms, including 64 bit platforms, so we also use that value. - Provide strto[u]l[l] preprocessor macros that resolve to grub_strto[u]l[l]. To avoid gcrypt redefining strtoul, we also define HAVE_STRTOUL here. Signed-off-by: Daniel Axtens <[email protected]>

Import a very trimmed-down set of libtasn1 files: pushd /tmp wget https://ftp.gnu.org/gnu/libtasn1/libtasn1-4.16.0.tar.gz popd pushd grub-core/lib mkdir libtasn1 cp /tmp/libtasn1-4.16.0/{README.md,LICENSE} libtasn1/ mkdir libtasn1/lib cp /tmp/libtasn1-4.16.0/lib/{coding.c,decoding.c,element.c,element.h,errors.c,gstr.c,gstr.h,int.h,parser_aux.c,parser_aux.h,structure.c,structure.h} libtasn1/lib cp /tmp/libtasn1-4.16.0/lib/includes/libtasn1.h ../../include/grub/ git add libtasn1/ ../../include/grub/libtasn1.h popd Signed-off-by: Daniel Axtens <[email protected]>

We don't expect to be able to write ASN.1, only read it, so we can disable some code. Do that with #if 0/#endif, rather than deletion. This means that the difference between upstream and grub is smaller, which should make updating libtasn1 easier in the future. With these exclusions we also avoid the need for minmax.h, which is convenient because it means we don't have to import it from gnulib. Signed-off-by: Daniel Axtens <[email protected]>

Do a few things to make libtasn1 compile as part of grub: - replace strcat. grub removed strcat so replace it with the appropriate calls to memcpy and strlen. - replace c_isdigit with grub_isdigit (and don't import c-ctype from gnulib) grub_isdigit provides the same functionality as c_isdigit: it determines if the input is an ASCII digit without regard for locale. - replace GL_ATTRIBUTE_PURE with __attribute__((pure)) which been supported since gcc-2.96. This avoids messing around with gnulib. - adjust libtasn1.h: drop the ASN1_API logic, it's not needed for our modules. Unconditionally support const and pure attributes and adjust header paths. - adjust header paths to "grub/libtasn1.h". - replace a 64 bit division with a call to grub_divmod64, preventing creation of __udivdi3 calls on 32 bit platforms. Signed-off-by: Daniel Axtens <[email protected]>

Create a wrapper file that specifies the module license. Set up the makefile so it is built. Signed-off-by: Daniel Axtens <[email protected]>

Import tests from libtasn1 that don't use functionality we don't import. I have put them here rather than in the libtasn1 directory because: - They need much more significant changes to run in the grub context. - I don't expect they will need to be changed when updating libtasn1: I expect the old tests will usually continue to pass on new versions. This doesn't test the full decoder but that will be exercised in test suites for coming patch sets. Signed-off-by: Daniel Axtens <[email protected]>

To support verification of appended signatures, we need a way to embed the necessary public keys. Existing appended signature schemes in the Linux kernel use X.509 certificates, so allow certificates to be embedded in the grub core image in the same way as PGP keys. Signed-off-by: Alastair D'Silva <[email protected]> Signed-off-by: Daniel Axtens <[email protected]>

In order to parse PKCS#7 messages and X.509 certificates with libtasn1, we need some information about how they are encoded. We get these from GNUTLS, which has the benefit that they support the features we need and are well tested. The GNUTLS license is LGPLv2.1+, which is GPLv3 compatible, allowing us to import it without issue. Signed-off-by: Daniel Axtens <[email protected]>

This code allows us to parse: - PKCS#7 signedData messages. Only a single signerInfo is supported, which is all that the Linux sign-file utility supports creating out-of-the-box. Only RSA, SHA-256 and SHA-512 are supported. Any certificate embedded in the PKCS#7 message will be ignored. - X.509 certificates: at least enough to verify the signatures on the PKCS#7 messages. We expect that the certificates embedded in grub will be leaf certificates, not CA certificates. The parser enforces this. Signed-off-by: Daniel Axtens <[email protected]>

Building on the parsers and the ability to embed x509 certificates, as well as the existing gcrypt functionality, add a module for verifying appended signatures. This includes a verifier that requires that Linux kernels and grub modules have appended signatures, and commands to manage the list of trusted certificates for verification. Verification must be enabled by setting check_appended_signatures. If GRUB is locked down when the module is loaded, verification will be enabled and locked automatically. As with the PGP verifier, it is not a complete secure-boot solution: other mechanisms, such as a password or lockdown, must be used to ensure that a user cannot drop to the grub shell and disable verification. Signed-off-by: Daniel Axtens <[email protected]>

These tests are run through all_functional_test and test a range of commands and behaviours. Signed-off-by: Daniel Axtens <[email protected]>

This explains how appended signatures can be used to form part of a secure boot chain, and documents the commands and variables introduced. Signed-off-by: Daniel Axtens <[email protected]>

If the 'ibm,secure-boot' property of the root node is 2 or greater, enter lockdown. Signed-off-by: Daniel Axtens <[email protected]>

HEAP_MAX_ADDR is confusing. Currently it is set to 32MB, except on ieee1275 on x86, where it is 64MB. There is a comment which purports to explain it: /* If possible, we will avoid claiming heap above this address, because it seems to cause relocation problems with OSes that link at 4 MiB */ This doesn't make a lot of sense when the constants are well above 4MB already. It was not always this way. Prior to commit 7b5d0fe ("Increase heap limit") in 2010, HEAP_MAX_SIZE and HEAP_MAX_ADDR were indeed 4MB. However, when the constants were increased the comment was left unchanged. It's been over a decade. It doesn't seem like we have problems with claims over 4MB on powerpc or x86 ieee1275. (sparc does things completely differently and never used the constant.) Drop the constant and the check. The only use of HEAP_MIN_SIZE was to potentially override the HEAP_MAX_ADDR check. It is now unused. Remove it. Signed-off-by: Daniel Axtens <[email protected]>

On powerpc-ieee1275, we are running out of memory trying to verify anything. This is because: - we have to load an entire file into memory to verify it. This is extremely difficult to change with appended signatures. - We only have 32MB of heap. - Distro kernels are now often around 30MB. So we want to claim more memory from OpenFirmware for our heap. There are some complications: - The grub mm code isn't the only thing that will make claims on memory from OpenFirmware: * PFW/SLOF will have claimed some for their own use. * The ieee1275 loader will try to find other bits of memory that we haven't claimed to place the kernel and initrd when we go to boot. * Once we load Linux, it will also try to claim memory. It claims memory without any reference to /memory/available, it just starts at min(top of RMO, 768MB) and works down. So we need to avoid this area. See arch/powerpc/kernel/prom_init.c as of v5.11. - The smallest amount of memory a ppc64 KVM guest can have is 256MB. It doesn't work with distro kernels but can work with custom kernels. We should maintain support for that. (ppc32 can boot with even less, and we shouldn't break that either.) - Even if a VM has more memory, the memory OpenFirmware makes available as Real Memory Area can be restricted. A freshly created LPAR on a PowerVM machine is likely to have only 256MB available to OpenFirmware even if it has many gigabytes of memory allocated. EFI systems will attempt to allocate 1/4th of the available memory, clamped to between 1M and 1600M. That seems like a good sort of approach, we just need to figure out if 1/4 is the right fraction for us. We don't know in advance how big the kernel and initrd are going to be, which makes figuring out how much memory we can take a bit tricky. To figure out how much memory we should leave unused, I looked at: - an Ubuntu 20.04.1 ppc64le pseries KVM guest: vmlinux: ~30MB initrd: ~50MB - a RHEL8.2 ppc64le pseries KVM guest: vmlinux: ~30MB initrd: ~30MB Ubuntu VMs struggle to boot with just 256MB under SLOF. RHEL likewise has a higher minimum supported memory figure. So lets first consider a distro kernel and 512MB of addressible memory. (This is the default case for anything booting under PFW.) Say we lose 131MB to PFW (based on some tests). This leaves us 381MB. 1/4 of 381MB is ~95MB. That should be enough to verify a 30MB vmlinux and should leave plenty of space to load Linux and the initrd. If we consider 256MB of RMA under PFW, we have just 125MB remaining. 1/4 of that is a smidge under 32MB, which gives us very poor odds of verifying a distro-sized kernel. However, if we need 80MB just to put the kernel and initrd in memory, we can't claim any more than 45MB anyway. So 1/4 will do. We'll come back to this later. grub is always built as a 32-bit binary, even if it's loading a ppc64 kernel. So we can't address memory beyond 4GB. This gives a natural cap of 1GB for powerpc-ieee1275. Also apply this 1/4 approach to i386-ieee1275, but keep the 32MB cap. make check still works for both i386 and powerpc and I've booted powerpc grub with this change under SLOF and PFW. Signed-off-by: Daniel Axtens <[email protected]>

On PowerVM, the first time we boot a Linux partition, we may only get 256MB of real memory area, even if the partition has more memory. This isn't really enough. Fortunately, the Power Architecture Platform Reference (PAPR) defines a method we can call to ask for more memory. This is part of the broad and powerful ibm,client-architecture-support (CAS) method. CAS can do an enormous amount of things on a PAPR platform: as well as asking for memory, you can set the supported processor level, the interrupt controller, hash vs radix mmu, and so on. We want to touch as little of this as possible because we don't want to step on the toes of the future OS. If: - we are running under what we think is PowerVM (compatible property of / begins with "IBM"), and - the full amount of RMA is less than 512MB (as determined by the reg property of /memory) then call CAS as follows: (refer to the Linux on Power Architecture Reference, LoPAR, which is public, at B.5.2.3): - Use the "any" PVR value and supply 2 option vectors. - Set option vector 1 (PowerPC Server Processor Architecture Level) to "ignore". - Set option vector 2 with default or Linux-like options, including a min-rma-size of 512MB. This will cause a CAS reboot and the partition will restart with 512MB of RMA. Grub will notice the 512MB and not call CAS again. (A partition can be configured with only 256MB of memory, which would mean this request couldn't be satisfied, but PFW refuses to load with only 256MB of memory, so it's a bit moot. SLOF will run fine with 256MB, but we will never call CAS under qemu/SLOF because /compatible won't begin with "IBM".) One of the first things Linux does while still running under OpenFirmware is to call CAS with a much fuller set of options (including asking for 512MB of memory). This includes a much more restrictive set of PVR values and processor support levels, and this will induce another reboot. On this reboot grub will again notice the higher RMA, and not call CAS. We will get to Linux, Linux will call CAS but because the values are now set for Linux this will not induce another CAS reboot and we will finally boot. On all subsequent boots, everything will be configured with 512MB of RMA and all the settings Linux likes, so there will be no further CAS reboots. (phyp is super sticky with the RMA size - it persists even on cold boots. So if you've ever booted Linux in a partition, you'll probably never have grub call CAS. It'll only ever fire the first time a partition loads grub, or if you deliberately lower the amount of memory your partition has below 512MB.) Signed-off-by: Daniel Axtens <[email protected]>

Red Hat certificates have both Key Usage and Extended Key Usage extensions present, but the appended signatures x509 parser doesn't handle the latter and so buils due finding an unrecognised critical extension: Error loading initial key: ../../grub-core/commands/appendedsig/x509.c:780:Unhandled critical x509 extension with OID 2.5.29.37 Fix this by also parsing the Extended Key Usage extension and handle it by verifying that the certificate has a single purpose, that is code signing. Signed-off-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Daniel Axtens <[email protected]>

This patch aims to make grub more robust when booting from SAN/Multipath disks. If a path is failing intermittently so grub will retry the OPEN and READ the disk (grub_ieee1275_open and grub_ieee1275_read) until the total amount of times specified in MAX_RETRIES. Signed-off-by: Diego Domingos <[email protected]>

Signed-off-by: Jan Pokorný <[email protected]>

Currently, grub-rpm-sort is unconditionally compiled whether ./configure has been called with --disable-rpm-sort or not. This adds the necessary logic to configure.ac and Makefile.util.def and some debug output to ./configure and fixes #44.

The rpmvercmp() function was moved from librpm to librpmio. The configure option had some logic to first check if the symbol is in librpm and then librpmio if this check didn't succeed. But the logic wasn't working and rpm sorting was always disabled. Instead of trying to fix this logic, let's just remove since the function already moved and there's no need to check librpm anymore. Now it's enabled again: GRUB2 will be compiled with following components: ... grub-rpm-sort: Yes ... Signed-off-by: Javier Martinez Canillas <[email protected]>

If a proxyDHCP configuration is used, the server name, server IP and boot file values should be taken from the DHCP proxy offer instead of the DHCP server ack packet. Currently that case is not handled, add support for it.

This incompat feature is used to denote that the filesystem stored its metadata checksum seed in the superblock. This is used to allow tune2fs to change the UUID on a mounted metadata_csum filesystem without having to rewrite all the disk metadata. But GRUB doesn't use the metadata checksum in anyway, so can just ignore this feature if is enabled. This is consistent with GRUB filesystem code in general which just does a best effort to access the filesystem's data. It may be removed from the ignored list in the future if supports to do metadata checksumming verification is added to the read-only FS driver. Suggested-by: Eric Sandeen <[email protected]> Suggested-by: Lukas Czerner <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]>

On OPAL ppc64le machines with an old petitboot version that doesn't have support to parse BLS snippets, the grub2-mkconfig script is executed to generate menuentry commands from the BLS snippets. In this case, the script is executed with the --no-grubenv-update option that indicates that no side effects should happen when running the script. But the options field in the BLS snippets are updated regardless, only do the update if --no-grubenv-update was not used. Signed-off-by: Javier Martinez Canillas <[email protected]>

Colin Watson's patch from comment rhboot#11 on the upstream bug: https://savannah.gnu.org/bugs/?35880#comment11 Resolves: rhbz#1592124 Signed-off-by: Paulo Flabiano Smorigo <[email protected]>

The grub-boot-success.timer should be disabled inside a container since it leads to the following error: Jan 09 22:56:38 test sshd[8786]: pam_unix(sshd:session): session opened for user www(uid=1000) by (uid=0) Jan 09 22:58:39 test systemd[8857]: Starting Mark boot as successful... Jan 09 22:58:39 test systemd[8857]: grub-boot-success.service: Main process exited, code=exited, status=1/FAILURE Jan 09 22:58:39 test systemd[8857]: grub-boot-success.service: Failed with result 'exit-code'. Jan 09 22:58:39 test systemd[8857]: Failed to start Mark boot as successful. Jan 09 22:58:39 test grub2-set-bootflag[10034]: Error canonicalizing /boot/grub2/grubenv filename: No such file or directory Resolves: rhbz#1914571

The GRUB configuration file is always placed in /boot/grub2/ now, even for EFI. But the tool is still creating the user.cfg in the ESP and not there. Resolves: rhbz#1955294 Signed-off-by: Javier Martinez Canillas <[email protected]>

The document was moved to https://systemd.io/BOOT_LOADER_SPECIFICATION/, update the URL accordingly to point to the current location. Resolves: rhbz#1926453 Signed-off-by: Javier Martinez Canillas <[email protected]>

The 30_uefi-firmware template checks if an OsIndicationsSupported UEFI var exists and EFI_OS_INDICATIONS_BOOT_TO_FW_UI bit is set, to decide whether a "fwsetup" menu entry would be added or not to the GRUB menu. But this has the problem that it will only work if the configuration file was created on an UEFI machine that supports booting to a firmware UI. This for example doesn't support creating GRUB config files when executing on systems that support both UEFI and legacy BIOS booting. Since creating the config file from legacy BIOS wouldn't allow to access the firmware UI. To prevent this, make the template to unconditionally create the grub.cfg snippet but check at runtime if was booted through UEFI to decide if this entry should be added. That way it won't be added when booting with BIOS. There's no need to check if EFI_OS_INDICATIONS_BOOT_TO_FW_UI bit is set, since that's already done by the "fwsetup" command when is executed. Resolves: rhbz#1823864 Signed-off-by: Javier Martinez Canillas <[email protected]>

The "fwsetup" command is only registered if the firmware supports booting to the firmware setup UI. But it could be possible that the GRUB config already contains a "fwsetup" entry, because it was generated in a machine that has support for this feature. To prevent users getting a "can't find command `fwsetup`" error if it is not supported by the firmware, let's just always register the command but print a more accurate message if the firmware doesn't support this option. Resolves: rhbz#1823864 Signed-off-by: Javier Martinez Canillas <[email protected]>

We are currently allocating just enough memory for the file size, which means that the kernel BSS is in limbo (and not even zeroed). We are also not honoring the alignment specified in the image PE header. This makes us use the PE optional header in which the kernel puts the actual size it needs, including BSS, and make sure we clear it, and honors the specified alignment for the image. Signed-off-by: Benjamin Herrenschmidt <[email protected]>

The GRUB core.img is generated locally, when this is done the grub2-probe tool figures out the device and partition that needs to be read to parse the GRUB configuration file. But in some cases the core.img can't be generated on the host and instead has to be done at package build time. For example, if needs to get signed with a key that's only available on the package building infrastructure. If that's the case, the prefix variable won't have a device and partition but only a directory path. So there's no way for GRUB to know from which device has to read the configuration file. To allow GRUB to continue working on that scenario, fallback to iterating over all the available devices, if reading the config failed when using the prefix and fw_path variables. Signed-off-by: Javier Martinez Canillas <[email protected]>

On RHEL-signed powerpc grub, we sign a grub with -p /grub2 and expect that there's a boot partition. Unfortunately grub_set_prefix_and_root tries to convert this to ($fwdevice)/grub2. This ends up being (ieee1275/disk)/grub2 and that falls apart pretty quickly - there's no file-system on ieee1275/disk, and it makes the search routine try things like (ieee1275/disk,msdos2)(ieee1275/disk)/grub2 which also doesn't work. Detect if we would be about to create (ieee1275/disk)/path and don't: preserve a prefix of /path instead and hope the search later finds us. Related: rhbz#1899864 Signed-off-by: Daniel Axtens <[email protected]>

Mea culpa: when testing the PowerPC special case for signed grub, I assumed qemu and PowerVM would behave identically. This was wrong, and with hindsight a pretty dumb error. This fixes it. This time, I am actually testing on PowerVM. Signed-off-by: Daniel Axtens <[email protected]>

In "arm64: Fix EFI loader kernel image allocation", Ben fixed the kernel alignment to match the alignment given in the PE header. In doing so, a check for valid PE magic was added, which was hard-coded to the value seen on Aarch64 (GRUB_PE32_PE64_MAGIC). Unfortunately, this code is shared between 64-bit and 32-bit, and so that value broke 32-bit Arm systems. This patch adds a constant definition for GRUB_PE32_PEXX_MAGIC, which is either GRUB_PE32_PE64_MAGIC or GRUB_PE32_PE32_MAGIC, depending on which platform is being built, and uses it in the header magic check. Resolves: rhbz#2000756 Signed-off-by: Peter Jones <[email protected]>

The commit 8b1e5d1 (fs/xfs: Add bigtime incompat feature support) introduced the bigtime support by adding some features in v3 inodes. This change extended grub_xfs_inode struct by 76 bytes but also changed the computation of XFS_V2_INODE_SIZE and XFS_V3_INODE_SIZE. Prior this commit, XFS_V2_INODE_SIZE was 100 bytes. After the commit it's 84 bytes XFS_V2_INODE_SIZE becomes 16 bytes too small. As a result, the data structures aren't properly aligned and the GRUB generates "attempt to read or write outside of partition" errors when trying to read the XFS filesystem: GNU GRUB version 2.11 .... grub> set debug=efi,gpt,xfs grub> insmod part_gpt grub> ls (hd0,gpt1)/ partmap/gpt.c:93: Read a valid GPT header partmap/gpt.c:115: GPT entry 0: start=4096, length=1953125 fs/xfs.c:931: Reading sb fs/xfs.c:270: Validating superblock fs/xfs.c:295: XFS v4 superblock detected fs/xfs.c:962: Reading root ino 128 fs/xfs.c:515: Reading inode (128) - 64, 0 fs/xfs.c:515: Reading inode (739521961424144223) - 344365866970255880, 3840 error: attempt to read or write outside of partition. This commit change the XFS_V2_INODE_SIZE computation by subtracting 76 bytes instead of 92 bytes from the actual size of grub_xfs_inode struct. This 76 bytes value comes from added members: 20 grub_uint8_t unused5 1 grub_uint64_t flags2 48 grub_uint8_t unused6 This patch explicitly splits the v2 and v3 parts of the structure. The unused4 is still ending of the v2 structures and the v3 starts at unused5. Thanks to this we will avoid future corruptions of v2 or v3 inodes. The XFS_V2_INODE_SIZE is returning to its expected size and the filesystem is back to a readable state: GNU GRUB version 2.11 .... grub> set debug=efi,gpt,xfs grub> insmod part_gpt grub> ls (hd0,gpt1)/ partmap/gpt.c:93: Read a valid GPT header partmap/gpt.c:115: GPT entry 0: start=4096, length=1953125 fs/xfs.c:931: Reading sb fs/xfs.c:270: Validating superblock fs/xfs.c:295: XFS v4 superblock detected fs/xfs.c:962: Reading root ino 128 fs/xfs.c:515: Reading inode (128) - 64, 0 fs/xfs.c:515: Reading inode (128) - 64, 0 fs/xfs.c:931: Reading sb fs/xfs.c:270: Validating superblock fs/xfs.c:295: XFS v4 superblock detected fs/xfs.c:962: Reading root ino 128 fs/xfs.c:515: Reading inode (128) - 64, 0 fs/xfs.c:515: Reading inode (128) - 64, 0 fs/xfs.c:515: Reading inode (128) - 64, 0 fs/xfs.c:515: Reading inode (131) - 64, 768 efi/ fs/xfs.c:515: Reading inode (3145856) - 1464904, 0 grub2/ fs/xfs.c:515: Reading inode (132) - 64, 1024 grub/ fs/xfs.c:515: Reading inode (139) - 64, 2816 grub> Fixes: 8b1e5d1 (fs/xfs: Add bigtime incompat feature support) Signed-off-by: Erwan Velu <[email protected]> Tested-by: Carlos Maiolino <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit a4b4955)

At the very least, this will make it easier to track down the problem module - or, if something else has gone wrong, provide more information for debugging. Signed-off-by: Robbie Harwood <[email protected]>

This was first reported under PFW but reproduces under SLOF. - The core.elf was 2126152 = 0x207148 bytes in size with the following program headers (per readelf): Entry point 0x200000 There are 4 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000160 0x00200000 0x00200000 0x21f98 0x2971c RWE 0x8 GNU_STACK 0x0220f8 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4 LOAD 0x0220f8 0x00232000 0x00232000 0x1e4e50 0x1e4e50 RWE 0x4 NOTE 0x206f48 0x00000000 0x00000000 0x00200 0x00000 R 0x4 - SLOF places the ELF file at 0x4000 (after the reserved space for interrupt handlers etc.) upwards. The image was 2126152 = 0x207148 bytes in size, so it runs from 0x4000 - 0x20b148. We'll call 0x4000 the load address. 0x0 0x4000 0x20b148 |----------|--------------| | reserved | ELF contents | - SLOF then copies the first LOAD program header (for .text). That runs for 0x21f98 bytes. It runs from (load addr + 0x160) to (load addr + 0x160 + 0x21f98) = 0x4160 to 0x260f8 and we copy it to 0x200000 to 0x221f98. This overwrites the end of the image: 0x0 0x4000 0x200000 0x221f98 |----------|------------|---------------| | reserved | ELF cont.. | .text section | - SLOF zeros the bss up to PhysAddr + MemSize = 0x22971c 0x0 0x4000 0x200000 0x221f98 0x22971c |----------|------------|---------------|--------| | reserved | ELF cont.. | .text section | bss 0s | - SLOF then goes to fulfil the next LOAD header (for mods), which is for 0x1e4e50 bytes. We copy from (load addr + 0x220f8) to (load addr + 0x220f8 + 0x1e4e50) = 0x260f8 to 0x20af48 and we copy it to 0x232000 to 0x416e50: 0x0 0x4000 0x200000 0x221f98 0x22971c |----------|------------|---------------|--------| | reserved | ELF cont.. | .text section | bss 0s | |-------------| | copied area | 0x260f8 0x20af48 This goes poorly: 0x0 0x4000 0x200000 0x221f98 0x22971c 0x232000 0x40bf08 0x416e50 |----------|------------|---------------|--------|-----|-----------|-------------| | reserved | ELF cont.. | .text section | bss 0s | pad | some mods | .text start | This matches the observations on the running system - 0x40bf08 was where the contents of memory no longer matched the contents of the ELF file. This was reported as a license verification failure on SLOF as the last module's .module_license section fell past where the corruption began. Signed-off-by: Daniel Axtens <[email protected]> [[email protected]: trim very detailed commit message] Signed-off-by: Robbie Harwood <[email protected]>

Since commit: ab2e53c grub-mkconfig: Honor a symlink when generating configuration by grub-mkconfig has inadvertently discarded umask for creating grub.cfg in the process of grub-mkconfig. The resulting wrong permission (0644) would allow unprivileged users to read grub's configuration file content. This presents a low confidentiality risk as grub.cfg may contain non-secured plain-text passwords. This patch restores the missing umask and set the file mode of creation to 0600 preventing unprivileged access. Fixes: CVE-2021-3981 Signed-off-by: Michael Chang <[email protected]> (cherry picked from commit 2acad06)

When using --no-floppy and a floppy was encountered, iterate_device() was returning 1, causing the iteration to stop instead of continuing. Signed-off-by: Renaud Métrich <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit 68ba54c) Signed-off-by: Robbie Harwood <[email protected]> (cherry picked from commit 7ada55e)

When using 'search' on EFI systems, we sometimes want to exclude devices that are not EFI disks (e.g. md, lvm). This is typically used when wanting to chainload when having a software raid (md) for EFI partition: with no option, 'search --file /EFI/redhat/shimx64.efi' sets root envvar to 'md/boot_efi' which cannot be used for chainloading since there is no effective EFI device behind. This commit also refactors handling of --no-floppy option. Signed-off-by: Renaud Métrich <[email protected]> [rharwood: apply rmetrich's flags initialization fix] Signed-off-by: Robbie Harwood <[email protected]> (cherry picked from commit fdd8396)

When efi.quickboot is enabled on VMWare (which is the default for hardware release 16 and later), it may happen that not all EFI devices are connected. Due to this, browsing the devices in make_devices() just fails to find devices, in particular disks or partitions for a given disk. This typically happens when network booting, then trying to chainload to local disk (this is used in deployment tools such as Red Hat Satellite), which is done through using the following grub.cfg snippet: -------- 8< ---------------- 8< ---------------- 8< -------- unset prefix search --file --set=prefix /EFI/redhat/grubx64.efi if [ -n "$prefix" ]; then chainloader ($prefix)/EFI/redhat/grubx64/efi ... -------- 8< ---------------- 8< ---------------- 8< -------- With efi.quickboot, none of the devices are connected, causing "search" to fail. Sometimes devices are connected but not the partition of the disk matching $prefix, causing partition to not be found by "chainloader". This patch introduces a new "connectefi pciroot|scsi" command which recursively connects all EFI devices starting from a given controller type: - if 'pciroot' is specified, recursion is performed for all PCI root handles - if 'scsi' is specified, recursion is performed for all SCSI I/O handles (recommended usage to avoid connecting unwanted handles which may impact Grub performances) Typical grub.cfg snippet would then be: -------- 8< ---------------- 8< ---------------- 8< -------- connectefi scsi unset prefix search --file --set=prefix /EFI/redhat/grubx64.efi if [ -n "$prefix" ]; then chainloader ($prefix)/EFI/redhat/grubx64/efi ... -------- 8< ---------------- 8< ---------------- 8< -------- The code is easily extensible to handle other arguments in the future if needed. Signed-off-by: Renaud Métrich <[email protected]> Signed-off-by: Robbie Harwood <[email protected]> (cherry picked from commit cc972c2)

I wrongly assumed that the most compatible way to perform CAS negotiation was to only set the minimum number of vectors required to ask for more memory. It turns out that this messes up booting if the minimum VP capacity would be less than the default 10% in vector 4. Linux configures the minimum capacity to be 1%, so copy it for that and for vector 3 which we now need to specify as well. Signed-off-by: Daniel Axtens <[email protected]> (cherry picked from commit e6f02ad)

Frustratingly, the device name itself can contain an embedded comma: e.g /pci@800000020000015/pci1014,034A@0/sas/disk@5000c50098a0ee8b So my previous approach was wrong: we cannot rely upon the presence of a comma to say that a partition has been specified! It turns out for prefixes like (,gpt2)/grub2 we really want to make up a full (device,partition)/patch prefix, because root discovery code in 10_linux will reset the root variable and use search to fill it again. If you have run grub-install, you probably don't have search built in, and if you don't have prefix containing (device,partition), grub will construct ($root)$prefix/powerpc-ieee1275/search.mod - but because $root has just been changed, this will no longer work, and the boot will fail! Retain the gist of the logic, but instead of looking for a comma, look for a leading '('. This matches the earlier code better anyway. There's certainly a better fix to be had. But any time you chose to build with a bare prefix like '/grub2', you're almost certainly going to build in search anyway, so this will do. Signed-off-by: Daniel Axtens <[email protected]> (cherry picked from commit 80b6eb5)

Add support for trusted boot using a vTPM 2.0 on the IBM IEEE1275 PowerPC platform. With this patch grub now measures text and binary data into the TPM's PCRs 8 and 9 in the same way as the x86_64 platform does. This patch requires Daniel Axtens's patches for claiming more memory. For vTPM support to work on PowerVM, system driver levels 1010.30 or 1020.00 are required. Note: Previous versions of firmware levels with the 2hash-ext-log API call have a bug that, once this API call is invoked, has the effect of disabling the vTPM driver under Linux causing an error message to be displayed in the Linux kernel log. Those users will have to update their machines to the firmware levels mentioned above. Cc: Eric Snowberg <[email protected]> Signed-off-by: Stefan Berger <[email protected]> (cherry picked from commit d3e5a8e)

The feature Retry on Fail added to GRUB can cause a LPM to take longer if the SAN is slow. When a LPM to external site occur, the path of the disk can change and thus the disk search function on grub can take some time since it is used as a hint. This can cause the Retry on Fail feature to try to access the disk 20x times (since this is hardcoded number) and, if the SAN is slow, the boot time can increase a lot. In some situations not acceptable. The following patch enables a configuration at user space of the maximum number of retries we want for this feature. The variable ofdisk_retries should be set using grub2-editenv and will be checked by retry function. If the variable is not set, so the default number of retries will be used instead. (cherry picked from commit 4c5c756)

grub_load_and_start_image only loads an image - it still requires the caller to start it. This renames it to grub_load_image. It's called from 2 places: - grub_cmd_chainloader when not using the shim protocol. - grub_secureboot_chainloader_boot if handle_image returns an error. In this case, the image is loaded and then nothing else happens which seems strange. I assume the intention is that it falls back to LoadImage and StartImage if handle_image fails, so I've made it do that. Signed-off-by: Chris Coulson <[email protected]> (cherry picked from commit b4d70820a65c00561045856b7b8355461a9545f6) (cherry picked from commit 05b16a6be50b1910609740a66b561276fa490538)

When not using the shim lock protocol, the chainloader command retains the source buffer and device path passed to LoadImage, requiring the unload hook passed to grub_loader_set to free them. It isn't required to retain this state though - they aren't required by StartImage or anything else in the boot hook, so clean them up before grub_cmd_chainloader finishes. This also wraps the loader state when using the shim lock protocol inside a struct. Signed-off-by: Chris Coulson <[email protected]> (cherry picked from commit fa39862933b3be1553a580a3a5c28073257d8046) (cherry picked from commit 0333343ee99c4e88f062789263c94291c057251b) [rharwood: double-frees and uninitialized, verifying twice] Signed-off-by: Robbie Harwood <[email protected]>

Loaders rely on global variables for saving context which is consumed in the boot hook and freed in the unload hook. In the case where a loader command is executed twice, calling grub_loader_set a second time executes the unload hook, but in some cases this runs when the loader's global context has already been updated, resulting in the updated context being freed and potential use-after-free bugs when the boot hook is subsequently called. This adds a new API (grub_loader_set_ex) which allows a loader to specify context that is passed to its boot and unload hooks. This is an alternative to requiring that loaders call grub_loader_unset before mutating their global context. Signed-off-by: Chris Coulson <[email protected]> (cherry picked from commit 4322a64dde7e8fedb58e50b79408667129d45dd3) (cherry picked from commit 937ad0e2159b6b8cb0d2ce3515da3a8b797c7927)

This ports the EFI chainloader to use grub_loader_set_ex in order to fix a use-after-free bug that occurs when grub_cmd_chainloader is executed more than once before a boot attempt is performed. Signed-off-by: Chris Coulson <[email protected]> (cherry picked from commit 4b7f0402b7cb0f67a93be736f2b75b818d7f44c9) (cherry picked from commit fc1a79bf0e0bc019362ace46d908a92b48dcd55b) [rharwood: context sludge from previous commit] Signed-off-by: Robbie Harwood <[email protected]>

In some error paths in grub_cmd_linux, the pointer to lh may be dereferenced after the buffer it points to has been freed. There aren't any security implications from this because nothing else uses the allocator after the buffer is freed and before the pointer is dereferenced, but fix it anyway. Signed-off-by: Chris Coulson <[email protected]> (cherry picked from commit 8224f5a71af94bec8697de17e7e579792db9f9e2) (cherry picked from commit 4744b62e20d07674017213ac54d7442d679f9d1a)

This ports the linuxefi loader to use grub_loader_set_ex in order to fix a use-after-fre bug that occurs when grub_cmd_linux is executed more than once before a boot attempt is performed. This is more complicated than for the chainloader command, as the initrd command needs access to the loader state. To solve this, the linuxefi module registers a dummy initrd command at startup that returns an error. The linuxefi command then registers a proper initrd command with a higher priority that is passed the loader state. Signed-off-by: Chris Coulson <[email protected]> (cherry picked from commit 7cf736436b4c934df5ddfa6f44b46a7e07d99fdc) [rharwood/pjones: set kernel_size in context] (cherry picked from commit 9c056391f7a36ea480de9a759c12e55a90f2040a) [rharwood: verifying twice] Signed-off-by: Robbie Harwood <[email protected]>

Subsequent invocations of the initrd command result in the previous initrd being leaked, so fix that. Signed-off-by: Chris Coulson <[email protected]> (cherry picked from commit d98af31ce1e31bb22163960d53f5eb28c66582a0) (cherry picked from commit 62234d6a00e6d1dd8e017ff161d359feb5234082)

We must not allow other verifiers to pass things like the GRUB modules. Instead of maintaining a blocklist, maintain an allowlist of things that we do not care about. This allowlist really should be made reusable, and shared by the lockdown verifier, but this is the minimal patch addressing security concerns where the TPM verifier was able to mark modules as verified (or the OpenPGP verifier for that matter), when it should not do so on shim-powered secure boot systems. Fixes: CVE-2022-28735 Signed-off-by: Julian Andres Klode <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit fa61ad69861c1cb3f68bf853d78fae7fd93986a0) (cherry picked from commit f418191e01b38a635319a26925cf345523d4440c)

If we have an error in grub_file_open() before we free device_name, we will leak it. Free device_name in the error path and null out the pointer in the good path once we free it there. Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit 1499a5068839fa37cb77ecef4b5bdacbd1ed12ea) (cherry picked from commit 2ec50b289d8b24922433439533113087f111f110)

Fuzzing revealed some inputs that were taking a long time, potentially forever, because they did not bail quickly upon encountering an I/O error. Try to catch I/O errors sooner and bail out. Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit 882be97d1df6449b9fd4d593f0cb70005fde3494) (cherry picked from commit 3f6fc3ebfd58fcdb3fe6c2f7a5a4fa05772ae786)

This causes the bitmap to be leaked. Do not permit multiple image headers. Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit 8ce433557adeadbc46429aabb9f850b02ad2bdfb) (cherry picked from commit 6e10bba6a4cbfd6c7bf116f41fd4e037465e19d8)

…rite A 16-bit greyscale PNG without alpha is processed in the following loop: for (i = 0; i < (data->image_width * data->image_height); i++, d1 += 4, d2 += 2) { d1[R3] = d2[1]; d1[G3] = d2[1]; d1[B3] = d2[1]; } The increment of d1 is wrong. d1 is incremented by 4 bytes per iteration, but there are only 3 bytes allocated for storage. This means that image data will overwrite somewhat-attacker-controlled parts of memory - 3 bytes out of every 4 following the end of the image. This has existed since greyscale support was added in 2013 in commit 3ccf16d (grub-core/video/readers/png.c: Support grayscale). Saving starfield.png as a 16-bit greyscale image without alpha in the gimp and attempting to load it causes grub-emu to crash - I don't think this code has ever worked. Delete all PNG greyscale support. Fixes: CVE-2021-3695 Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit 0e1d163382669bd734439d8864ee969616d971d9) [rharwood: context conflict] Signed-off-by: Robbie Harwood <[email protected]> (cherry picked from commit 4c631c8119206b3178912df2905434d967661c3d)

In fuzzing we observed crashes where a code would attempt to be inserted into a huffman table before the start, leading to a set of heap OOB reads and writes as table entries with negative indices were shifted around and the new code written in. Catch the case where we would underflow the array and bail. Fixes: CVE-2021-3696 Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit 1ae9a91d42cb40da8a6f11fac65541858e340afa) (cherry picked from commit 132ccc681cf642ad748580f26b54c9259a7f43fd)

ASAN picked up two OOB global reads: we weren't checking if some code values fit within the cplens or cpdext arrays. Check and throw an error if not. Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit c3a8ab0cbd24153ec7b1f84a96ddfdd72ef8d117) (cherry picked from commit 5d09addf58086aa11d5f9a91af5632ff87c2d2ee)

Fuzzing revealed some inputs that were taking a long time, potentially forever, because they did not bail quickly upon encountering an I/O error. Try to catch I/O errors sooner and bail out. Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit ab2e5d2e4bff488bbb557ed435a61ae102ef9f0c) (cherry picked from commit 1ff8df0d2dea8ec7c8575241d5e7d6622c204ec3)

Fix a memory leak where an invalid file could cause us to reallocate memory for a huffman table we had already allocated memory for. Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit bc06e12b4de55cc6f926af9f064170c82b1403e9) (cherry picked from commit 5298bf758ea39a90537f9a1c76541ff2f21b970b)

An invalid file could contain multiple start of stream blocks, which would cause us to reallocate and leak our bitmap. Refuse to handle multiple start of streams. Additionally, fix a grub_error() call formatting. Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit f3a854def3e281b7ad4bbea730cd3046de1da52f) (cherry picked from commit db0154828989a0a52ee59a4dda8c3803752bc827)

Certain 1 px wide images caused a wild pointer write in grub_jpeg_ycrcb_to_rgb(). This was caused because in grub_jpeg_decode_data(), we have the following loop: for (; data->r1 < nr1 && (!data->dri || rst); data->r1++, data->bitmap_ptr += (vb * data->image_width - hb * nc1) * 3) We did not check if vb * width >= hb * nc1. On a 64-bit platform, if that turns out to be negative, it will underflow, be interpreted as unsigned 64-bit, then be added to the 64-bit pointer, so we see data->bitmap_ptr jump, e.g.: 0x6180_0000_0480 to 0x6181_0000_0498 ^ ~--- carry has occurred and this pointer is now far away from any object. On a 32-bit platform, it will decrement the pointer, creating a pointer that won't crash but will overwrite random data. Catch the underflow and error out. Fixes: CVE-2021-3697 Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit 41aeb2004db9924fecd9f2dd64bc2a5a5594a4b5) (cherry picked from commit 5f9582490792108306d047379fed2371bee286f8)

In some cases attempting to display arbitrary binary strings leads to ASAN splats reading the widthspec array out of bounds. Check the index. If it would be out of bounds, return a width of 1. I don't know if that's strictly correct, but we're not really expecting great display of arbitrary binary data, and it's certainly not worse than an OOB read. Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit fdf32abc7a3928852422c0f291d8cd1dd6b34a8d) (cherry picked from commit f2c10aaf335b88a69885375c4d68ffab2429df77)

A netbuff shouldn't be too huge. It's bounded by MTU and TCP segment reassembly. This helps avoid some bugs (and provides a spot to instrument to catch them at their source). Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit ee9591103004cd13b4efadda671536090ca7fd57) (cherry picked from commit acde668bb9d9fa862a1a63e3bbd5fa47fdfa9183)

This avoids an underflow and subsequent unpleasantness. Fixes: CVE-2022-28733 Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit eb74e5743ca7e18a5e75c392fe0b21d1549a1936) (cherry picked from commit 552ad34583e788542e9ca08524a0d4bc8f98c297)

grub_net_dns_lookup() takes as inputs a pointer to an array of addresses ("addresses") for the given name, and pointer to a number of addresses ("naddresses"). grub_net_dns_lookup() is responsible for allocating "addresses", and the caller is responsible for freeing it if "naddresses" > 0. The DNS recv_hook will sometimes set and free the addresses array, for example if the packet is too short: if (ptr + 10 >= nb->tail) { if (!*data->naddresses) grub_free (*data->addresses); grub_netbuff_free (nb); return GRUB_ERR_NONE; } Later on the nslookup command code unconditionally frees the "addresses" array. Normally this is fine: the array is either populated with valid data or is NULL. But in these sorts of error cases it is neither NULL nor valid and we get a double-free. Only free "addresses" if "naddresses" > 0. It looks like the other use of grub_net_dns_lookup() is not affected. Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit eb2e69fcf51307757e43f55ee8c9354d1ee42dd1) (cherry picked from commit d801a27e7acec6c1a83067fab0bb975877eaf704)

I don't really understand what's going on here but fuzzing found a bug where we read past the end of check_with. That's a C string, so use grub_strlen() to make sure we don't overread it. Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit 6a97b3f4b1d5173aa516edc6dedbc63de7306d21) (cherry picked from commit e0589624e86bc96666cbdb62f6e55cafec2871b3)

A malicious tftp server can cause UAFs and a double free. An attempt to read from a network file is handled by grub_net_fs_read(). If the read is at an offset other than the current offset, grub_net_seek_real() is invoked. In grub_net_seek_real(), if a backwards seek cannot be satisfied from the currently received packets, and the underlying transport does not provide a seek method, then grub_net_seek_real() will close and reopen the network protocol layer. For tftp, the ->close() call goes to tftp_close() and frees the tftp_data_t file->data. The file->data pointer is not nulled out after the free. If the ->open() call fails, the file->data will not be reallocated and will continue point to a freed memory block. This could happen from a server refusing to send the requisite ack to the new tftp request, for example. The seek and the read will then fail, but the grub_file continues to exist: the failed seek does not necessarily cause the entire file to be thrown away (e.g. where the file is checked to see if it is gzipped/lzio/xz/etc., a read failure is interpreted as a decompressor passing on the file, not as an invalidation of the entire grub_file_t structure). This means subsequent attempts to read or seek the file will use the old file->data after free. Eventually, the file will be close()d again and file->data will be freed again. Mark a net_fs file that doesn't reopen as broken. Do not permit read() or close() on a broken file (seek is not exposed directly to the file API - it is only called as part of read, so this blocks seeks as well). As an additional defence, null out the ->data pointer if tftp_open() fails. That would have lead to a simple null pointer dereference rather than a mess of UAFs. This may affect other protocols, I haven't checked. Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit dada1dda695439bb55b2848dddc2d89843552f81) (cherry picked from commit 352c5ae8a9fc715712e6ecbd7ccb6218122c748f)

Under tftp errors, we print a tftp error message from the tftp header. However, the tftph pointer is a pointer inside nb, the netbuff. Previously, we were freeing the nb and then dereferencing it. Don't do that, use it and then free it later. This isn't really _bad_ per se, especially as we're single-threaded, but it trips up fuzzers. Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit 956f4329cec23e4375182030ca9b2be631a61ba5) (cherry picked from commit dbe9abcdee6ce796811111b67e3f24eefe2135d1)

It's possible for data->sock to get torn down in tcp error handling. If we unconditionally tear it down again we will end up doing writes to an offset of the NULL pointer when we go to tear it down again. Detect if it has been torn down and don't do it again. Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit ec233d3ecf995293304de443579aab5c46c49e85) (cherry picked from commit d39cf87ed701b9f0900daed7f672e07994d37ce8)

GRUB has special code for handling an http header that is split across two packets. The code tracks the end of line by looking for a "\n" byte. The code for split headers has always advanced the pointer just past the end of the line, whereas the code that handles unsplit headers does not advance the pointer. This extra advance causes the length to be one greater, which breaks an assumption in parse_line(), leading to it writing a NUL byte one byte past the end of the buffer where we reconstruct the line from the two packets. It's conceivable that an attacker controlled set of packets could cause this to zero out the first byte of the "next" pointer of the grub_mm_region structure following the current_line buffer. Do not advance the pointer in the split header case. Fixes: CVE-2022-28734 Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit e9fb459638811c12b0989dbf64e3e124974ef617) (cherry picked from commit b604916beb6c39e8ed27f72851eb16f3eaa293c5)

In a similar vein to the previous patch, parse_line() would write a NUL byte past the end of the buffer if there was an HTTP header with a LF rather than a CRLF. RFC-2616 says: Many HTTP/1.1 header field values consist of words separated by LWS or special characters. These special characters MUST be in a quoted string to be used within a parameter value (as defined in section 3.6). We don't support quoted sections or continuation lines, etc. If we see an LF that's not part of a CRLF, bail out. Fixes: CVE-2022-28734 Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit d232ad41ac4979a9de4d746e5fdff9caf0e303de) (cherry picked from commit 8960e6d6137090a7e8c6592077da6e387a4ef972)

A corrupt f2fs file system could specify a nat journal entry count that is beyond the maximum NAT_JOURNAL_ENTRIES. Check if the specified nat journal entry count before accessing the array, and throw an error if it is too large. Signed-off-by: Sudhakar Kuppusamy <[email protected]> Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit a3988cb3f0a108dd67ac127a79a4c8479d23334e) (cherry picked from commit 7125978aa7d6068812ef6da0ab38ce521ae7eba1)

A corrupt f2fs filesystem could have a block offset or a bitmap offset that would cause us to read beyond the bounds of the nat bitmap. Introduce the nat_bitmap_size member in grub_f2fs_data which holds the size of nat bitmap. Set the size when loading the nat bitmap in nat_bitmap_ptr(), and catch when an invalid offset would create a pointer past the end of the allocated space. Check against the bitmap size in grub_f2fs_test_bit() test bit to avoid reading past the end of the nat bitmap. Signed-off-by: Sudhakar Kuppusamy <[email protected]> Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit 62d63d5e38c67a6e349148bf7cb87c560e935a7e) (cherry picked from commit 92219e6d379b5b4d30b05361830b72ab1d95d281)

A corrupt f2fs file system might specify a name length which is greater than the maximum name length supported by the GRUB f2fs driver. We will allocate enough memory to store the overly long name, but there are only F2FS_NAME_LEN bytes in the source, so we would read past the end of the source. While checking directory entries, do not copy a file name with an invalid length. Signed-off-by: Sudhakar Kuppusamy <[email protected]> Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit 9a891f638509e031d322c94e3cbcf38d36f3993a) (cherry picked from commit 13f9160ae0d2806baed459884999356817096cd7)

According to the btrfs code in Linux, the structure of a directory item leaf should be of the form: |struct btrfs_dir_item|name|data| in GRUB the name len and data len are in the grub_btrfs_dir_item structure's n and m fields respectively. The combined size of the structure, name and data should be less than the allocated memory, a difference to the Linux kernel's struct btrfs_dir_item is that the grub_btrfs_dir_item has an extra field for where the name is stored, so we adjust for that too. Signed-off-by: Darren Kenny <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit 6d3f06c0b6a8992b9b1bb0e62af93ac5ff2781f0) [rharwood: we've an extra variable here] Signed-off-by: Robbie Harwood <[email protected]> (cherry picked from commit e3e21b9a81aea09dd43368cf097c1029a8380d82)

The fuzzer is generating btrfs file systems that have chunks with invalid combinations of stripes and substripes for the given RAID configurations. After examining the Linux kernel fs/btrfs/tree-checker.c code, it appears that sub-stripes should only be applied to RAID10, and in that case there should only ever be 2 of them. Similarly, RAID single should only have 1 stripe, and RAID1/1C3/1C4 should have 2. 3 or 4 stripes respectively, which is what redundancy corresponds. Some of the chunks ended up with a size of 0, which grub_malloc() still returned memory for and in turn generated ASAN errors later when accessed. While it would be possible to specifically limit the number of stripes, a more correct test was on the combination of the chunk item, and the number of stripes by the size of the chunk stripe structure in comparison to the size of the chunk itself. Signed-off-by: Darren Kenny <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit 3849647b4b98a4419366708fc4b7f339c6f55ec7) (cherry picked from commit fa5a02a8930bbd8a3b5ae6ed9612307611f18500)

The corpus we generating issues in grub_btrfs_read_logical() when attempting to iterate over nstripes entries in the boot mapping. In most cases the reason for the failure was that the number of strips exceeded the possible space statically allocated in superblock bootmapping space. Each stripe entry in the bootmapping block consists of a grub_btrfs_key followed by a grub_btrfs_chunk_stripe. Another issue that came up was that while calculating the chunk size, in an earlier piece of code in that function, depending on the data provided in the btrfs file system, it would end up calculating a size that was too small to contain even 1 grub_btrfs_chunk_item, which is obviously invalid too. Signed-off-by: Darren Kenny <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit e00cd76cbadcc897a9cc4087cb2fcb5dbe15e596) (cherry picked from commit b74a6fc95b0839937acf4f2b7445ae9d179f49ec)

grub_min(a,b) and grub_max(a,b) use a relatively naive implementation which leads to several problems: - they evaluate their parameters more than once - the naive way to address this, to declare temporary variables in a statement-expression, isn't resilient against nested uses, because MIN(a,MIN(b,c)) results in the temporary variables being declared in two nested scopes, which may result in a build warning depending on your build options. This patch changes our implementation to use a statement-expression inside a helper macro, and creates the symbols for the temporary variables with __COUNTER__ (A GNU C cpp extension) and token pasting to create uniquely named internal variables. Signed-off-by: Peter Jones <[email protected]> (cherry picked from commit 2d6800450fa731d7b3ef9893986806e88e819eb6)

This is a minor cleanup patch to remove the bespoke MIN() and MAX() definitions from the reiserfs driver, and uses grub_min() / grub_max() instead. Signed-off-by: Peter Jones <[email protected]> (cherry picked from commit 5fc601574fce99b32fe4dfb55bd8f3ab0175fd6a)

Currently grub_boot_time() includes valuable debugging messages, but if you build without BOOT_TIME_STATS enabled, they are silently and confusingly compiled away. This patch changes grub_boot_time() to also log when "boot" is enabled in DEBUG, regardless of BOOT_TIME_STATS. Signed-off-by: Peter Jones <[email protected]> (cherry picked from commit 4fd282de00df05ce289467861deb7a0e186cfbd7)

Currently .module_license is set writable (that is, the section has the SHF_WRITE flag set) in the module's ELF headers. This probably never actually matters, but it can't possibly be correct. This patch sets that data as "const", which causes that flag not to be set. Signed-off-by: Peter Jones <[email protected]> (cherry picked from commit 2eff3e2c9d9e6b75daa81b840c96f112ef7d5de6)

Currently grub modules built with clang or gcc have several sections which we don't actually need or support. We already have a list of section to skip in genmod.sh, and this patch adds the following sections to that list (as well as a few newlines): .note.gnu.property .llvm* Note that the glob there won't work without a new enough linker, but the failure is just reversion to the status quo, so that's not a big problem. Signed-off-by: Peter Jones <[email protected]> (cherry picked from commit e85d1c4d795f8135ad0acfa36d64760d12d6fed1)

Currently when loading grub modules, we allocate space for all sections, including those without SHF_ALLOC set. We then copy the sections that /do/ have SHF_ALLOC set into the allocated memory, leaving some of our allocation untouched forever. Additionally, on platforms with GOT fixups and trampolines, we currently compute alignment round-ups for the sections and sections with sh_size = 0. This patch removes the extra space from the allocation computation, and makes the allocation computation loop skip empty sections as the loading loop does. Signed-off-by: Peter Jones <[email protected]> (cherry picked from commit 03215e342f552396ab08125ea769b1e166417ec1)

In order to properly validate a loaded kernel's support for being loaded without a writable stack or executable, we need to be able to properly parse arbitrary PE headers. Currently, pe32.h is written in such a way that the MS-DOS header that tells us where to find the PE header in the binary can't be accessed. Further, for some reason it calls the DOS MZ magic "GRUB_PE32_MAGIC". This patch adds the structure for the DOS header, renames the DOS magic define, and adds defines for the actual PE magic. Signed-off-by: Peter Jones <[email protected]> (cherry picked from commit 955f47aa8300387eecf18b0866d21dde7720593d)

…ER_DATA. On some of the firmwares with more security mitigations, EFI_LOADER_DATA doesn't get you executable memory, and we take a fault and reboot when we enter kernel. This patch correctly allocates the kernel code as EFI_RUNTIME_SERVICES_CODE rather than EFI_LOADER_DATA. Signed-off-by: Peter Jones <[email protected]> [rharwood: use kernel_size] Signed-off-by: Robbie Harwood <[email protected]> (cherry picked from commit 8b31058a12d3e85f0f0180ac90b98d6465fccbb7)

Currently we load module sections at whatever alignment gcc+ld happened to dump into the ELF section header, which is often pretty useless. For example, by default time.mod has these sections on a current x86_64 build: $ eu-readelf -a grub-core/time.mod |& grep ^Section -A13 Section Headers: [Nr] Name Type Addr Off Size ES Flags Lk Inf Al [ 0] NULL 0 00000000 00000000 0 0 0 0 [ 1] .text PROGBITS 0 00000040 0000015e 0 AX 0 0 1 [ 2] .rela.text RELA 0 00000458 000001e0 24 I 8 1 8 [ 3] .rodata.str1.1 PROGBITS 0 0000019e 000000a1 1 AMS 0 0 1 [ 4] .module_license PROGBITS 0 00000240 0000000f 0 A 0 0 8 [ 5] .data PROGBITS 0 0000024f 00000000 0 WA 0 0 1 [ 6] .bss NOBITS 0 00000250 00000008 0 WA 0 0 8 [ 7] .modname PROGBITS 0 00000250 00000005 0 0 0 1 [ 8] .symtab SYMTAB 0 00000258 00000150 24 9 6 8 [ 9] .strtab STRTAB 0 000003a8 000000ab 0 0 0 1 [10] .shstrtab STRTAB 0 00000638 00000059 0 0 0 1 With NX protections being page based, loading sections with either a 1 or 8 *byte* alignment does absolutely nothing to help us out. This patch switches most EFI platforms to load module sections at 4kB page-aligned addresses. To do so, it adds an new per-arch function, grub_arch_dl_min_alignment(), which returns the alignment needed for dynamically loaded sections (in bytes). Currently it sets it to 4096 when GRUB_MACHINE_EFI is true on x86_64, i386, arm, arm64, and emu, and 1-byte alignment on everything else. It then changes the allocation size computation and the loader code in grub_dl_load_segments() to align the locations and sizes up to these boundaries, and fills any added padding with zeros. All of this happens before relocations are applied, so the relocations factor that in with no change. As an aside, initially Daniel Kiper and I thought that it might be a better idea to split the modules up into top-level sections as .text.modules, .rodata.modules, .data.modules, etc., so that their page permissions would get set by the loader that's loading grub itself. This turns out to have two significant downsides: 1) either in mkimage or in grub_dl_relocate_symbols(), you wind up having to dynamically process the relocations to accommodate the moved module sections, and 2) you then need to change the permissions on the modules and change them back while relocating them in grub_dl_relocate_symbols(), which means that any loader that /does/ honor the section flags but does /not/ generally support NX with the memory attributes API will cause grub to fail. Signed-off-by: Peter Jones <[email protected]> (cherry picked from commit 31d52500b281619d92b03b2c2d30fe15aedaf326)

For NX, we need to set the page access permission attributes for write and execute permissions. This patch adds two new primitives, grub_set_mem_attrs() and grub_clear_mem_attrs(), and associated constant definitions, to be used for that purpose. For most platforms, it adds a dummy implementation that returns GRUB_ERR_NONE. On EFI platforms, it adds a common helper function, grub_efi_status_to_err(), which translates EFI error codes to grub error codes, adds headers for the EFI Memory Attribute Protocol (still pending standardization), and an implementation of the grub nx primitives using it. Signed-off-by: Peter Jones <[email protected]> [rharwood: add pjones's none/nyi fixup] Signed-off-by: Robbie Harwood <[email protected]> (cherry picked from commit 35de78a8d32b9fad5291ec96fd3cbb9cf2f4a80b)

For NX, we need to set write and executable permissions on the sections of grub modules when we load them. On sections with SHF_ALLOC set, which is typically everything except .modname and the symbol and string tables, this patch clears the Read Only flag on sections that have the ELF flag SHF_WRITE set, and clears the No eXecute flag on sections with SHF_EXECINSTR set. In all other cases it sets both flags. Signed-off-by: Peter Jones <[email protected]> [rharwood: arm tgptr -> tgaddr] Signed-off-by: Robbie Harwood <[email protected]> (cherry-picked from commit ca74904ede0406b594cbedc52ce8e38a6633d2ae)

For NX, our kernel loaders need to set write and execute page permissions on allocated pages and the stack. This patch adds those calls. Signed-off-by: Peter Jones <[email protected]> [rharwood: fix aarch64 callsites] (cherry-picked from commit a9f79a997f01a83b36cdfa89ef2e72ac2a17c06c) [rharwood: uninitialized stack_attrs, double verification] Signed-off-by: Robbie Harwood <[email protected]>

For NX, we need the grub binary to announce that it is compatible with the NX feature. This implies that when loading the executable grub image, several attributes are true: - the binary doesn't need an executable stack - the binary doesn't need sections to be both executable and writable - the binary knows how to use the EFI Memory Attributes protocol on code it is loading. This patch adds a definition for the PE DLL Characteristics flag GRUB_PE32_NX_COMPAT, and changes grub-mkimage to set that flag. Signed-off-by: Peter Jones <[email protected]> (cherry picked from commit 0c7f1aed5a87f75051b421903a900ccb4bbd795a)

If one of the file filters breaks things, it's hard to figure out where it has happened. This makes grub log which filter is being run, which makes it easier to figure out where you are in the sequence of events. Signed-off-by: Peter Jones <[email protected]> (cherry picked from commit d3d6518)

Currently when populating the initial memory arena on EFI systems, we count the available regions below GRUB_EFI_MAX_ALLOCATION_ADDRESS from the EFI memory map and then allocates one quarter of that for our arena. Because many systems come up without IOMMUs, we currently set GRUB_EFI_MAX_ALLOCATION_ADDRESS to 0x7fffffff, i.e. all addresses allocated must be below 2G[0]. Due to firmware and other considerations, this makes the most memory we can possibly have in our arena 512M. Because our EFI loader doesn't get kernel and initrd memory from grub's allocator, but rather reserves it directly from UEFI and then simply marks those as allocated if they're within grub's arena, it was historically possible to have initrds that are larger than 512M, because we could use any memory region below 4G, without concern for grub's choice of arena size. Unfortunately, when we switched to using the "verifiers" API (and thus the file_filter_t API) to do measurement of kernel and initrd, this introduced a pattern that allocates the entire file when we call grub_file_open(), and buffers it to pass to the filter. This results in needing to have enough space for the initramfs in the grub arena. This is bad. Since it's unlikely you're going to do anything *other* than loading a kernel and initramfs that takes much of the available free memory from UEFI, this patch introduces a workaround by changing the amount we give to the arena be three quarters of the available memory, rather than one quarter, thus changing our theoretical initrd limit to 1.5G. In practice, it may still be smaller than that depending on allocation fragmentation, but generally it will be most of it. Note that this doesn't fix the underlying flaw, which is that there is no safe way to do the validation correctly using the "verifiers" system with the current file API without buffering the whole file before grub_file_read() is ever called, and thus you can't set an allocation policy for the initial buffer of the file at all, so unless we raise the allocation limit to >4G, it can't be allocated in the big region. [0] I'm not sure there was a good reason not to pick 4G, but even if we had, at least one common firmware routes the first 2G of physical RAM to 0x0, and any additional memory starting at 0x100000000. Related: rhbz#2112134 Signed-off-by: Peter Jones <[email protected]> (cherry picked from commit 005a0aa)

In our kernel allocator on EFI systems, we currently have a growing amount of code that references the various allocation policies by position in the array, and of course maintenance of this code scales very poorly. This patch changes them to be enumerated, so they're easier to refer to farther along in the code without confusion. Signed-off-by: Peter Jones <[email protected]> (cherry picked from commit 6768026)

Currently in our kernel allocator, we use the same set of choices for all of our various kernel and initramfs allocations, though they do not have exactly the same constraints. This patch adds the concept of an allocation purpose, which currently can be KERNEL_MEM or INITRD_MEM, and updates kernel_alloc() calls appropriately, but does not change any current policy decision. It also adds a few debug prints. Signed-off-by: Peter Jones <[email protected]> (cherry picked from commit 36307be)

Currently on x86, only linux kernels built with CONFIG_RELOCATABLE for x86_64 can be loaded above 4G, but the maximum address for the initramfs is specified via a HdrS field. This allows us to utilize that value, and unless loading the kernel above 4G, uses the value present there. If loading kernel above 4G is allowed, we assume loading the initramfs above 4G also works; in practice this has been true in the kernel code for quite some time. Resolves: rhbz#2112134 Signed-off-by: Peter Jones <[email protected]> (cherry picked from commit 3e08c35)

At some point due to an erroneous kernel warning, we switched kernel and initramfs to being loaded in EFI_RUNTIME_SERVICES_CODE and EFI_RUNTIME_SERVICES_DATA memory pools. This doesn't appear to be correct according to the spec, and that kernel warning has gone away. This patch puts them back in EFI_LOADER_CODE and EFI_LOADER_DATA allocations, respectively. Resolves: rhbz#2108456 Signed-off-by: Peter Jones <[email protected]> (cherry picked from commit 35b5d5f)

Signed-off-by: Robbie Harwood <[email protected]> (cherry picked from commit 0837dcd)

As a legacy support, if the vector 5 is not implemented, Power Hypervisor will consider the max CPUs as 64 instead 256 currently supported during client-architecture-support negotiation. This patch implements the vector 5 and set the MAX CPUs to 256 while setting the others values to 0 (default). Signed-off-by: Diego Domingos <[email protected]> Signed-off-by: Robbie Harwood <[email protected]> (cherry picked from commit f735c65)

Signed-off-by: Robbie Harwood <[email protected]> (cherry picked from commit 275a048)

Signed-off-by: Robbie Harwood <[email protected]> (cherry picked from commit 12354f5)

On OSTree systems, `grub2-mkconfig` is run with `/etc` mounted read-only because as part of the promise of transactional updates, we want to make sure that we're not modifying the current deployment's state (`/etc` or `/var`). This conflicts with 0837dcd ("BLS: create /etc/kernel/cmdline during mkconfig") which wants to write to `/etc/kernel/cmdline`. I'm not exactly sure on the background there, but based on the comment I think the intent is to fulfill grubby's expectation that the file exists. However, in systems like Silverblue, kernel arguments are managed by the rpm-ostree stack and grubby is not shipped at all. Adjust the script slightly so that we only write `/etc/kernel/cmdline` if the parent directory is writable. In the future, we're hoping to simplify things further on rpm-ostree systems by not running `grub2-mkconfig` at all since libostree already directly writes BLS entries. Doing that would also have avoided this, but ratcheting it into existing systems needs more careful thought. Signed-off-by: Jonathan Lebon <[email protected]> Fixes: fedora-silverblue/issue-tracker#322 (cherry picked from commit 3c3d1a3)

This reverts commit 98b6e23.

When efi.quickboot is enabled on VMWare (which is the default for hardware release 16 and later), it may happen that not all EFI devices are connected. Due to this, browsing the devices in make_devices() just fails to find devices, in particular disks or partitions for a given disk. This typically happens when network booting, then trying to chainload to local disk (this is used in deployment tools such as Red Hat Satellite), which is done through using the following grub.cfg snippet: -------- 8< ---------------- 8< ---------------- 8< -------- unset prefix search --file --set=prefix /EFI/redhat/grubx64.efi if [ -n "$prefix" ]; then chainloader ($prefix)/EFI/redhat/grubx64/efi ... -------- 8< ---------------- 8< ---------------- 8< -------- With efi.quickboot, none of the devices are connected, causing "search" to fail. Sometimes devices are connected but not the partition of the disk matching $prefix, causing partition to not be found by "chainloader". This patch introduces a new "eficonnect pciroot|scsi|all" command whic recursively connects all EFI devices starting from a given controller type: - if 'pciroot' is specified, recursion is performed for all PCI root handles - if 'scsi' is specified, recursion is performed for all SCSI I/O handles (recommended usage to avoid connecting unwanted handles which may impact Grub performances) - if 'all' is specified, recursion is performed on all handles (not recommended since it may heavily impact Grub performances) Typical grub.cfg snippet would then be: -------- 8< ---------------- 8< ---------------- 8< -------- eficonnect scsi unset prefix search --file --set=prefix /EFI/redhat/grubx64.efi if [ -n "$prefix" ]; then chainloader ($prefix)/EFI/redhat/grubx64/efi ... -------- 8< ---------------- 8< ---------------- 8< -------- The code is easily extensible to handle other arguments in the future if needed. Signed-off-by: Renaud Métrich <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

efi: new 'connectefi' command #108

efi: new 'connectefi' command #108

Commits on Jun 11, 2021

Commits on Oct 7, 2021

Commits on Oct 12, 2021

Commits on Oct 25, 2021

Commits on Feb 2, 2022

Commits on Mar 9, 2022

Commits on May 4, 2022

Commits on May 17, 2022

Commits on May 25, 2022

Commits on Jun 3, 2022

Commits on Aug 1, 2022

Commits on Aug 2, 2022

Commits on Aug 11, 2022

Commits on Aug 25, 2022

Commits on Sep 1, 2022

efi: new 'connectefi' command #108

Are you sure you want to change the base?

efi: new 'connectefi' command #108

Commits on Jun 11, 2021

Commits on Oct 7, 2021

Commits on Oct 12, 2021

Commits on Oct 25, 2021

Commits on Feb 2, 2022

Commits on Mar 9, 2022

Commits on May 4, 2022

Commits on May 17, 2022

Commits on May 25, 2022

Commits on Jun 3, 2022

Commits on Aug 1, 2022

Commits on Aug 2, 2022

Commits on Aug 11, 2022

Commits on Aug 25, 2022

Commits on Sep 1, 2022