Jon DeVree [Wed, 18 Oct 2023 03:03:47 +0000 (23:03 -0400)]
fs/xfs: Fix XFS directory extent parsing
The XFS directory entry parsing code has never been completely correct
for extent based directories. The parser correctly handles the case
where the directory is contained in a single extent, but then mistakenly
assumes the data blocks for the multiple extent case are each identical
to the single extent case. The difference in the format of the data
blocks between the two cases is tiny enough that its gone unnoticed for
a very long time.
A recent change introduced some additional bounds checking into the XFS
parser. Like GRUB's existing parser, it is correct for the single extent
case but incorrect for the multiple extent case. When parsing a directory
with multiple extents, this new bounds checking is sometimes (but not
always) tripped and triggers an "invalid XFS directory entry" error. This
probably would have continued to go unnoticed but the /boot/grub/<arch>
directory is large enough that it often has multiple extents.
The difference between the two cases is that when there are multiple
extents, the data blocks do not contain a trailer nor do they contain
any leaf information. That information is stored in a separate set of
extents dedicated to just the leaf information. These extents come after
the directory entry extents and are not included in the inode size. So
the existing parser already ignores the leaf extents.
The only reason to read the trailer/leaf information at all is so that
the parser can avoid misinterpreting that data as directory entries. So
this updates the parser as follows:
For the single extent case the parser doesn't change much:
1. Read the size of the leaf information from the trailer
2. Set the end pointer for the parser to the start of the leaf
information. (The previous bounds checking set the end pointer to the
start of the trailer, so this is actually a small improvement.)
3. Set the entries variable to the expected number of directory entries.
For the multiple extent case:
1. Set the end pointer to the end of the block.
2. Do not set up the entries variable. Figuring out how many entries are
in each individual block is complex and does not seem worth it when
it appears to be safe to just iterate over the entire block.
The bounds check itself was also dependent upon the faulty XFS parser
because it accidentally used "filename + length - 1". Presumably this
was able to pass the fuzzer because in the old parser there was always
8 bytes of slack space between the tail pointer and the actual end of
the block. Since this is no longer the case the bounds check needs to be
updated to "filename + length + 1" in order to prevent a regression in
the handling of corrupt fliesystems.
Notes:
* When there is only one extent there will only ever be one block. If
more than one block is required then XFS will always switch to holding
leaf information in a separate extent.
* B-tree based directories seems to be parsed properly by the same code
that handles multiple extents. This is unlikely to ever occur within
/boot though because its only used when there are an extremely large
number of directory entries.
Fixes: ef7850c75 (fs/xfs: Fix issues found while fuzzing the XFS filesystem) Fixes: b2499b29c (Adds support for the XFS filesystem.) Fixes: https://savannah.gnu.org/bugs/?64376 Signed-off-by: Jon DeVree <nuxi@vault24.org> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Tested-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Tested-by: Marta Lewandowska <mlewando@redhat.com>
fs/xfs: Incorrect short form directory data boundary check
After parsing of the current entry, the entry pointer is advanced
to the next entry at the end of the "for" loop. In case where the
last entry is at the end of the data boundary, the advanced entry
pointer can point off the data boundary. The subsequent boundary
check for the advanced entry pointer can cause a failure.
The fix is to include the boundary check into the "for" loop
condition.
Signed-off-by: Lidong Chen <lidong.chen@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Tested-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Tested-by: Marta Lewandowska <mlewando@redhat.com>
Revert "zfsinfo: Correct a check for error allocating memory"
Original commit is wrong because grub_file_get_device_name() may return NULL
if we use implicit $root. Additionally, the grub_errno is guaranteed to be
GRUB_ERR_NONE at the beginning of a command. So, everything should work as
expected and Coverity report, CID 73668, WRT to this code should be treated
as false positive.
This reverts commit 7aab03418 (zfsinfo: Correct a check for error allocating memory).
Fixes: 7aab03418 (zfsinfo: Correct a check for error allocating memory) Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
ValdikSS [Tue, 10 Oct 2023 18:28:44 +0000 (21:28 +0300)]
disk/i386/pc/biosdisk: Read up to 63 sectors in LBA mode
Current code imposes limitations on the amount of sectors read in
a single call according to CHS layout of the disk even in LBA
read mode. There's no need to obey CHS layout restrictions for
LBA reads on LBA disks. It only slows down booting process.
Fabian Vogt [Thu, 5 Oct 2023 13:57:44 +0000 (15:57 +0200)]
fs/btrfs: Zero file data not backed by extents
Implicit holes in file data need to be zeroed explicitly, instead of
just leaving the data in the buffer uninitialized.
This led to kernels randomly failing to boot in "fun" ways when loaded
from btrfs with the no_holes feature enabled, because large blocks of
zeros in the kernel file contained random data instead.
Stefan Berger [Wed, 4 Oct 2023 15:32:35 +0000 (11:32 -0400)]
kern/ieee1275/init: Restrict high memory in presence of fadump on ppc64
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 <stefanb@linux.ibm.com> Reviewed-by: Hari Bathini <hbathini@linux.ibm.com> Cc: Pavithra Prakash <pavrampu@in.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Carolyn Scherrer <cpscherr@us.ibm.com> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com> Cc: Sourabh Jain <sourabhjain@linux.ibm.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
tests/util/grub-shell: Enable RNG device to better test stack smashing
In certain firmwares, e.g. OVMF, the RNG protocol is not enabled unless
there is an RNG device. When not enabled, GRUB fails to initialize the
stack guard with random bytes. For testing, this is not a big issue, but
there have been bugs found in the initialization. So turn this on for EFI
platforms to catch any regressions.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
kern/efi/init: Disable stack smashing protection on grub_efi_init()
GCC is electing to instrument grub_efi_init() to give it stack smashing
protection when configuring with --enable-stack-protector on the x86_64-efi
target. In the function prologue, the canary at the top of the stack frame
is set to the value of the stack guard. And in the epilogue, the canary is
checked to verify if it is equal to the guard and if not to call the stack
check fail function. The issue is that grub_efi_init() sets up the guard
by initializing it with random bytes, if the firmware supports the RNG
protocol. So in its prologue the canary will be set with the value of the
uninitialized guard, likely NUL bytes. Then the guard is initialized, and
finally the epilogue checks the canary against the guard, which will almost
certainly be different. This causes the code path for a smashed stack to be
taken, causing the machine to print out a message that stack smashing was
detected, wait 5 seconds, and then reboot. Disable grub_efi_init()
instrumentation so there is no stack smashing false positive generated.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
disk/cryptodisk: Add support for LUKS2 in (proc)/luks_script
The sector size in bytes is added to each line and it is allowed to be
6 decimal digits long, which covers the most common cases of 512 and 4096
byte sectors with space for two additional digits as future-proofing. The
size allocation is updated to reflect this additional field. Also make
clearer the size allocation calculation.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Use the return value of grub_snprintf() to move the string pointer forward,
instead of incrementing the string pointer iteratively until a NULL byte is
reached. Move the space out of the format string argument, a small
optimization, but also makes the spacing clearer. Also, use the new
PRIxGRUB_OFFSET instead of PRIuGRUB_UINT64_T to accurately reflect the
format string for this type.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
term/serial: Ensure proper NULL termination after grub_strncpy()
A large enough argument to the --port option could cause a string buffer
to be not NULL terminated because grub_strncpy() does not guarantee NULL
termination if copied string is longer than max characters to copy.
Fixes: 712309eaae04 (term/serial: Use grub_strncpy() instead of grub_snprintf() when only copying string) Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Maxim Suhanov [Mon, 28 Aug 2023 13:38:19 +0000 (16:38 +0300)]
fs/ntfs: Fix an OOB read when parsing a volume label
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.
Maxim Suhanov [Mon, 28 Aug 2023 13:32:33 +0000 (16:32 +0300)]
fs/ntfs: Fix an OOB read when reading data from the resident $DATA attribute
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.
Maxim Suhanov [Mon, 28 Aug 2023 13:31:57 +0000 (16:31 +0300)]
fs/ntfs: Fix an OOB write when parsing the $ATTRIBUTE_LIST attribute 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.
Michael Chang [Mon, 25 Sep 2023 05:58:18 +0000 (13:58 +0800)]
kern/acpi: Skip NULL entries in RSDT and XSDT
During attempts to configure a serial console, a Page Fault Exception
and system reset were encountered, specifically on release 2.12~rc1.
This issue was not present in prior versions and seemed to affect only
a specific machine, potentially pointing to hardware or firmware flaw.
After investigation, it was discovered that the invalid page access
occurred during the discovery of serial MMIO ports as specified by
ACPI's SPCR table [1]. The recent change uncovered an issue in GRUB's
ACPI driver.
In certain cases, the XSDT/RSDT root table might contain a NULL entry as
a terminator, depending on how the tables are assembled. GRUB cannot
blindly trust the address in the root table to be valid and should
perform a sanity check for NULL entries. This patch introduces this
simple check.
This fix is also inspired by a related Linux kernel fix [2].
[1] 7b192ec4c term/ns8250: Use ACPI SPCR table when available to configure serial
[2] 0f929fbf0 ACPICA: Tables: Add new mechanism to skip NULL entries in RSDT and XSDT.
Signed-off-by: Michael Chang <mchang@suse.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When grub-install is run with the verbose option, it will print a log
message indicating the grub-mkimage command and arguments used.
GRUB no longer calls the grub-mkimage binary internally, however the
command logged is a command that if run should effectively be what
grub-install used. However, as this has changed some of the newer
options have been incorrectly added so that the printed command fails
when run separately. This change makes the displayed command run as
intended.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
util/grub-install-common: Minor improvements to printing of grub-mkimage command
This is a preparatory patch to make the following patch less cluttered. The
only visible change made here is to not print extra spaces when either or
both --note or --disable-shim-lock are not given and to not print an extra
space at the end of the command. The latter is done by constructing the
trailing argument string with spaces in front of each argument rather than
trailing. The allocation of the argument string is made precise, which has
the benefit of saving a few bytes, but more importantly self-documenting
what the needed allocated bytes are. Also, unneeded braces are removed from
an if block.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
lib/i386/relocator64: Fix 64-bit FreeBSD boot on BIOS
The commit 80948f532d (lib/i386/relocator64: Build fixes for i386) has
broken 64-bit FreeBSD boot on BIOS. This patch fixes the issue.
Fixes: 80948f532d (lib/i386/relocator64: Build fixes for i386) Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Anthony PERARD [Mon, 11 Sep 2023 13:43:45 +0000 (14:43 +0100)]
templates/linux_xen: Fix XSM entries generation
It turns out that setting $xen_version in linux_entry_xsm() override
$xen_version in the loop over $reverse_sorted_xen_list. This means
that only one entry per Xen version is going to enable XSM, but all
further entries are going to have "(XSM enabled)" in their titles
without enabling XSM.
When a "xenpolicy-$xen_version" file was found for the current
$xen_version, it would overwrite $xen_version to add "(XSM enabled)" to
the menu entry title. Once updated, the next call to linux_entry_xsm()
would also have this modified $xen_version and would look for the file
"xenpolicy-*(XSM enabled)" and fail.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Xiaotian Wu [Thu, 24 Aug 2023 13:04:01 +0000 (21:04 +0800)]
loongarch: Eliminate cmodel compilation warnings
In the configure phase, the "-mcmodel=large" CFLAGS passed the test, but
because it has not been implemented in gcc, the following warning will
appear when compiling:
gcc: warning: 'large' is not supported, now cmodel is set to 'normal'
Signed-off-by: Xiaotian Wu <wuxiaotian@loongson.cn> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Fri, 11 Aug 2023 22:22:25 +0000 (17:22 -0500)]
configure: Enable -fno-omit-frame-pointer for backtrace module
The backtrace module is written assuming that the frame pointer is in %ebp.
By default, -Os optimization level is used, which enables the gcc option
-fomit-frame-pointer. This breaks the backtrace functionality. Enabling
this may cause an unnoticeable performance cost and virtually no size increase.
The backtrace command on x86_64 and probably i386 is broken due to the
above rationale. I've not verified, but presumably the backtrace that used
to be printed for an unhandled CPU exception is also broken. Do any distros
handle this?
Considering that, to my knowledge, no one has complained about this in the
over 13 years that -Os has been used, has this code actually been useful?
Is it worth disabling -fomit-frame-pointer? Though, I don't see much downside
right now in disabling it. Alternatively, we could disable/remove the
backtrace code. I think it would be nice to keep it and have it working.
Nowadays, presumably QEMU makes the GDB stub rarely used as I imagine most
are developing in a virtual machines. Also, the GDB stub does not work in UEFI.
So, if anyone is using it on real hardware, they are doing so on pretty old
machines. The lack of a GDB stub does not seem to be a pain point because
no one has got it working on UEFI.
This patch gets the backtrace command working on x86_64-efi in QEMU for me.
However, it hangs when run on my laptop. Not sure what's going on there.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Ard Biesheuvel [Mon, 7 Aug 2023 12:21:51 +0000 (14:21 +0200)]
loader/efi/linux: Implement x86 mixed mode using legacy boot
Recent mixed-mode Linux kernels, i.e., v4.0 or newer, can access EFI
runtime services at OS runtime even when the OS was not entered via the
EFI stub. This is because, instead of reverting back to the firmware's
segment selectors, GDTs and IDTs, the 64-bit kernel simply calls 32-bit
runtime services using compatibility mode, i.e., the same mode used for
32-bit user space, without taking down all interrupt handling, exception
handling, etc.
This means that GRUB's legacy x86 boot mode is sufficient to make use of
this: 32-bit i686 builds of GRUB can already boot 64-bit kernels in EFI
enlightened mode, but without going via the EFI stub, and provide all
the metadata that the OS needs to map the EFI runtime regions and call
EFI runtime services successfully.
It does mean that GRUB should not attempt to invoke the firmware's
LoadImage()/StartImage() methods on kernel builds that it knows cannot
be started natively. So, add a check for this in the native EFI boot
path and fall back to legacy x86 mode in such cases.
Note that in the general case, booting non-native images of the same
native word size, e.g., x64 EFI apps on arm64 firmware, might be
supported by means of emulation. So, let's only disallow images that use
a non-native word size. This will also permit booting i686 kernels on
x86_64 builds, although without access to runtime services, as this is
not supported by Linux.
This change on top of 2.12-rc1 is sufficient to boot ordinary Linux
mixed mode builds and get full access to the EFI runtime services.
Cc: Daniel Kiper <daniel.kiper@oracle.com> Cc: Steve McIntyre <steve@einval.com> Cc: Julian Andres Klode <julian.klode@canonical.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Ard Biesheuvel [Thu, 3 Aug 2023 13:24:09 +0000 (15:24 +0200)]
loader/i386/linux: Prefer entry in long mode when booting via EFI
The x86_64 Linux kernel can be booted in 32-bit mode, in which case the
startup code creates a set of preliminary page tables that map the first
4 GiB of physical memory 1:1 and enables paging. This is a prerequisite
for 64-bit execution and can therefore only be implemented in 32-bit code.
The x86_64 Linux kernel can also be booted in 64-bit mode directly: this
implies that paging is already enabled and it is the responsibility of
the bootloader to ensure that the active page tables cover the entire
loaded image, including its BSS space, the size of which is described in
the image's setup header.
Given that the EFI spec mandates execution in long mode for x86_64 and
stipulates that all system memory is mapped 1:1, the Linux/x86
requirements for 64-bit entry can be met trivially when booting on
x86_64 via EFI. So, enter via the 64-bit entry point in this case.
This involves inspecting the xloadflags field in the setup header to
check whether the 64-bit entry point is supported. This field was
introduced in Linux version v3.8 (early 2013).
This change ensures that all EFI firmware tables and other assets passed
by the firmware or bootloader in memory remain mapped and accessible
throughout the early startup code.
Avoiding the drop out of long mode will also be needed to support
upcoming CPU designs that no longer implement 32-bit mode at all
(as recently announced by Intel [0]).
Some dnodes are shared with properties zap. This is used
e.g. for quotas. Then dnode type is 0xc4 and GRUB stumbles on
this. Check bonus type and if it's ok then ignore dnode type mismatch
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This is a speedup used in some ZFS version. This trips GRUB and makes it
unable to access directories. Just skip it for now and revisit
if we ever need this speedup.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
If the EFI graphics pixel format is PixelBltOnly, we cannot write directly
to the frame buffer. We need the shadow frame buffer which we copy via
the BitBlt operation to the hardware.
If the pixel format is PixelBltOnly and allocation of the shadow frame
buffer fails, we must raise an error to signal that the EFI GOP protocol
is not usable.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Tue, 22 Aug 2023 18:26:29 +0000 (13:26 -0500)]
docs: Add menu to prevent older makeinfo versions from failing
It has been reported that makeinfo version 4.13a complains and returns
error when menus for chapter structuring commands are not present. It
is also known that newer makeinfos, such as version 6.7, will create
default menus when needed. Since the menu will be created regardless,
explicitly create it to support older makeinfo versions. This also
enables building to be successful when an older makeinfo is installed
because in that case info files are attempted to be generated with the
"all" target.
Reported-by: Olaf Hering <olaf@aepfle.de> Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Tested-by: Olaf Hering <olaf@aepfle.de>
Glenn Washburn [Tue, 22 Aug 2023 18:26:28 +0000 (13:26 -0500)]
docs: Use @ref instead of @xref
The @xref command is meant to be used at the beginning of a sentence
because its expansion creates a "See " prefix on all output formats, and
on older makeinfo versions is strict about enforcing a "." or "," after
the command. The @ref command has no such restriction and is just the
link, which allows more control over output. This also fixes an issue
where there was a repeated "see" in the output.
Reported-by: Olaf Hering <olaf@aepfle.de> Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Tested-by: Olaf Hering <olaf@aepfle.de>
Allow using the envvar GRUB_SHELL_LUKS_TIMEOUT to change the default
timeout. If not specified, use value of GRUB_SHELL_DEFAULT_TIMEOUT. And
if that is not specified, fallback to original 600s timeout.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Fri, 18 Aug 2023 17:27:22 +0000 (12:27 -0500)]
disk/cryptodisk: Fix missing change when updating to use grub_uuidcasecmp()
This was causing the cryptomount command to return failure even though
the crypto device was successfully added. Of course, this meant that any
script using the return code would behave unexpectedly.
Fixes: 3cf2e848bc03 (disk/cryptodisk: Allows UUIDs to be compared in a dash-insensitive manner) Suggested-by: Olaf Hering <olaf@aepfle.de> Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Patrich Steinhardt <ps@pks.im> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Fri, 18 Aug 2023 17:15:27 +0000 (12:15 -0500)]
kern/misc: Make grub_vsnprintf() C99/POSIX conformant
To comply with C99 and POSIX standards, snprintf() should return the
number of bytes that would be written to the string (excluding the
terminating NUL byte) if the buffer size was big enough. Before this
change, the return value was the minimum of the standard return and the
length of the buffer. Rarely is the return value of grub_snprintf() or
grub_vsnprintf() used with current code, and the few places where it is
used do not need to be changed.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Mon, 14 Aug 2023 06:16:53 +0000 (01:16 -0500)]
commands/ls: Send correct dirname to print functions
For each non-directory path argument to the ls command, the full path was
being sent to the print functions, instead of the dirname. The long output
print function expected dirname to be the directory containing the file
and so could not open the file to get the file size because the generated
path was incorrect. This caused the output to be a blank line.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Mon, 14 Aug 2023 06:03:41 +0000 (01:03 -0500)]
fs/archelp: If path given to grub_archelp_dir() is not a directory return error
Specifically, return GRUB_ERR_BAD_FILE_TYPE because this is what is
expected by the ls command when it is given a path to a non-directory.
This fixes a bug where calling ls with a list of non-directory paths
outputs a blank line for each such argument.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Fri, 11 Aug 2023 21:30:04 +0000 (16:30 -0500)]
commands/videoinfo: Prevent crash when run while video driver already active
The videoinfo command will initialize all non-active video adapters. Video
drivers tend to zero out the global framebuffer object on initialization.
This is not a problem when there is no active video adapter. However, when
there is, then outputting to the video adapter will cause a crash because
methods in the framebuffer object are reinitialized. For example, this
command sequence will cause a crash.
terminal_output --append gfxterm; videoinfo
When running in a QEMU headless with GRUB built for the x86_64-efi target,
the first command initializes the Bochs video adapter, which, among
other things, sets the set_page() member function. Then when videoinfo is
run, all non-Bochs video adapters will be initialized, each one wiping
the framebuffer and thus setting set_page to NULL. Soon after the videoinfo
command finishes there will be a call to grub_refresh(), which will
ultimately call the framebuffer's set_page which will be NULL and cause
a crash when called.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Wed, 2 Aug 2023 00:58:51 +0000 (19:58 -0500)]
docs: Improve initrd documentation
A list of improvements:
* Remove reference to "initial ramdisk" and replace with "initrd". This
then covers the case of ramdisk and ramfs, which is the usual method
with kernels 2.6 and newer.
* Add sentence with URL to initrd documentation Linux kernel.
* Add a section documenting how to have the initrd command generate
a new-style initrd via a specially crafted argument and include an example.
* Update initrd16 to refer to the initrd section and make note that
initrd16 is only on the pc platform.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Oskari Pirhonen <xxc3ncoredxx@gmail.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
term/ns8250-spcr: Continue processing SPCR table even if revision is < 2
According to commit 0231d00082 (ACPI: SPCR: Make SPCR available to x86)
to the Linux kernel, "On x86, many systems have a valid SPCR table but the
table version is not 2 so the table version check must be a warning."
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
docs: A note to cat that hexdump should be used for binary data
The cat command should not be used to print binary data because it can
show bytes not in the binary data and not show bytes that are in the data,
which can lead to confusion. This happens because cat does some processing
of the data stream, namely trying to decode substrings as UTF-8.
Michał Grzelak [Tue, 18 Jul 2023 22:48:21 +0000 (00:48 +0200)]
configure: Fix SDL2 typo by referencing value
During configuration of SDL2, variable enable_grub_emu_sdl2 is checked
whether to throw an error message. However, error could not happen
because two unequal strings were compared. Fix this by referencing
value of enable_grub_emu_sdl2, not name.
Fixes: 17d6ac1a7 (emu: Add SDL2 support) Signed-off-by: Michał Grzelak <mchl.grzlk@gmail.com> Reviewed-by: Julian Andres Klode <julian.klode@canonical.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Daniel Kiper [Fri, 30 Jun 2023 14:02:15 +0000 (16:02 +0200)]
efi: Fallback to legacy mode if shim is loaded on x86 archs
The LoadImage() provided by the shim does not consult MOK when loading
an image. So, simply signature verification fails when it should not.
This means we cannot use Linux EFI stub to start the kernel when the
shim is loaded. We have to fallback to legacy mode on x86 architectures.
This is not possible on other architectures due to lack of legacy mode.
This is workaround which should disappear when the shim provides
LoadImage() which looks up MOK during signature verification.
On the occasion align constants in include/grub/efi/sb.h.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Michał Grzelak [Thu, 29 Jun 2023 18:11:04 +0000 (20:11 +0200)]
configure.ac: Fix typo by adding missing $
During configuration of SDL, variable enable_grub_emu_sdl is checked
whether to throw an error message. However, error could not happen
because two unequal strings were compared. Fix this by referencing
value of enable_grub_emu_sdl, not name.
Fixes: 17d6ac1a7 (emu: Add SDL2 support) Signed-off-by: Michał Grzelak <mchl.grzlk@gmail.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Wed, 28 Jun 2023 10:10:09 +0000 (05:10 -0500)]
docs: Minor corrections
When referring to initrd16 the link for initrd16 should be used, not a link
for initrd. Also, correct the spelling of additionally and add a comma after
it to correct its grammatical usage.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Wed, 28 Jun 2023 07:25:16 +0000 (02:25 -0500)]
loader/linux: Only emit newc directory once
When creating at runtime a newc initrd via arguments to initrd with "newc:"
prefixes, only emit a directory path record once. The original code
intended to do that by bailing out of emitting the record when the record
to be created matches an existing record. However, this does not happen
because grub_memcmp() is improperly checked.
Generating duplicate newc directory records does not cause any problems
because the Linux unpacker will skip it once it sees the directory already
exists. This fix saves a little processing and makes the generated newc
cpio archive a little smaller.
Fixes: 92750e4c60 (Add ability to generate newc additions on runtime.) Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Wed, 28 Jun 2023 06:19:48 +0000 (01:19 -0500)]
loader/efi/linux: Print EFI status as hex number instead of uint
EFI status codes are of different classes depending on the first byte and
all error status codes defined in appendix D of the main spec start from
1 and have the high bit set. When printing as a uint, the decimal is a very
large number that needs have the high bit cleared get the spec error code.
This can be easily visually done by a human if the number is printed as hex.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
So all we did with the surface in SDL1 was split into window,
surface, renderer and texture. Instead of drawing into the
surface and then flipping, you build your pixels, then update
a texture and then copy the texture to the renderer.
Here we use an empty RGB surface to hold our pixels, which enables
us to keep most of the code the same. The SDL1 code has been adjusted
to refer to "surface" instead of "window" when trying to access the
properties of the surface.
This approaches the configuration by adding a new --enable-grub-emu-sdl2
argument. If set to yes, or auto detected, it disables SDL1 support
automatically.
This duplicates the sdl module block in Makefile.core.def which may
be something to be aware of, but we also don't want to build separate
module.
Fixes: https://bugs.debian.org/1038035 Signed-off-by: Julian Andres Klode <julian.klode@canonical.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Michał Grzelak [Thu, 15 Jun 2023 22:39:47 +0000 (00:39 +0200)]
tpm: Enable boot despite unknown firmware failure
Currently booting the system is prevented when call to EFI firmware
hash_log_extend_event() returns unknown error. Solve this by following
convention used in commit a4356538d (commands/tpm: Don't propagate
measurement failures to the verifiers layer).
Let the system to be bootable by default when unknown TPM error is
encountered. Check environment variable tpm_fail_fatal to fallback to
previous behaviour.
Signed-off-by: Michał Grzelak <mchl.grzlk@gmail.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Kiper [Thu, 15 Jun 2023 14:45:00 +0000 (16:45 +0200)]
efi: Add missing __grub_efi_api attributes
The commit bb4aa6e06 (efi: Drop all uses of efi_call_XX() wrappers) did
not add some __grub_efi_api attributes to the EFI calls. Lack of them
led to hangs on x86_64-efi target. So, let's add missing __grub_efi_api
attributes.
Fixes: bb4aa6e06 (efi: Drop all uses of efi_call_XX() wrappers) Reported-by: Christian Hesse <list@eworm.de> Reported-by: Robin Candau <antiz@archlinux.org> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> Tested-by: Robin Candau <antiz@archlinux.org> Tested-by: Christian Hesse <list@eworm.de> Reviewed-by: Peter Jones <pjones@redhat.com>
disk: Generalize MD_MAX_DISKS to GRUB_MDRAID_MAX_DISKS
Move the constant from grub-core/osdep/linux/getroot.c to
include/grub/disk.h and then reuse it in place of the
hardcoded 1024 limit in diskfilter.
Fixes: 2a5e3c1f2 (disk/diskfilter: Don't make a RAID array with more than 1024 disks) Cc: Daniel Axtens <dja@axtens.net> Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Julian Andres Klode <julian.klode@canonical.com> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Xiaotian Wu [Thu, 15 Jun 2023 12:10:38 +0000 (20:10 +0800)]
loongarch: Disable relaxation relocations
A working GRUB cannot be built with upcoming binutils and GCC, because linker
relaxation was added [1] causing new unsupported relocations to appear in modules.
So we pass -mno-relax to GCC if it is supported, to disable relaxation and make
GRUB forward-compatible with new toolchains.
While similar code already exists for sparc64 in configure.ac, sparc64 sets
LDFLAGS while LoongArch requires CFLAGS to be set. If we only set LDFLAGS on
LoongArch, GCC will still generate relaxation relocations in the .o files, so
the sparc64 code cannot be reused.
Xiaotian Wu [Tue, 13 Jun 2023 09:06:33 +0000 (17:06 +0800)]
loongarch: Rename function names
According to the relocation documentation, the following function names are
renamed to show their exact meaning:
- from grub_loongarch64_xxx64_hi12() to grub_loongarch64_abs64_hi12(),
- from grub_loongarch64_xxx64_hi12() to grub_loongarch64_abs64_lo20().
Signed-off-by: Xiaotian Wu <wuxiaotian@loongson.cn> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Qiumiao Zhang [Tue, 13 Jun 2023 03:20:51 +0000 (11:20 +0800)]
kern/acpi: Use xsdt_addr if present
According to the ACPI specification, in ACPI 2.0 or later, an
ACPI-compatible OS must use the XSDT if present. So, we should
use xsdt_addr instead of rsdt_addr if xsdt_addr is valid.
Signed-off-by: Qiumiao Zhang <zhangqiumiao1@huawei.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Qiumiao Zhang [Tue, 13 Jun 2023 03:17:36 +0000 (11:17 +0800)]
commands/acpi: Use xsdt_addr if present
According to the ACPI specification, in ACPI 2.0 or later, an
ACPI-compatible OS must use the XSDT if present. So, we should
use xsdt_addr instead of rsdt_addr if xsdt_addr is valid.
Signed-off-by: Qiumiao Zhang <zhangqiumiao1@huawei.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Tue, 6 Jun 2023 05:48:39 +0000 (00:48 -0500)]
docs: Add debugging chapter to development documentation
Debugging GRUB can be tricky and require arcane knowledge. This will
help those unfamiliar with the process to get started debugging GRUB
with less effort.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Darren Kenny [Fri, 2 Jun 2023 18:08:44 +0000 (18:08 +0000)]
fs/xfs: Fix issues found while fuzzing the XFS filesystem
While performing fuzz testing with XFS filesystem images with ASAN
enabled, several issues were found where the memory accesses are made
beyond the data that is allocated into the struct grub_xfs_data
structure's data field.
The existing structure didn't store the size of the memory allocated into
the buffer in the data field and had no way to check it. To resolve these
issues, the data size is stored to enable checks into the data buffer.
With these checks in place, the fuzzing corpus no longer cause any crashes.
Signed-off-by: Darren Kenny <darren.kenny@oracle.com> Signed-off-by: Robbie Harwood <rharwood@redhat.com> Signed-off-by: Marta Lewandowska <mlewando@redhat.com> Signed-off-by: Lidong Chen <lidong.chen@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
grub-core/genmoddep.awk: Ensure output is deterministic
The output in moddep.lst generated from syminfo.lst using genmoddep.awk
is not deterministic since the order of the dependencies on each line
can vary depending on how awk sorts the values in the array.
Be deterministic in the output by sorting the dependencies on each line.
Signed-off-by: Alexander Kanavin <alex@linutronix.de> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The output of the SOURCES lines in grub-core/Makefile.core.am, generated
from grub-core/Makefile.core.def with gentpl.py is not deterministic due to
missing sorting of the list used to generate it. Add such a sort.
Signed-off-by: Alexander Kanavin <alex@linutronix.de> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Thu, 1 Jun 2023 04:25:55 +0000 (23:25 -0500)]
gdb: Add gdbinfo command for printing the load address of the EFI application
EFI firmware determines where to load the GRUB EFI at runtime, and so the
addresses of debug symbols are not known ahead of time. There is a command
defined in the gdb_grub script which will load the debug symbols at the
appropriate addresses, if given the application load address for GRUB.
So add a command named "gdbinfo" to allow the user to print this GDB command
string with the application load address on-demand. For the outputted GDB
command to have any effect when entered into a GDB session, GDB should have
been started with the script as an argument to the -x option or sourced into
an active GDB session before running the outputted command.
Documentation for the gdbinfo command is also added.
Co-developed-by: Peter Jones <pjones@redhat.com> Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Thu, 1 Jun 2023 04:16:26 +0000 (23:16 -0500)]
loader/efi/chainloader: Do not require a $root visible to EFI firmware when chainloading
The EFI chainloader checks that a device path can be created for the $root
device before allowing chainloading to a given file. This is probably to
ensure that the given file can be accessed and loaded by the firmware.
However, since GRUB is loading the image itself, the firmware need not
be able to access the file location of the image. So remove this check.
Also, this fixes an issue where chainloading an image file on a location
that is accessible by the firmware, e.g. (hd0,1)/efi/boot.efi, would
fail when root is a location inaccessible by the firmware, e.g. memdisk.
Use GRUB_EFI_BYTES_TO_PAGES() instead of doing the calculation explicitly.
Add comment noting the section where the load options for the chainloaded
EFI application is constructed.
Glenn Washburn [Thu, 1 Jun 2023 04:16:25 +0000 (23:16 -0500)]
docs: Document extra arguments to chainloader on EFI
Extra arguments given to chainloader on EFI platforms will be sent to
the chainloaded application. Also, minor edit in the chainloading section
to note that chainloading can be a jump via the firmware and not
necessarily in real mode (which does not exist on some architectures).
projects / thirdparty / grub.git / log
