Gary Lin [Mon, 25 Mar 2024 02:11:34 +0000 (10:11 +0800)]
util/bash-completion: Fix for bash-completion 2.12
_split_longopt() was the bash-completion private API and removed since
bash-completion 2.12. This commit initializes the bash-completion
general variables with _init_completion() to avoid the potential
"command not found" error.
Although bash-completion 2.12 introduces _comp_initialize() to deprecate
_init_completion(), _init_completion() is still chosen for the better
backward compatibility.
Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
No alignment is guaranteed and in fact on my IA-64 SAPIC is aligned
to 4 bytes instead of 8 and causes a trap. It affects only rarely used
lsacpi command and so went unnoticed.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Michael Chang [Mon, 19 Feb 2024 03:29:11 +0000 (11:29 +0800)]
gfxmenu/view: Resolve false grub_errno disrupting boot process
When enabling gfxmenu and choosing to boot the Xen hypervisor from its
menu, an error occurred:
error: ../../grub-core/video/bitmap_scale.c:42:null src bitmap in grub_video_create_scaled.
The error is returned by grub_video_bitmap_create_scaled() when the
source pixmap is not there. The init_background() uses it to scale up
the background image so it can fully fit into the screen resolution.
However not all backgrounds are set by a image, i.e. the "desktop-image"
property of the theme file. Instead a color code may be used, for
example OpenSUSE's green background uses "desktop-color" property:
desktop-color: "#0D202F"
So it is absolutely fine to call init_background() without a raw pixmap
if color code is used. A missing check has to be added to ensure the
grub_errno will not be erroneously set and gets in the way of ensuing
boot process.
The reason it happens sporadically is due to grub_errno is reset to
GRUB_ERR_NONE in other places if a function's error return can be
ignored. In particular this hunk in grub_gfxmenu_create_box() does the
majority of the reset of grub_errno returned by init_background(), but
the path may not be always chosen.
Jon DeVree [Sun, 11 Feb 2024 15:34:58 +0000 (10:34 -0500)]
fs/xfs: Handle non-continuous data blocks in directory extents
The directory extent list does not have to be a continuous list of data
blocks. When GRUB tries to read a non-existant member of the list,
grub_xfs_read_file() will return a block of zero'ed memory. Checking for
a zero'ed magic number is sufficient to skip this non-existant data block.
Prior to commit 07318ee7e (fs/xfs: Fix XFS directory extent parsing)
this was handled as a subtle side effect of reading the (non-existant)
tail data structure. Since the block was zero'ed the computation of the
number of directory entries in the block would return 0 as well.
Fixes: 07318ee7e (fs/xfs: Fix XFS directory extent parsing) Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2254370 Signed-off-by: Jon DeVree <nuxi@vault24.org> Reviewed-By: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Revert "templates: Reinstate unused version comparison functions with warning"
We reinstated these functions before the 2.12 release with a warning
such that users upgrading to 2.12 who had custom scripts using them
would not get broken in the upgrade and agreed to remove them after
the 2.12 release. This removes them accordingly.
This reverts commit e7a831963 (templates: Reinstate unused version
comparison functions with warning).
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by: Julian Andres Klode <julian.klode@canonical.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Gary Lin [Tue, 30 Jan 2024 06:41:10 +0000 (14:41 +0800)]
util/bash-completion: Load scripts on demand
There are two system directories for bash-completion scripts. One is
/usr/share/bash-completion/completions/ and the other is
/etc/bash_completion.d/. The "etc" scripts are loaded in advance and
for backward compatibility while the "usr" scripts are loaded on demand.
To load scripts on demand it requires a corresponding script for every
command. So, the main bash-completion script is split into several
subscripts for different "grub-*" commands. To share the code the real
completion functions are still implemented in "grub" and each
subscript sources "grub" and invokes the corresponding function.
Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Samuel Thibault [Tue, 23 Jan 2024 20:47:36 +0000 (21:47 +0100)]
osdep/hurd/getroot: Fix 64-bit build
The file_get_fs_options() takes a mach_msg_type_number_t, 32-bit,
not a size_t, 64-bit on 64-bit platforms.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Alec Brown [Sat, 20 Jan 2024 02:52:51 +0000 (02:52 +0000)]
loader/i386/multiboot_mbi: Clean up redundant code
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>
Alec Brown [Sat, 20 Jan 2024 02:52:50 +0000 (02:52 +0000)]
osdep/unix/getroot: Clean up redundant code
In grub-core/osdep/unix/getroot.c, Coverity spotted redundant code where the
double pointer os_dev was being set to 0 and then being overwritten later
without being used. Since this is unnecessary, we can remove the code that
sets os_dev to 0.
Fixes: CID 428875 Signed-off-by: Alec Brown <alec.r.brown@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Alec Brown [Sat, 20 Jan 2024 02:52:49 +0000 (02:52 +0000)]
fs/jfs: Clean up redundant code
In grub-core/fs/jfs.c, Coverity spotted redundant code where the pointer diro
was being set to 0 and then being overwritten later without being used. Since
this is unnecessary, we can remove the code that sets diro to 0.
Fixes: CID 428876 Signed-off-by: Alec Brown <alec.r.brown@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Gary Lin [Fri, 29 Dec 2023 09:08:20 +0000 (17:08 +0800)]
tests: Switch password quality check off for luks2 test
When adding/changing the password for the luks2 partition, cryptsetup
may reject the command due to the weak password. Since this is only for
testing, add "--force-password" to switch password quality check off to
avoid the unexpected failure.
Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Tue, 19 Dec 2023 06:00:01 +0000 (00:00 -0600)]
efi: Add support for reproducible builds
Having randomly generated bytes in the binary output breaks reproducible
builds. Since build timestamps are usually the source of irreproducibility
there is a standard which defines an environment variable SOURCE_DATE_EPOCH
to be used when set for build timestamps. According to the standard [1], the
value of SOURCE_DATE_EPOCH is a base-10 integer of the number of seconds
since the UNIX epoch. Currently, this is a 10 digit number that fits into
32-bits, but will not shortly after the year 2100. So to be future-proof
only use the least significant 32-bits. On 64-bit architectures, where the
canary is also 64-bits, there is an extra 32-bits that can be filled to
provide more entropy. The first byte is NUL to filter out string buffer
overflow attacks and the remaining 24-bits are set to static random bytes.
Glenn Washburn [Tue, 19 Dec 2023 06:00:00 +0000 (00:00 -0600)]
efi: Generate stack protector canary at build time if urandom is available
Generating the canary at build time allows the canary to be different for
every build which could limit the effectiveness of certain exploits.
Fallback to the statically generated random bytes if /dev/urandom is not
readable, e.g. Windows.
On 32-bit architectures, which use a 32-bit canary, reduce the canary to
4 bytes with one byte being NUL to filter out string buffer overflow attacks.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Tue, 19 Dec 2023 05:59:59 +0000 (23:59 -0600)]
efi: Initialize canary to non-zero value
The canary, __stack_chk_guard, is in the BSS and so will get initialized to
zero if it is not explicitly initialized. If the UEFI firmware does not
support the RNG protocol, then the canary will not be randomized and will
be zero. This seems like a possibly easier value to write by an attacker.
Initialize canary to static random bytes, so that it is still random when
there is no RNG protocol. Set at least one byte to NUL to protect against
string buffer overflow attacks [1]. Code that writes NUL terminated strings
will terminate when a NUL is encountered in the input byte stream. So the
attacker will not be able to forge the canary by including it in the input
stream without terminating the string operation and thus limiting the
stack corruption.
Alec Brown [Wed, 13 Dec 2023 22:25:13 +0000 (22:25 +0000)]
gfxmenu/gui_image: Fix double free of bitmap
In grub-core/gfxmenu/gui_image.c, Coverity detected a double free in the
function load_image(). The function checks if self->bitmap and self->raw_bitmap
aren't NULL and then frees them. In the case self->bitmap and self->raw_bitmap
are the same, only self->raw_bitmap is freed which would also free the memory
used by self->bitmap. However, in this case self->bitmap isn't being set to NULL
which could lead to a double free later in the code. After self->raw_bitmap is
freed, it gets set to the variable bitmap. If this variable is NULL, the code
could have a path that would free self->bitmap a second time in the function
rescale_image().
Fixes: CID 292472 Signed-off-by: Alec Brown <alec.r.brown@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Qiumiao Zhang [Mon, 11 Dec 2023 09:20:25 +0000 (17:20 +0800)]
commands/acpi: Fix calculation of ACPI tables addresses when processing RSDT and XSDT
According to the ACPI specification the XSDT Entry field contains an array
of 64-bit physical addresses which points to other DESCRIPTION_HEADERs. However,
the entry_ptr iterator is defined as a 32-bit pointer. It means each 64-bit
entry in the XSDT table is treated as two separate 32-bit entries then. Fix the
issue by using correct addresses sizes when processing RSDT and XSDT tables.
Signed-off-by: Qiumiao Zhang <zhangqiumiao1@huawei.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
There is some variance in how compiler treats sizeof() especially
on 32-bit platforms where it can be naturally either int or long.
Explicit cast solves the issue.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The HAVE_LIBZFS is defined by libzfs test and hence conflicts with
manual definition. On NetBSD it ends up detecting zfs but not detecting
nvpair and creates confusion. Split them.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Wrong function and variable name cause a stupid compilation error on
NetBSD and OpenBSD. Only NetBSD and OpenBSD use this file. No other
platform is affected.
Additionally, define RAW_FLOPPY_MAJOR constant if it is missing.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
build: Tolerate unused-but-set in generated lexer/bison files
We don't really control the small aspects of generated files and NetBSD
version has an unused variable that is then detected by gcc as warning
that is then promoted to error.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
loader/i386/bsdXX: Fix loading after unaligned module
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>
Mate Kukri [Fri, 8 Dec 2023 17:20:12 +0000 (17:20 +0000)]
grub-core/Makefile.am: Make path to extra_deps.lst relative to $(top_srcdir)/grub-core
The commit 154dcb1ae (build: Allow explicit module dependencies) broke
out of tree builds by introducing the extra_deps.lst file into the
source tree but referencing it just by name in grub-core/Makefile.am.
Fix it by adding $(top_srcdir)/grub-core to the path.
Mate Kukri [Fri, 8 Dec 2023 16:57:55 +0000 (16:57 +0000)]
util/grub-install: Move platdir path canonicalization after files were copied to grubdir
The commit 3f9eace2d (util/grub-install: Delay copying files to
{grubdir,platdir} after install_device was validated) delaying
copying of files caused a regression when installing without an
existing directory structure.
This patch ensures that the platform directory actually exists by the
time the code tries to canonicalize its filename.
Fixes: 3f9eace2d (util/grub-install: Delay copying files to {grubdir,platdir} after install_device was validated) Signed-off-by: Mate Kukri <mate.kukri@canonical.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Michael Chang [Wed, 6 Dec 2023 03:42:04 +0000 (11:42 +0800)]
util/grub-mkstandalone: Ensure deterministic tar file creation by sorting contents
The add_tar_files() function currently iterates through a directory's
content using readdir(), which doesn't guarantee a specific order. This
lack of deterministic behavior impacts reproducibility in the build process.
This commit resolves the issue by introducing sorting functionality.
The list retrieved by readdir() is now sorted alphabetically before
incorporation into the tar archive, ensuring consistent and predictable
file ordering within the archive.
On the occasion fix tfp memory leak.
Signed-off-by: Michael Chang <mchang@suse.com> Signed-off-by: Bernhard Wiedemann <bwiedemann@suse.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Michael Chang [Wed, 6 Dec 2023 03:42:03 +0000 (11:42 +0800)]
util/grub-mkstandalone: Ensure stable timestamps for generated images
This change mirrors a previous fix [1] but is specific to images
generated by grub-mkstandalone.
The former fix, commit 85a7be241 (util/mkimage: Use stable timestamp
when generating binaries.), focused on utilizing a stable timestamp
during binary generation in the util/mkimage context. This commit
extends that approach to the images produced by grub-mkstandalone,
ensuring consistency and stability in timestamps across all generated
binaries.
[1] 85a7be241 util/mkimage: Use stable timestamp when generating binaries.
Signed-off-by: Michael Chang <mchang@suse.com> Signed-off-by: Bernhard Wiedemann <bwiedemann@suse.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
templates: Reinstate unused version comparison functions with warning
Revert the commit a79c567f6 (templates: Remove unused version comparison
functions) and add a warning to the functions that they are deprecated.
Removing the functions directly caused a lot of upgrade issues
with custom user scripts that called the functions. In Debian and
Ubuntu, grub-mkconfig is invoked as a post-installation script
and would fail, causing upgrades to fail halfway through and
putting the package manager into an inconsistent state.
FWIW, we get one bug per 2 weeks basically, for an interim Ubuntu
release which generally does not receive much usage, that is a high
number.
The proposal is to pick this for 2.12 and directly after the release
remove it again. Then users will have time to fix their scripts without
systems breaking immediately.
This reverts commit a79c567f6 (templates: Remove unused version
comparison functions).
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by: Julian Andres Klode <julian.klode@canonical.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Mate Kukri [Fri, 24 Nov 2023 08:32:57 +0000 (08:32 +0000)]
util/grub-install: Delay copying files to {grubdir,platdir} after install_device was validated
Previously grub-install copied modules to grubdir before doing any
validation on the install_device.
When grub-install was called with an invalid install_device, modules
were already copied to /boot before it found out and was forced to rely
on atexit() rollback.
This patch delays copying the modules after at least some install_device
validation was done, and thus reduces reliance on successful rollback.
Signed-off-by: Mate Kukri <mate.kukri@canonical.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
efi: Set shim_lock_enabled even if validation is disabled
If validation has been disabled via MokSbState, secure boot on the
firmware is still enabled, and the kernel fails to boot.
This is a bit hacky, because shim_lock is not *fully* enabled, but
it triggers the right code paths.
Ultimately, all this will be resolved by shim gaining it's own image
loading and starting protocol, so this is more a temporary workaround.
Fixes: 6425c12cd (efi: Fallback to legacy mode if shim is loaded on x86 archs) Cc: Peter Jones <pjones@redhat.com> Cc: Michael Chang <mchang@suse.com> Signed-off-by: Julian Andres Klode <julian.klode@canonical.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Oliver Steffen [Thu, 16 Nov 2023 15:37:40 +0000 (16:37 +0100)]
docs: Improve bli module documentation
Improve the documentation of the bli module and explain in more detail what
it does. Make clear that GPT formatted drives are expected and other
partition formats are ignored. Also reorder and reword this section a bit.
Signed-off-by: Oliver Steffen <osteffen@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Oliver Steffen [Thu, 16 Nov 2023 15:37:39 +0000 (16:37 +0100)]
bli: Add explicit dependency on the part_gpt module
The bli module has a "hidden" dependency on the part_gpt module, which
is not picked up automatically by the build system. One purpose of the
bli module is to communicate the GPT UUID of the partition GRUB was
launched from to Linux user-space (systemd-gpt-auto-generator).
Without the part_gpt module, bli is not able to obtain the UUID. Since
bli does its work in the module initialization function, the order in
which the modules are loaded is also important: part_gpt needs to be
loaded before the bli module.
To solve this, track this dependency explicitly.
Note that the Boot Loader Interface specification, which bli aims to
implement, requires GPT formatted drives. The bli module ignores all
other partition formats.
Signed-off-by: Oliver Steffen <osteffen@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Oliver Steffen [Thu, 16 Nov 2023 15:37:38 +0000 (16:37 +0100)]
build: Allow explicit module dependencies
The build system deduces inter-module dependencies from the symbols
required and exported by the modules. This works well, except for some
rare cases where the dependency is indirect or hidden. A module might
not make use of any function of some other module, but still expect its
functionality to be available to GRUB.
To solve this, introduce a new file, currently empty, called extra_deps.lst
to track these cases manually. This file gets processed in the same way
as the automatically generated syminfo.lst, making it possible to inject
data into the dependency resolver.
Since *.lst files are set to be ignored by git, add an exception for
extra_deps.lst.
Additionally, introduce a new keyword for the syminfo.lst syntax:
"depends" allows specifying a module dependency directly:
depends <module> <depdendency>...
Signed-off-by: Oliver Steffen <osteffen@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Stefan Berger [Thu, 30 Nov 2023 14:17:21 +0000 (09:17 -0500)]
loader/powerpc/ieee1275: Use new allocation function for kernel and initrd
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>
Stefan Berger [Thu, 30 Nov 2023 14:17:19 +0000 (09:17 -0500)]
kern/ieee1275/init/ppc64: Rename regions_claim() to grub_regions_claim()
Rename regions_claim() to grub_regions_claim() to make it available for
memory allocation. The ieee1275 loader will use this function on PowerVM
and KVM on Power and thus avoid usage of memory that it is not allowed
to use.
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>
Stefan Berger [Thu, 30 Nov 2023 14:17:18 +0000 (09:17 -0500)]
kern/ieee1275/init/ppc64: Add support for alignment requirements
Add support for memory alignment requirements and adjust a candidate
address to it before checking whether the block is large enough. This
must be done in this order since the alignment adjustment can make
a block smaller than what was requested.
None of the current callers has memory alignment requirements but the
ieee1275 loader for kernel and initrd will use it to convey them.
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>
Stefan Berger [Thu, 30 Nov 2023 14:17:17 +0000 (09:17 -0500)]
kern/ieee1275/init/ppc64: Return allocated address using context
Return the allocated address of the memory block in the request structure
if a memory allocation was actually done. Leave the address untouched
otherwise. This enables a caller who wants to use the allocated memory
directly, rather than adding the memory to the heap, to see where memory
was allocated. None of the current callers need this but the converted
ieee1275 loader will make use of it.
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>
Stefan Berger [Thu, 30 Nov 2023 14:17:16 +0000 (09:17 -0500)]
kern/ieee1275/init/ppc64: Decide by request whether to initialize region
Let the regions_claim() request structure's init_region determine whether
to call grub_mm_init_region() on it. This allows for adding memory to
GRUB's memory heap if init_region is set to true, or direct usage of the
memory otherwise. Set all current callers' init_region to true since they
want to add memory regions to GRUB's heap.
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>
Stefan Berger [Thu, 30 Nov 2023 14:17:15 +0000 (09:17 -0500)]
kern/ieee1275/init/ppc64: Introduce a request for regions_claim()
The regions_claim() function limits the allocation of memory regions
by excluding certain memory areas from being used by GRUB. This for
example includes a gap between 640MB and 768MB as well as an upper
limit beyond which no memory may be used when an fadump is present.
However, the ieee1275 loader for kernel and initrd currently does not
use regions_claim() for memory allocation on PowerVM and KVM on Power
and therefore may allocate memory in those areas that it should not use.
To make the regions_claim() function more flexible and ultimately usable
for the ieee1275 loader, introduce a request structure to pass various
parameters to the regions_claim() function that describe the properties
of requested memory chunks. In a first step, move the total and flags
variables into this structure.
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>
fs/xfs: Add large extent counters incompat feature support
XFS introduced 64-bit extent counters for inodes via a series of
upstream commits and the feature was marked as stable in v6.5 via
commit 61d7e8274cd8 (xfs: drop EXPERIMENTAL tag for large extent
counts).
Further, xfsprogs release v6.5.0 switched this feature on by default
in mkfs.xfs via commit e5b18d7d1d96 (mkfs: enable large extent counts
by default).
Filesystems formatted with large extent count support, nrext64=1, are
thus currently not recognizable by GRUB, since this is an incompat
feature. Add the required support so that those filesystems and inodes
with large extent counters can be read by GRUB.
Signed-off-by: Anthony Iliopoulos <ailiop@suse.com> Reviewed-by: Andrey Albershteyn <aalbersh@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Tested-by: Marta Lewandowska <mlewando@redhat.com> Tested-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
gpt: Add compile time asserts for guid and gpt_partentry sizes
With new alignment specification it's easy to screw up. Fortunately if it
happens the size will be bigger than intended. Compile time assert will catch
this.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.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>
gpt_partition: Mark grub_gpt_partentry as having natural alignment
gpt_partition contains grub_guid. We need to decide whether the whole
structure is unaligned and then we need to use packed_guid. But we never
have unaligned part entries as we read them in an aligned buffer from disk.
Hence just make it all aligned.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
efi: Deduplicate configuration table search function
We do table search in many places doing exactly the same algorithm.
The only minor variance in users is which table is used if several entries
are present. As specification mandates uniqueness and even if it ever isn't,
first entry is good enough, unify this code and always use the first entry.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Qiumiao Zhang [Wed, 25 Oct 2023 03:54:57 +0000 (11:54 +0800)]
util/grub-mount: Check file path sanity
The function argp_parser() in util/grub-mount.c lacks a check on the
sanity of the file path when parsing parameters. This results in
a segmentation fault if a partition is mounted to a non-existent path.
Signed-off-by: Qiumiao Zhang <zhangqiumiao1@huawei.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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>
projects / thirdparty / grub.git / log
