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>
Most of leftover code blindly assumes GRUB_RELOCATOR_FIRMWARE_REQUESTS_QUANT
divisibility by 8. So, enforce this at compile time.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.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>
These should be quite obvious and will make the SDL2 patch easier
to read then doing it inline there.
Signed-off-by: Julian Andres Klode <julian.klode@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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>
Currently bootstrap complains in the following way when
patching gnulib files:
patching file argp-help.c
Hunk #1 succeeded at 52 (offset 1 line).
Hunk #2 succeeded at 1548 (offset 115 lines).
patching file mbswidth.c
patching file mbswidth.h
Hunk #1 succeeded at 40 (offset -5 lines).
Let's fix it by amending line numbers in the patch.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Alec Brown <alec.r.brown@oracle.com>
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>
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>
Use PRIxGRUB_INT64_T format specifier for grub_int64_t type
and drop redundant casts.
Signed-off-by: Xiaotian Wu <wuxiaotian@loongson.cn>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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>
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>
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>
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>
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>
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>
Add a new module named bli. It implements a small but quite useful part
of the Boot Loader Interface [0]. This interface uses EFI variables for
communication between the boot loader and the operating system.
When loaded, this module sets two EFI variables under the vendor GUID
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f:
- LoaderInfo: contains GRUB + <version number>.
This allows the running operating system to identify the boot loader
used during boot.
- LoaderDevicePartUUID: contains the partition UUID of the EFI System
Partition (ESP). This is used by systemd-gpt-auto-generator [1] to
find the root partitions (and others too), via partition type IDs [2].
This module is available on EFI platforms only. The bli module relies on
the part_gpt module which has to be loaded beforehand to make the GPT
partitions discoverable.
Update the documentation, add a new chapter "Modules" and describe the
bli module there.
[0] https://systemd.io/BOOT_LOADER_INTERFACE/
[1] https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html
[2] https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add checks for NULL pointers to grub_device_close() and
grub_disk_close() to make these functions more robust.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add a function that sets an EFI variable to a string value.
The string is converted from UTF-8 to UTF-16.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Create a new function for UTF-8 to UTF-16 conversion called
grub_utf8_to_utf16_alloc() in the grub-code/kern/misc.c and replace
charset conversion code used in some places in the EFI code. It is
modeled after the grub_utf8_to_ucs4_alloc() like functions in
include/grub/charset.h. It can't live in include/grub/charset.h,
because it needs to be reachable from the kern/efi code.
Add a check for integer overflow and remove redundant NUL-termination.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
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>
Extend the printf format specifier for pointers (%p) to accept a suffix
specifier G to print GUIDs: %pG can be used to print grub_guid structs.
This does not interfere with the -Wformat checking of gcc. Note that
the data type is not checked though (%p accepts void *).
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>
Add a function to the EFI module that allows setting EFI variables
with specific attributes.
This is useful for marking variables as volatile, for example.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In grub-core/kern/efi/mm.c, grub_efi_finish_boot_services() has an instance
where the memory for the variable finish_mmap_buf is freed, but on the next
iteration of a while loop, grub_efi_get_memory_map() uses finish_mmap_buf. To
prevent this, we can set finish_mmap_buf to NULL after the free.
Signed-off-by: Alec Brown <alec.r.brown@oracle.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>
The call wrappers are no longer needed now that GCC can generate
function calls using MS calling convention, so let's get rid of them.
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>
UEFI mandates MS calling convention on x86_64, which was not supported
on GCC when UEFI support was first introduced into GRUB. However, now we
can use the ms_abi function type attribute to annotate functions and
function pointers as adhering to the MS calling convention, and the
compiler will generate the correct instruction sequence for us.
So let's add the appropriate annotation to all the function prototypes.
This will allow us to drop the special call wrappers in a subsequent patch.
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>
The return value of grub_loongarch64_stack_pop() is unsigned, so -1 should
not be used in the first place. Replacing with 0 is enough to avoid the
UB in this edge case.
Technically though, proper error handling is needed throughout the
management of the reloc stack, so no unexpected behavior will happen
even in case of malformed object code input (right now, pushes become
no-ops when the stack is full, and garbage results if the stack does not
contain enough operands for an op). The refactor would touch some more
places so would be best done in a separate series.
Fixes: CID 407777
Fixes: CID 407778
Signed-off-by: WANG Xuerui <git@xen0n.name>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Loosely based on early_pci_serial_init() from Linux, allow GRUB to make
use of PCI serial devices.
Specifically, my Alderlake NUC exposes the Intel AMT SoL UART as a PCI
enumerated device but doesn't include it in the EFI tables.
Tested and confirmed working on a "Lenovo P360 Tiny" with Intel AMT
enabled. This specific machine has (from lspci -vv):
00:16.3 Serial controller: Intel Corporation Device 7aeb (rev 11) (prog-if 02 [16550])
DeviceName: Onboard - Other
Subsystem: Lenovo Device 330e
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin D routed to IRQ 19
Region 0: I/O ports at 40a0 [size=8]
Region 1: Memory at b4224000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: serial
From which the following config (/etc/default/grub) gets a working
serial setup:
GRUB_CMDLINE_LINUX="console=tty0 earlyprintk=pciserial,00:16.3,115200 console=ttyS0,115200"
GRUB_SERIAL_COMMAND="serial --port=0x40a0 --speed=115200"
GRUB_TERMINAL="serial console"
Documentation is added to note that serial devices found on the PCI bus will
be exposed as "pci,XX:XX.X" and how to find serial terminal logical names.
Also, some minor documentation improvements were added.
This can be tested in QEMU by adding a pci-serial device, e.g. using the option
"-device pci-serial".
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Glenn Washburn <development@efficientek.com>
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
On failure to allocate from grub_relocator_firmware_alloc_region() in
malloc_in_range() the function would stop enforcing the alignment, and
the following was returned:
lib/relocator.c:431: trying to allocate in 0x200000-0xffbf9fff aligned 0x200000 size 0x406000
lib/relocator.c:1197: allocated: 0x74de2000+0x406000
lib/relocator.c:1407: allocated 0x74de2000/0x74de2000
Fix this by making sure that target always contains a suitably aligned
address. After the change the return from the function is:
lib/relocator.c:431: trying to allocate in 0x200000-0xffb87fff aligned 0x200000 size 0x478000
lib/relocator.c:1204: allocated: 0x74c00000+0x478000
lib/relocator.c:1414: allocated 0x74c00000/0x74c00000
Fixes: 3a5768645c (First version of allocation from firmware)
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The access_size is part of a union, so doesn't technically exist for
a PIO port (i.e., not MMIO), but we set it anyways.
This doesn't cause a bug today because the other leg of the union
doesn't have anything overlapping with it now, but it's bad, I will
punish myself for writing it that way :-) In the meantime, fix this
and actually name the struct inside the union for clarity of intent
and to avoid such issue in the future.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When an invalid node size is detected in grub_hfsplus_mount(), data
pointer is freed. Thus, file->data is not set. The code should also
set the grub_errno when that happens to indicate an error and to avoid
accessing the uninitialized file->data in grub_file_close().
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When trying to resolve DNS names into IP addresses, the DNS code fails
from time to time with the following error:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
error: ../../grub-core/net/dns.c:688:no DNS record found.
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
This happens when both IPv4 and IPv6 queries are performed against the
DNS server (e.g. 8.8.8.8) but there is no IP returned for IPv6 query, as
shown below:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
grub> net_del_dns 192.168.122.1
grub> net_add_dns 8.8.8.8
grub> net_nslookup ipv4.test-ipv6.com
error: ../../grub-core/net/dns.c:688:no DNS record found.
grub> net_nslookup ipv4.test-ipv6.com
216.218.228.115
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
The root cause is the code exiting prematurely when the data->addresses
buffer has been allocated in recv_hook(), even if there was no address
returned last time recv_hook() executed.
Signed-off-by: Renaud Métrich <rmetrich@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn