Current code works only if package matches binary name transformation rules.
It's often true but is not guaranteed.
Fixes: https://savannah.gnu.org/bugs/?64410
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Current code in some codepaths neither discards nor reports errors.
Properly surface the error.
While on it split 2 cases of unrelated variables both named err.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In grub-core/loader/i386/multiboot_mbi.c, Coverity spotted redundant code where
the variable err was being set to GRUB_ERR_NONE and then being overwritten
later without being used. Since this is unnecessary, we can remove the code
that sets err to GRUB_ERR_NONE.
Fixes: CID 428877
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Current code implicitly assumes that aligning chunk_size + *kern_end is
the same as aligning on curload which is not the case because
chunk_size starts at zero even if *kern_end is unaligned and ALIGN_PAGE
moved curload to an aligned position but not *kern_end + chunk_size.
This fixes booting of FreeBSD with zfs module.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
On PowerVM and KVM on Power use the new memory allocation function that
honors restrictions on which memory GRUB can actually use. In the request
structure indicate the request for a single memory block along with
address alignment restrictions. Request direct usage of the memory block
by setting init_region to false (prevent it from being added to GRUB's
heap). Initialize the found addr to -1, so that -1 will be returned
to the loader in case no memory could be allocated.
Report an out-of-memory error in case the initrd could not be loaded.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Cc: 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>
On ia64 alignment requirements are strict. When we pass a pointer to
UUID it needs to be at least 4-byte aligned or EFI will crash.
On the other hand in device path there is no padding for UUID, so we
need 2 types in one formor another. Make 4-byte aligned and unaligned types
The code is structured in a way to accept unaligned inputs
in most cases and supply 4-byte aligned outputs.
Efiemu case is a bit ugly because there inputs and outputs are
reversed and so we need careful casts to account for this
inversion.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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>
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]).
[0] https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Julian Andres Klode <julian.klode@canonical.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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>
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>
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>
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.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Use the new printf format specifier %pG.
Fixes the text representation of GUIDs in the output of the lsefisystab
command (missing 4th dash).
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
There are 3 implementations of a GUID in GRUB. Replace them with
a common one, placed in types.h.
It uses the "packed" flavor of the GUID structs, the alignment attribute
is dropped, since it is not required.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The EFI spec mandates that the handle produced by the LoadImage boot
service has a LoadedImage protocol instance installed on it, but for
robustness, we should still deal with a NULL return value from the
helper routine that obtains this protocol pointer.
If this happens, don't try to start the image but unload it and return
an error.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Switch the x86 based EFI platform builds to the generic EFI loader,
which exposes the initrd via the LoadFile2 protocol instead of the
x86-specific setup header. This will launch the Linux kernel via its EFI
stub, which performs its own initialization in the EFI boot services
context before calling ExitBootServices() and performing the bare metal
Linux boot.
Given that only Linux kernel versions v5.8 and later support this initrd
loading method, the existing x86 loader is retained as a fallback, which
will also be used for Linux kernels built without the EFI stub. In this
case, GRUB calls ExitBootServices() before entering the Linux kernel,
and all EFI related information is provided to the kernel via struct
boot_params in the setup header, as before.
Note that this means that booting EFI stub kernels older than v5.8 is
not supported even when not using an initrd at all. Also, the EFI
handover protocol, which has no basis in the UEFI specification, is not
implemented.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Now that GCC can generate function calls using the correct calling
convention for us, we can stop using the efi_call_XX() wrappers, and
just dereference the function pointers directly.
This avoids the untyped variadic wrapper routines, which means better
type checking for the method calls.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In grub-core/loader/multiboot_elfxx.c, we need to make sure that the program
header offset is less than the file size along with the MULTIBOOT_SEARCH
constant. We can do so by setting the variable phlimit to the minimum value of
the two limits and check it each time we change program header index to insure
that the program header offset isn't outside of the limits.
Fixes: CID 314029
Fixes: CID 314038
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In grub-core/loader/multiboot_elfxx.c, space is being allocated for the section
header region, but isn't verifying if the region is within the file's size.
Before calling grub_calloc(), we can add a conditional to check if the section
header region is smaller than the file size.
Fixes: CID 314029
Fixes: CID 314038
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In grub-core/loader/multiboot_elfxx.c, the code is filling an area of memory
with grub_memset() but doesn't check if there is space in the allocated memory
before doing so. To make sure we aren't zeroing memory past the allocated memory
region, we need to check that the offset into the allocated memory region plus
the memory size of the program is smaller than the allocated memory size.
Fixes: CID 314029
Fixes: CID 314038
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Per systemctl(1), it "is asynchronous; it will return after the reboot
operation is enqueued, without waiting for it to complete". This differs
from kexec(8), which calls reboot(2) and therefore does not return.
When not using fallback, this confusingly results in:
error trying to perform 'systemctl kexec': 0
Aborted. Press any key to exit.
on screen for a bit, followed by successful kexec.
To reduce the likelihood of hitting this case, add a delay on successful
return. Ultimately, the systemd interface is racy: we can't avoid it
entirely unless we never fallback on success.
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
RISC-V doesn't have to do anything very different from other architectures
to loader EFI stub linux kernel. As a result, just use the common linux
loader instead of defining a RISC-V specific linux loader.
Signed-off-by: Atish Patra <atishp@rivosinc.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The arch specific image header details are not very useful as most of
the GRUB just looks at the PE/COFF spec parameters (PE32 magic and
header offset).
Remove the arch specific images headers and define a generic arch
headers that provide enough PE/COFF fields for the GRUB to parse
kernel images correctly.
Signed-off-by: Atish Patra <atishp@rivosinc.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
ARM64 linux loader code is written in such a way that it can be reused
across different architectures without much change. Move it to common
code so that RISC-V doesn't have to define a separate loader.
Signed-off-by: Atish Patra <atishp@rivosinc.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The "addr" is used to request the memory with specific ranges but the real
loadable address come from the relocator. Thus, print the final retrieved
addresses, virtual and physical, for initrd.
On the occasion migrate to PRIxGRUB_ADDR and PRIxGRUB_SIZE format specifiers.
Signed-off-by: Jeremy Szu <jeremy.szu@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The current i386 initrd is limited under 1 GiB memory and it works with
most compressed initrds (also initrd_addr_max case reported by kernel).
addr = (addr_max - aligned_size) & ~0xFFF;
Above line is used to calculate the reasonable address to store the initrd.
However, if initrd size is greater than 1 GiB or initrd_addr_max, then it
will get overflow, especially on x86_64 arch.
Therefore, add a check point to prevent it overflows as well as having
a debug log for complex story of initrd addresses.
Signed-off-by: Jeremy Szu <jeremy.szu@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Per "man 5 cpio", the namesize in the cpio header includes the trailing
NUL byte of the pathname and the pathname is followed by NUL bytes, but
the current implementation ignores the trailing NUL byte when making
the newc header. Although make_header() tries to pad the pathname string,
the padding won't happen when strlen(name) + sizeof(struct newc_head)
is a multiple of 4, and the non-NULL-terminated pathname may lead to
unexpected results.
Assume that a file is created with 'echo -n aaaa > /boot/test12' and
loaded by grub2:
linux /boot/vmlinuz
initrd newc:test12:/boot/test12 /boot/initrd
The initrd command eventually invoked grub_initrd_load() and sent
't''e''s''t''1''2' to make_header() to generate the header:
00000070 30 37 30 37 30 31 33 30 31 43 41 30 44 45 30 30 |070701301CA0DE00|
00000080 30 30 38 31 41 34 30 30 30 30 30 33 45 38 30 30 |0081A4000003E800|
00000090 30 30 30 30 36 34 30 30 30 30 30 30 30 31 36 33 |0000640000000163|
000000a0 37 36 45 34 35 32 30 30 30 30 30 30 30 34 30 30 |76E4520000000400|
000000b0 30 30 30 30 30 38 30 30 30 30 30 30 31 33 30 30 |0000080000001300|
000000c0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 |0000000000000000|
000000d0 30 30 30 30 30 36 30 30 30 30 30 30 30 30 74 65 |00000600000000te|
^namesize
000000e0 73 74 31 32 61 61 61 61 30 37 30 37 30 31 30 30 |st12aaaa07070100|
^^ end of the pathname
Since strlen("test12") + sizeof(struct newc_head) is 116 = 29 * 4,
make_header() didn't pad the pathname, and the file content followed
"test12" immediately. This violates the cpio format and may trigger such
error during linux boot:
Initramfs unpacking failed: ZSTD-compressed data is trunc
To avoid the potential problems, this commit counts the trailing NUL byte
in when calling make_header() and adjusts the initrd size accordingly.
Now the header becomes
00000070 30 37 30 37 30 31 33 30 31 43 41 30 44 45 30 30 |070701301CA0DE00|
00000080 30 30 38 31 41 34 30 30 30 30 30 33 45 38 30 30 |0081A4000003E800|
00000090 30 30 30 30 36 34 30 30 30 30 30 30 30 31 36 33 |0000640000000163|
000000a0 37 36 45 34 35 32 30 30 30 30 30 30 30 34 30 30 |76E4520000000400|
000000b0 30 30 30 30 30 38 30 30 30 30 30 30 31 33 30 30 |0000080000001300|
000000c0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 |0000000000000000|
000000d0 30 30 30 30 30 37 30 30 30 30 30 30 30 30 74 65 |00000700000000te|
^namesize
000000e0 73 74 31 32 00 00 00 00 61 61 61 61 30 37 30 37 |st12....aaaa0707|
^^ end of the pathname
Besides the trailing NUL byte, make_header() pads 3 more NUL bytes, and
the user can safely read the pathname without a further check.
To conform to the cpio format, the headers for "TRAILER!!!" are also
adjusted to include the trailing NUL byte, not ignore it.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The commit eb33e61b3 (multiboot: fix memory leak) did not fix all
issues. Fix all of them right now.
Fixes: eb33e61b3 (multiboot: fix memory leak)
Signed-off-by: t.feng <fengtao40@huawei.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add an include on stdbool.h, making the bool type generally available
within the GRUB without needing to add a file-specific include every
time it would be used.
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The GRUB emulator is used as a debugging utility but it could also be
used as a user-space bootloader if there is support to boot an operating
system.
The Linux kernel is already able to (re)boot another kernel via the
kexec boot mechanism. So the grub-emu tool could rely on this feature
and have linux and initrd commands that are used to pass a kernel,
initramfs image and command line parameters to kexec for booting
a selected menu entry.
By default the systemctl kexec option is used so systemd can shutdown
all of the running services before doing a reboot using kexec. But if
this is not present, it can fall back to executing the kexec user-space
tool directly. The ability to force a kexec-reboot when systemctl kexec
fails must only be used in controlled environments to avoid possible
filesystem corruption and data loss.
Signed-off-by: Raymund Will <rw@suse.com>
Signed-off-by: John Jolly <jjolly@suse.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Now that we implemented support for the LoadFile2 protocol for initrd
loading, there is no longer a need to pass the initrd parameters via
the device tree. This means that when the LoadFile2 protocol is being
used, there is no reason to update the device tree in the first place,
and so we can ignore it entirely.
The only remaining reason to deal with the devicetree is if we are
using the "devicetree" command to load one from disk, so tweak the
logic in grub_fdt_install() to take that into account.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Recent Linux kernels will invoke the LoadFile2 protocol installed on
a well-known vendor media path to load the initrd if it is exposed by
the firmware. Using this method is preferred for two reasons:
- the Linux kernel is in charge of allocating the memory, and so it can
implement any placement policy it wants (given that these tend to
change between kernel versions),
- it is no longer necessary to modify the device tree provided by the
firmware.
So let's install this protocol when handling the "initrd" command if
such a recent kernel was detected (based on the PE/COFF image version),
and defer loading the initrd contents until the point where the kernel
invokes the LoadFile2 protocol.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The way we load the Linux and PE/COFF image headers depends on a fixed
placement of the COFF header at offset 0x40 into the file. This is
a reasonable default, given that this is where Linux emits it today.
However, in order to comply with the PE/COFF spec, which allows this
header to appear anywhere in the file, let's ensure that we read the
header from where it actually appears in the file if it is not located
at offset 0x40.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Xen has its own version of the image header, to account for the
additional PE/COFF header fields. Since we are adding references to
those in the shared EFI loader code, update the common definitions
and drop the Xen specific one which no longer has a purpose.
Since in both cases, the call to grub_arch_efi_linux_check_image() is
preceded by a load of the image header, let's move the load into that
function, and rename it to grub_arch_efi_linux_load_image_header().
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Numerous register fields in the relocator state are simply not
used depending on the relocator. This causes Coverity to flag
these fields but there is no real bug here. Simply initializing
the variable to {0} solves the issue. Fixed in the else case too
for consistency.
Fixes: CID 396932
Signed-off-by: Ross Philipson <ross.philipson@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In the case of an error grub_initrd_load() uses argv[] to print the
filename that caused the error. It is also possible to obtain the
filename from the file handles and there is no need to duplicate that
information in argv[], so let's drop it.
Signed-off-by: Nikita Ermakov <arei@altlinux.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In grub-core/loader/i386/bsdXX.c and grub-core/loader/multiboot_elfxx.c, error
conditionals are simplified to statements such as "if (err)". Even though the
assumption that non-zero values give errors is correct, it would be clearer and
more consistent to compare these conditionals to GRUB_ERR_NONE.
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In bsdXX.c and multiboot_elfxx.c, e_phnum is used to obtain the number of
program header table entries, but it wasn't being checked if the value was
there.
According to the elf(5) manual page,
"If the number of entries in the program header table is larger than or equal to
PN_XNUM (0xffff), this member holds PN_XNUM (0xffff) and the real number of
entries in the program header table is held in the sh_info member of the
initial entry in section header table. Otherwise, the sh_info member of the
initial entry contains the value zero."
Since this check wasn't being made, grub_elfXX_get_phnum() is being added to
elfXX.c to make this check and use e_phnum if it doesn't have PN_XNUM as a
value, else use sh_info. We also need to make sure e_phnum isn't greater than
PN_XNUM and sh_info isn't less than PN_XNUM.
Note that even though elf.c and elfXX.c are located in grub-core/kern, they are
compiled as modules and don't need the EXPORT_FUNC() macro to define the functions
in elf.h.
Also, changed casts of phnum to match variables being set as well as dropped
casts when unnecessary.
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In multiboot_elfxx.c, e_shstrndx is used to obtain the section header table
index of the section name string table, but it wasn't being checked if the value
was there.
According to the elf(5) manual page,
"If the index of section name string table section is larger than or equal to
SHN_LORESERVE (0xff00), this member holds SHN_XINDEX (0xffff) and the real
index of the section name string table section is held in the sh_link member of
the initial entry in section header table. Otherwise, the sh_link member of the
initial entry in section header table contains the value zero."
Since this check wasn't being made, grub_elfXX_get_shstrndx() is being added to
elfXX.c to make this check and use e_shstrndx if it doesn't have SHN_XINDEX as a
value, else use sh_link. We also need to make sure e_shstrndx isn't greater than
or equal to SHN_LORESERVE and sh_link isn't less than SHN_LORESERVE.
Note that even though elf.c and elfXX.c are located in grub-core/kern, they are
compiled as modules and don't need the EXPORT_FUNC() macro to define the functions
in elf.h.
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In bsdXX.c and multiboot_elfxx.c, e_shnum is used to obtain the number of
section header table entries, but it wasn't being checked if the value was
there.
According to the elf(5) manual page,
"If the number of entries in the section header table is larger than or equal to
SHN_LORESERVE (0xff00), e_shnum holds the value zero and the real number of
entries in the section header table is held in the sh_size member of the initial
entry in section header table. Otherwise, the sh_size member of the initial
entry in the section header table holds the value zero."
Since this check wasn't being made, grub_elfXX_get_shnum() is being added to
elfXX.c to make this check and use whichever member doesn't have a value of
zero. If both are zero, then we must return an error. We also need to make sure
that e_shnum doesn't have a value greater than or equal to SHN_LORESERVE and
sh_size isn't less than SHN_LORESERVE.
In order to get this function to work, the type ElfXX_Shnum is being added where
Elf32_Shnum defines Elf32_Word and Elf64_Shnum defines Elf64_Xword. This new
type is needed because if shnum obtains a value from sh_size, sh_size could be
of type El32_Word for Elf32_Shdr structures or Elf64_Xword for Elf64_Shdr
structures.
Note that even though elf.c and elfXX.c are located in grub-core/kern, they are
compiled as modules and don't need the EXPORT_FUNC() macro to define the functions
in elf.h.
For a few smaller changes, changed casts of shnum to match variables being set
as well as dropped casts when unnecessary and fixed spacing errors in bsdXX.c.
Also, shnum is an unsigned integer and is compared to int i in multiboot_elfxx.c,
it should be unsigned to match shnum.
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The "ARM\x64" magic number in the file header identifies an image as one
that implements the bare metal boot protocol, allowing the loader to
simply move the file to a suitably aligned address in memory, with
sufficient headroom for the trailing .bss segment (the required memory
size is described in the header as well).
Note of this matters for GRUB, as it only supports EFI boot. EFI does
not care about this magic number, and nor should GRUB: this prevents us
from booting other PE linux images, such as the generic EFI zboot
decompressor, which is a pure PE/COFF image, and does not implement the
bare metal boot protocol.
So drop the magic number check.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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.
Fixes: CVE-2022-28736
Signed-off-by: Chris Coulson <chris.coulson@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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.
Signed-off-by: Chris Coulson <chris.coulson@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In bsdXX.c, a couple of untrusted loop bound and untrusted allocation size bugs
were flagged by Coverity in the functions grub_openbsd_find_ramdisk() and
grub_freebsd_load_elfmodule(). These bugs were flagged by coverity because the
variable shdr was downcasting from a char pointer to an Elf_Shdr pointer
whenever it was used to set the base value in for loops. To avoid this, we need
to set shdr as an Elf_Shdr pointer where it is initialized.
In the function read_headers(), the function is reading elf section header data
from a file and passing it to the variable shdr as data for a char pointer. If
we switch the type of shdr to an Elf_Shdr pointer in read_headers() as well as
other functions, then we won't need to downcast to an Elf_Shdr pointer. By doing
this, the issue becomes masked from Coverity's view. In the following patches,
we check limits to ensure the data isn't tainted.
Also, switched use of (char *) to (grub_uint8_t *) to give a better indication
of pointer arithmetic and not suggest use of a C string.
Fixes: CID 314018
Fixes: CID 314030
Fixes: CID 314031
Fixes: CID 314039
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
The GRUB is failing to build with GCC-12 in many places like this:
In function 'init_cbfsdisk',
inlined from 'grub_mod_init' at ../../grub-core/fs/cbfs.c:391:3:
../../grub-core/fs/cbfs.c:345:7: error: array subscript 0 is outside array bounds of 'grub_uint32_t[0]' {aka 'unsigned int[]'} [-Werror=array-bounds]
345 | ptr = *(grub_uint32_t *) 0xfffffffc;
| ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is caused by GCC regression in 11/12 [1]. In a nut shell, the
warning is about detected invalid accesses at non-zero offsets to NULL
pointers. Since hardwired constant address is treated as NULL plus an
offset in the same underlying code, the warning is therefore triggered.
Instead of inserting #pragma all over the places where literal pointers
are accessed to avoid diagnosing array-bounds, we can try to borrow the
idea from Linux kernel that the absolute_pointer() macro [2][3] is used
to disconnect a pointer using literal address from it's original object,
hence GCC won't be able to make assumptions on the boundary while doing
pointer arithmetic. With that we can greatly reduce the code we have to
cover up by making initial literal pointer assignment to use the new
wrapper but not having to track everywhere literal pointers are
accessed. This also makes code looks cleaner.
Please note the grub_absolute_pointer() macro requires to be invoked in
a function as long as it is compound expression. Some global variables
with literal pointers has been changed to local ones in order to use
grub_absolute_pointer() to initialize it. The shuffling is basically done
in a selective and careful way that the variable's scope doesn't matter
being local or global, for example, the global variable must not get
modified at run time throughout. For the record, here's the list of
global variables got shuffled in this patch:
grub-core/commands/i386/pc/drivemap.c:int13slot
grub-core/term/i386/pc/console.c:bios_data_area
grub-core/term/ns8250.c:serial_hw_io_addr
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
[2] https://elixir.bootlin.com/linux/v5.16.14/source/include/linux/compiler.h#L180
[3] https://elixir.bootlin.com/linux/v5.16.14/source/include/linux/compiler-gcc.h#L31
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In the function grub_xnu_boot(), struct grub_relocator32_state state is called
but isn't being initialized. This results in the members grub_uint32_t ebx,
grub_uint32_t ecx, grub_uint32_t edx, grub_uint32_t edi, and grub_uint32_t esi
being filled with junk data from the stack since none of them are being set to
any values. We can prevent this by setting state to {0}.
Fixes: CID 375035
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In the function grub_xnu_boot_resume(), struct grub_relocator32_state state is
called but isn't being initialized. This results in the members grub_uint32_t
ebx, grub_uint32_t ecx, grub_uint32_t edx, grub_uint32_t esi, and grub_uint32_t
edi being filled with junk data from the stack since none of them are being set
to any values. We can prevent this by setting state to {0}.
Fixes: CID 375031
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
