Implement a new "connectefi disk" command enabling DISK I/O devices as well as SCSI I/O devices #202
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 Signed-off-by: Christian Glombek <[email protected]> Signed-off-by: Robbie Harwood <[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]>
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]> [jpokorny: 01_menu_auto_hide.in: fix a then/than typo] Signed-off-by: Jan Pokorný <[email protected]> Signed-off-by: Robbie Harwood <[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]>
Several kernel variants can be installed on a system in parallel. In order to allow the user to choose which kernel will be set to default after an update, re-enable grub's usage of DEFAULTKERNEL as set in /etc/sysconfig/kernel Signed-off-by: Nicolas Frayer <[email protected]>
This patch converts the plain numbers used in Vec5 properties to constants. 1. LPAR: Client program supports logical partitioning and associated hcall()s. 2. SPLPAR: Client program supports the Shared Processor LPAR Option. 3. CMO: Enables the Cooperative Memory Over-commitment Option. 4. MAX_CPU: Defines maximum number of CPUs supported. Signed-off-by: Avnish Chouhan <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit 8406cfe)
This patch enables multiple options in Vec5 which are required and
solves the boot issues seen on some machines which are looking for
these specific options.
1. LPAR: Client program supports logical partitioning and
associated hcall()s.
2. SPLPAR: Client program supports the Shared
Processor LPAR Option.
3. DYN_RCON_MEM: Client program supports the
“ibm,dynamic-reconfiguration-memory” property and it may be
presented in the device tree.
4. LARGE_PAGES: Client supports pages larger than 4 KB.
5. DONATE_DCPU_CLS: Client supports donating dedicated processor cycles.
6. PCI_EXP: Client supports PCI Express implementations
utilizing Message Signaled Interrupts (MSIs).
7. CMOC: Enables the Cooperative Memory Over-commitment Option.
8. EXT_CMO: Enables the Extended Cooperative Memory Over-commit Option.
9. ASSOC_REF: Enables “ibm,associativity” and
“ibm,associativity-reference-points” properties.
10. AFFINITY: Enables Platform Resource Reassignment Notification.
11. NUMA: Supports NUMA Distance Lookup Table Option.
12. HOTPLUG_INTRPT: Supports Hotplug Interrupts.
13. HPT_RESIZE: Enable Hash Page Table Resize Option.
14. MAX_CPU: Defines maximum number of CPUs supported.
15. PFO_HWRNG: Supports Random Number Generator.
16. PFO_HW_COMP: Supports Compression Engine.
17. PFO_ENCRYPT: Supports Encryption Engine.
18. SUB_PROCESSORS: Supports Sub-Processors.
19. DY_MEM_V2: Client program supports the “ibm,dynamic-memory-v2” property in the
“ibm,dynamic-reconfiguration-memory” node and it may be presented in the device tree.
20. DRC_INFO: Client program supports the “ibm,drc-info” property definition and it may be
presented in the device tree.
Signed-off-by: Avnish Chouhan <[email protected]>
Reviewed-by: Daniel Kiper <[email protected]>
(cherry picked from commit 98d0df0)
Modify UINT32 to UINTN in EFI_HTTP_MESSAGE to be UEFI 2.9 compliant. Signed-off-by: Keng-Yu Lin <[email protected]> Signed-off-by: Nicolas Frayer <[email protected]>
If GRUB_ENABLE_BLSCFG is true, running grub2-mkconfig will not overwrite kernel cmdline in BLS snippets with what is in GRUB_CMDLINE_LINUX in /etc/default/grub. Update can be forced by sending new arg --update-bls-cmdline, thus decoupling cmdline updates from updates of other parameters. GRUB_GRUBENV_UPDATE remains 'yes' by default. Signed-off-by: mkl <[email protected]>
When the tpm module is loaded, the verifier reads entire file into memory, measures it and uses verified content as a backing buffer for file accesses. However, this process may result in high memory utilization for file operations, sometimes causing a system to run out of memory which may finally lead to boot failure. To address this issue, among others, the commit 887f98f (mm: Allow dynamically requesting additional memory regions) have optimized memory management by dynamically allocating heap space to maximize memory usage and reduce threat of memory exhaustion. But in some cases problems may still arise, e.g., when large ISO images are mounted using loopback or when dealing with embedded systems with limited memory resources. Unfortunately current implementation of the tpm module doesn't allow elimination of the back buffer once it is loaded. Even if the TPM device is not present or it has been explicitly disabled. This may unnecessary allocate a lot memory. To solve this issue, a patch has been developed to detect the TPM status at module load and skip verifier registration if the device is missing or deactivated. This prevents allocation of memory for the back buffer, avoiding wasting memory when no real measure boot functionality is performed. Disabling the TPM device in the system can reduce memory usage in the GRUB. It is useful in scenarios where high memory utilization is a concern and measurements of loaded artifacts are not necessary. Signed-off-by: Michael Chang <[email protected]> Signed-off-by: Stefan Berger <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit 30708df)
UEFI Secure Boot requires signed grub binaries to work, so grub- install should not be used. However, users who have Secure Boot disabled and wish to use the command should not be prevented from doing so if they invoke --force. fixes bz#1917213 / bz#2240994 Signed-off-by: Marta Lewandowska <[email protected]>
When a kernel dump is present then restrict the high memory regions to avoid allocating memory where the kernel dump resides. Use the ibm,kernel-dump node under /rtas to determine whether a kernel dump exists and up to which limit grub can use available memory. Set the upper_mem_limit to the size of the kernel dump section of type 'REAL_MODE_REGION' and therefore only allow grub's memory usage for high addresses from RMO_ADDR_MAX to 'upper_mem_limit'. This means that grub can use high memory in the range of RMO_ADDR_MAX (768MB) to upper_mem_limit and the kernel-dump memory regions above 'upper_mem_limit' remain untouched. This change has no effect on memory allocations below 'linux_rmo_save' (typically at 640MB). Also, fall back to allocating below rmo_linux_save in case the chunk of memory there would be larger than the chunk of memory above RMO_ADDR_MAX. This can for example occur if a free memory area is found starting at 300MB extending up to 1GB but a kernel dump is located at 768MB and therefore does not allow the allocation of the high memory area but requiring to use the chunk starting at 300MB to avoid an unnecessary out-of-memory condition. Signed-off-by: Stefan Berger <[email protected]> Reviewed-by: Hari Bathini <[email protected]> Cc: Pavithra Prakash <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Carolyn Scherrer <[email protected]> Cc: Mahesh Salgaonkar <[email protected]> Cc: Sourabh Jain <[email protected]>
Commit de735a4 added a grub_env_set where the prefix contains the arch name in the pathname. This create issues when trying to load modules using this prefix as the pathname contains a "doubled" arch name in it (ie .../powerpc-ieee1275/powerpc-ieee1275/). Signed-off-by: Nicolas Frayer <[email protected]>
bz#2223437 Signed-off-by: Marta Lewandowska <[email protected]>
Following up on CVE-2019-14865 and taking a fresh look at grub2-set-bootflag now (through my work at CIQ on Rocky Linux), I saw some other ways in which users could still abuse this little program: 1. After CVE-2019-14865 fix, grub2-set-bootflag no longer rewrites the grubenv file in-place, but writes into a temporary file and renames it over the original, checking for error returns from each call first. This prevents the original file truncation vulnerability, but it can leave the temporary file around if the program is killed before it can rename or remove the file. There are still many ways to get the program killed, such as through RLIMIT_FSIZE triggering SIGXFSZ (tested, reliable) or by careful timing (tricky) of signals sent by process group leader, pty, pre-scheduled timers, SIGXCPU (probably not an exhaustive list). Invoking the program multiple times fills up /boot (or if /boot is not separate, then it can fill up the root filesystem). Since the files are tiny, the filesystem is likely to run out of free inodes before it'd run out of blocks, but the effect is similar - can't create new files after this point (but still can add data to existing files, such as logs). 2. After CVE-2019-14865 fix, grub2-set-bootflag naively tries to protect itself from signals by becoming full root. (This does protect it from signals sent by the user directly to the PID, but e.g. "kill -9 -1" by the user still works.) A side effect of such "protection" is that it's possible to invoke more concurrent instances of grub2-set-bootflag than the user's RLIMIT_NPROC would normally permit (as specified e.g. in /etc/security/limits.conf, or say in Apache httpd's RLimitNPROC if grub2-set-bootflag would be abused by a website script), thereby exhausting system resources (e.g., bypassing RAM usage limit if RLIMIT_AS was also set). 3. umask is inherited. Again, due to how the CVE-2019-14865 fix creates a new file, and due to how mkstemp() works, this affects grubenv's new file permissions. Luckily, mkstemp() forces them to be no more relaxed than 0600, but the user ends up being able to set them e.g. to 0. Luckily, at least in my testing GRUB still works fine even when the file has such (lack of) permissions. This commit deals with the abuses above as follows: 1. RLIMIT_FSIZE is pre-checked, so this specific way to get the process killed should no longer work. However, this isn't a complete fix because there are other ways to get the process killed after it has created the temporary file. The commit also fixes bug 1975892 ("RFE: grub2-set-bootflag should not write the grubenv when the flag being written is already set") and similar for "menu_show_once", which further reduces the abuse potential. 2. RLIMIT_NPROC bypass should be avoided by not becoming full root (aka dropping the partial "kill protection"). 3. A safe umask is set. This is a partial fix (temporary files can still accumulate, but this is harder to trigger). While at it, this commit also fixes potential 1- or 2-byte over-read of env[] if its content is malformed - this was not a security issue since the grubenv file is trusted input, and the fix is just for robustness. Signed-off-by: Solar Designer <[email protected]>
Switch to per-user fixed temporary filenames along with a weird locking mechanism, which is explained in source code comments. This is a more complete fix than the previous commit (temporary files can't accumulate). Unfortunately, it introduces new risks (by working on a temporary file shared between the user's invocations), which are _hopefully_ avoided by the patch's elaborate logic. I actually got it wrong at first, which suggests that this logic is hard to reason about, and more errors or omissions are possible. It also relies on the kernel's primitives' exact semantics to a greater extent (nothing out of the ordinary, though). Remaining issues that I think cannot reasonably be fixed without a redesign (e.g., having per-flag files with nothing else in them) and without introducing new issues: A. A user can still revert a concurrent user's attempt of setting the other flag - or of making other changes to grubenv by means other than this program. B. One leftover temporary file per user is still possible. Signed-off-by: Solar Designer <[email protected]>
Exit calmly when not installed SUID root and invoked by non-root. This allows installing user/grub-boot-success.service unconditionally while supporting non-SUID installation of the program for some limited usage. Signed-off-by: Solar Designer <[email protected]>
…for the $MFT file When parsing an extremely fragmented $MFT file, i.e., the file described using the $ATTRIBUTE_LIST attribute, current NTFS code will reuse a buffer containing bytes read from the underlying drive to store sector numbers, which are consumed later to read data from these sectors into another buffer. These sectors numbers, two 32-bit integers, are always stored at predefined offsets, 0x10 and 0x14, relative to first byte of the selected entry within the $ATTRIBUTE_LIST attribute. Usually, this won't cause any problem. However, when parsing a specially-crafted file system image, this may cause the NTFS code to write these integers beyond the buffer boundary, likely causing the GRUB memory allocator to misbehave or fail. These integers contain values which are controlled by on-disk structures of the NTFS file system. Such modification and resulting misbehavior may touch a memory range not assigned to the GRUB and owned by firmware or another EFI application/driver. This fix introduces checks to ensure that these sector numbers are never written beyond the boundary. Fixes: CVE-2023-4692 Reported-by: Maxim Suhanov <[email protected]> Signed-off-by: Maxim Suhanov <[email protected]> Reviewed-by: Daniel Kiper <[email protected]>
…tribute When reading a file containing resident data, i.e., the file data is stored in the $DATA attribute within the NTFS file record, not in external clusters, there are no checks that this resident data actually fits the corresponding file record segment. When parsing a specially-crafted file system image, the current NTFS code will read the file data from an arbitrary, attacker-chosen memory offset and of arbitrary, attacker-chosen length. This allows an attacker to display arbitrary chunks of memory, which could contain sensitive information like password hashes or even plain-text, obfuscated passwords from BS EFI variables. This fix implements a check to ensure that resident data is read from the corresponding file record segment only. Fixes: CVE-2023-4693 Reported-by: Maxim Suhanov <[email protected]> Signed-off-by: Maxim Suhanov <[email protected]> Reviewed-by: Daniel Kiper <[email protected]>
… and non-resident index attributes This fix introduces checks to ensure that index entries are never read beyond the corresponding directory index. The lack of this check is a minor issue, likely not exploitable in any way. Reported-by: Maxim Suhanov <[email protected]> Signed-off-by: Maxim Suhanov <[email protected]> Reviewed-by: Daniel Kiper <[email protected]>
This fix introduces checks to ensure that bitmaps for directory indices are never read beyond their actual sizes. The lack of this check is a minor issue, likely not exploitable in any way. Reported-by: Maxim Suhanov <[email protected]> Signed-off-by: Maxim Suhanov <[email protected]> Reviewed-by: Daniel Kiper <[email protected]>
This fix introduces checks to ensure that an NTFS volume label is always read from the corresponding file record segment. The current NTFS code allows the volume label string to be read from an arbitrary, attacker-chosen memory location. However, the bytes read are always treated as UTF-16LE. So, the final string displayed is mostly unreadable and it can't be easily converted back to raw bytes. The lack of this check is a minor issue, likely not causing a significant data leak. Reported-by: Maxim Suhanov <[email protected]> Signed-off-by: Maxim Suhanov <[email protected]> Reviewed-by: Daniel Kiper <[email protected]>
Move some calls used to access NTFS attribute header fields into functions with human-readable names. Suggested-by: Daniel Kiper <[email protected]> Signed-off-by: Maxim Suhanov <[email protected]> Reviewed-by: Daniel Kiper <[email protected]>
The grub_dprintf() call for printing the message
updating attributes for GOT and trampolines
passes the argument "mod->name", but the format string doesn't accept that
argument.
Print the module name too.
Example output:
> kern/dl.c:736: updating attributes for GOT and trampolines ("video_fb")
Fixes: ad1b904 (nx: set page permissions for loaded modules.)
Signed-off-by: Laszlo Ersek <[email protected]>
On aarch64 UEFI, we currently have a crasher:
grub_dl_load_core()
grub_dl_load_core_noinit()
/* independent allocation: must remain writable */
mod = grub_zalloc();
/* allocates module image with incorrect tail alignment */
grub_dl_load_segments()
/* write-protecting the module image makes "mod" read-only! */
grub_dl_set_mem_attrs()
grub_update_mem_attrs()
grub_dl_init()
/* page fault, crash */
mod->next = ...;
- Commit 887f1d8 ("modules: load module sections at page-aligned
addresses", 2023-02-08) forgot to page-align the allocation of the
trampolines and GOT areas of grub2 modules, in grub_dl_load_segments().
- Commit ad1b904 ("nx: set page permissions for loaded modules.",
2023-02-08) calculated a common bounding box for the trampolines and GOT
areas in grub_dl_set_mem_attrs(), rounded the box size up to a whole
multiple of EFI page size ("arch_addralign"), and write-protected the
resultant page range.
Consequently, grub_dl_load_segments() places the module image in memory
such that its tail -- the end of the trampolines and GOT areas -- lands at
the head of a page whose tail in turn contains independent memory
allocations, such as "mod". grub_dl_set_mem_attrs() will then unwittingly
write-protect these other allocations too.
But "mod" must remain writable: we assign "mod->next" in grub_dl_init()
subsequently. Currently we crash there with a page fault / permission
fault.
(The crash is not trivial to hit: the tramp/GOT areas are irrelevant on
x86_64, plus the page protection depends on the UEFI platform firmware
providing EFI_MEMORY_ATTRIBUTE_PROTOCOL. In practice, the crash is
restricted to aarch64 edk2 (ArmVirtQemu) builds containing commit
1c4dfadb4611, "ArmPkg/CpuDxe: Implement EFI memory attributes protocol",
2023-03-16.)
Example log before the patch:
> kern/dl.c:736: updating attributes for GOT and trampolines ("video_fb")
> kern/efi/mm.c:927: set +rx -w on 0x13b88b000-0x13b88bfff before:rwx after:r-x
> kern/dl.c:744: done updating module memory attributes for "video_fb"
> kern/dl.c:639: flushing 0xe4f0 bytes at 0x13b87d000
> kern/arm64/cache.c:42: D$ line size: 64
> kern/arm64/cache.c:43: I$ line size: 64
> kern/dl.c:839: module name: video_fb
> kern/dl.c:840: init function: 0x0
> kern/dl.c:865: Initing module video_fb
>
> Synchronous Exception at 0x000000013B8A76EC
> PC 0x00013B8A76EC
>
> X0 0x000000013B88B960 X1 0x0000000000000000 X2 0x000000013F93587C X3 0x0000000000000075
>
> SP 0x00000000470745C0 ELR 0x000000013B8A76EC SPSR 0x60000205 FPSR 0x00000000
> ESR 0x9600004F FAR 0x000000013B88B9D0
>
> ESR : EC 0x25 IL 0x1 ISS 0x0000004F
>
> Data abort: Permission fault, third level
Note the following:
- The whole 4K page at 0x1_3B88_B000 is write-protected.
- The "video_fb" module actually lives at [0x1_3B87_D000, 0x1_3B88_B4F0)
-- left-inclusive, right-exclusive --; that is, in the last page (at
0x1_3B88_B000), it only occupies the first 0x4F0 bytes.
- The instruction at 0x1_3B8A_76EC faults. Not shown here, but it is a
store instruction, which writes to the field at offset 0x70 of the
structure pointed-to by the X0 register. This is the "mod->next"
assignment from grub_dl_init().
- The faulting address is therefore (X0 + 0x70), i.e., 0x1_3B88_B9D0. This
is indeed the value held in the FAR register.
- The faulting address 0x1_3B88_B9D0 falls in the above-noted page (at
0x1_3B88_B000), namely at offset 0x9D0. This is *beyond* the first 0x4F0
bytes that the very tail of the "video_fb" module occupies at the front
of that page.
For now, add a self-check that reports this bug (and prevents the crash by
skipping the write protection).
Example log after the patch:
> kern/dl.c:742:BUG: trying to protect pages outside of module allocation
> ("video_fb"): module base 0x13b87d000, size 0xe4f0; tramp/GOT base
> 0x13b88b000, size 0x1000
Signed-off-by: Laszlo Ersek <[email protected]>
The tramp/GOT write-protection in grub_dl_set_mem_attrs() requires that the tramp/GOT areas of the module image *not* share a page with any other memory allocations. Page-align the tramp/GOT areas, while satisfying their intrinsic alignment requirements too. Fixes: 887f1d8 (modules: load module sections at page-aligned addresses) Fixes: ad1b904 (nx: set page permissions for loaded modules.) Signed-off-by: Laszlo Ersek <[email protected]>
Previous patch makes it so that the machine can boot, but not all boot params are passed from /etc/default/grub to BLS snippets because /etc/default/grub gets written by anaconda during boot loader installation, long after grub rpms first got installed. Signed-off-by: Marta Lewandowska <[email protected]>
The initial fix implemented a new flag that forces the grub cfg stub to be located on the same disk as grub. This created several issues such as RAID machines not being able to boot as their partition names under grub were different from the partition where grub is located. It also simply means that any machines with the /boot partition located on a disk other than the one containing grub won't boot. This commit denies booting if the grub cfg stub is located on a USB drive with a duplicated UUID (UUID being the same as the partition containing the actual grub cfg stub) Signed-off-by: Nicolas Frayer <[email protected]>
/boot/efi/EFI/$os_name/grub.cfg contains a grub cfg stub that should not be overwritten by grub2-mkconfig. Ensure that we prevent this from happening. Signed-off-by: Marta Lewandowska <[email protected]> Signed-off-by: Nicolas Frayer <[email protected]>
Remove the debug message "/EndEntire" while using GRUB chainloader command. Signed-off-by: raravind <[email protected]> (cherry picked from commit f75f538)
The 'connectefi disk' command now connects DISK I/O devices as well. The 'connectefi scsi' command is now deprecated and maps to 'connectefi disk'. Connecting DISK I/O devices is required to chainboot HPE ProLiant DL360 Gen10 Plus systems which have their internal NVME disks use the SATA protocol. Below is the 'lsefi' output of such system after connecting DISK I/O devices: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -- Handle 0x37fa2218 /ACPI(a0341d0,0)/PCI(0,17)/Sata(0,0,0)/EndEntire 151c8eae-7f2c-472c-9e54-9828194f6a88 disk d432a67f-14dc-484b-b3bb-3f0291849327 a77b2472-e282-4e9f-a245-c2c0e27bbcc1 block device path -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -- Signed-off-by: Renaud Métrich <[email protected]>
Signed-off-by: Renaud Métrich <[email protected]>
|
The 2nd commit is a resync with Upstream code that was not accepted yet. I've sent the patch to Upstream as well: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
connectefi diskcommand now connects DISK I/O devices as well.The
connectefi scsicommand is now deprecated and maps toconnectefi disk.Connecting DISK I/O devices is required to chainboot HPE ProLiant DL360 Gen10 Plus systems which have their internal NVME disks use the SATA protocol.
Below is the
lsefioutput of such system after connecting DISK I/O devices:See also RFE RHEL-84072