The option can be used to suppress output if we only want to test the
return value of the command.
Also, mention this option in the documentation.
Signed-off-by: Michael Chang <mchang@suse.com>
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Switching to another EFI boot application while there are secrets in
RAM is dangerous, because not all firmware is wiping memory on free.
To reduce the attack surface, wipe the passphrase acquired when
unlocking an encrypted volume.
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This commit adds the grub_cryptodisk_erasesecrets() function to wipe
master keys from all cryptodisks. This function is EFI-only.
Since there is no easy way to "force unmount" a given encrypted disk,
this function renders all mounted cryptodisks unusable. An attempt to
read them will return garbage.
This is why this function must be used in "no way back" conditions.
Currently, it is used when unloading the cryptodisk module and when
performing the "exit" command (it is often used to switch to the next
EFI application). This function is not called when performing the
"chainloader" command, because the callee may return to GRUB. For this
reason, users are encouraged to use "exit" instead of "chainloader" to
execute third-party boot applications.
This function does not guarantee that all secrets are wiped from RAM.
Console output, chunks from disk read requests and other may remain.
This function does not clear the IV prefix and rekey key for geli disks.
Also, this commit adds the relevant documentation improvements.
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Document the --cryptodisk-only argument. Also, document the
"cryptocheck" command invoked when that argument is processed.
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When the --cryptodisk-only argument is given, also check the target
device using the "cryptocheck" command, if available.
This extends the checks to common layouts like LVM-on-LUKS, so the
--cryptodisk-only argument transparently handles such setups.
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This command examines a given diskfilter device, e.g., an LVM disk,
and checks if underlying disks, physical volumes, are cryptodisks,
e.g., LUKS disks, this layout is called "LVM-on-LUKS".
The return value is 0 when all underlying disks (of a given device)
are cryptodisks (1 if at least one disk is unencrypted or in an
unknown state).
Users are encouraged to include the relevant check before loading
anything from an LVM disk that is supposed to be encrypted.
This further supports the CLI authentication, blocking bypass
attempts when booting from an encrypted LVM disk.
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This allows users to restrict the "search" command's scope to
encrypted disks only.
Typically, this command is used to "rebase" $root and $prefix
before loading additional configuration files via "source" or
"configfile". Unfortunately, this leads to security problems,
like CVE-2023-4001, when an unexpected, attacker-controlled
device is chosen by the "search" command.
The --cryptodisk-only argument allows users to ensure that the
file system picked is encrypted.
This feature supports the CLI authentication, blocking bypass
attempts.
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This further mitigates potential misuse of the CLI after the
root device has been successfully unlocked via TPM.
Fixes: CVE-2025-4382
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When large extent counter / NREXT64 support was added to GRUB, it missed
a couple of direct reads of nextents which need to be changed to the new
NREXT64-aware helper as well. Without this, we'll have mis-reads of some
directories with this feature enabled.
The large extent counter fix likely raced on merge with commit 07318ee7e
(fs/xfs: Fix XFS directory extent parsing) which added the new direct
nextents reads just prior, causing this issue.
Fixes: aa7c132267 (fs/xfs: Add large extent counters incompat feature support)
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Anthony Iliopoulos <ailiop@suse.com>
Reviewed-by: Jon DeVree <nuxi@vault24.org>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
RAID 4 requires the same recovery module as RAID 5. Extend the condition to
cover both RAID levels.
Signed-off-by: Egor Ignatov <egori@altlinux.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The code goes on to allocate memory in another region on failure, hence
it should discard the error.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Other platforms specify license in platform-specific files but corresponding
code for emu is in kernel, so datetime ends up without license section.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Without this option compiler sometimes emits R_RISCV_ALIGN relocs.
Unlike other relocs this one requires the linker to do NOP deletions
and we can't ignore them. Just instruct compiler not to emit them.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add the long options of tpm2_key_protect_init along with the short options.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The TPM2 key protector tests require two external packages: swtpm-tools
and tpm2-tools. Add those two packages to the INSTALL file to inform
the user to install those packages before starting the TPM2 key protector
tests.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
This commit updates the NV index mode section and the grub-protect
section to reflect the recent changes in TPM2 key protector and
grub-protect.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Two more NV index test cases are added to test key sealing and
unsealing with the NV index handle 0x1000000.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reset "ret" to 0 when a test case fails so that the other test cases
could continue.
Also set the exit status to 1 when encountering a failure to reflect the
test result.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Since grub-protect already supports NV index mode, tpm2_seal_nv() is
replaced with one grub-protect command to simplify the test script.
"tpm2_evictcontrol" is also replaced with "grub-protect --tpm2-evict".
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This commit implements the missing NV index mode support in grub-protect.
NV index mode stores the sealed key in the TPM non-volatile memory (NVRAM)
instead of a file. There are two supported types of TPM handles.
1. Persistent handle (0x81000000~0x81FFFFFF)
Only the raw format is supported due to the limitation of persistent
handles. This grub-protect command seals the key into the
persistent handle 0x81000000.
# grub-protect \
--protector=tpm2 \
--action=add \
--tpm2-bank=sha256 \
--tpm2-pcrs=7,11 \
--tpm2-keyfile=luks-key \
--tpm2-nvindex=0x81000000
2. NV index handle (0x1000000~0x1FFFFFF)
Both TPM 2.0 Key File format and the raw format are supported by NV
index handles. Here is the grub-protect command to seal the key in
TPM 2.0 Key File format into the NV index handle 0x1000000.
# grub-protect \
--protector=tpm2 \
--action=add \
--tpm2key \
--tpm2-bank=sha256 \
--tpm2-pcrs=7,11 \
--tpm2-keyfile=luks-key \
--tpm2-nvindex=0x1000000
Besides the "add" action, the corresponding "remove" action is also
introduced. To remove the data from a persistent or NV index handle,
just use "--tpm2-nvindex=HANDLE" combining with "--tpm2-evict". This
sample command removes the data from the NV index handle 0x1000000.
# grub-protect \
--protector=tpm2 \
--action=remove \
--tpm2-evict \
--tpm2-nvindex=0x1000000
Also set and check the boolean variables with true/false instead of 1/0.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Previously, NV index mode only supported persistent handles which are
only for TPM objects.
On the other hand, the "NV index" handle allows the user-defined data,
so it can be an alternative to the key file and support TPM 2.0 Key
File format immediately.
The following tpm2-tools commands store the given key file, sealed.tpm,
in either TPM 2.0 Key File format or the raw format into the NV index
handle 0x1000000.
# tpm2_nvdefine -C o \
-a "ownerread|ownerwrite" \
-s $(stat -c %s sealed.tpm) \
0x1000000
# tpm2_nvwrite -C o -i sealed.tpm 0x1000000
To unseal the key in GRUB, add the "tpm2_key_protector_init" command to
grub.cfg:
tpm2_key_protector_init --mode=nv --nvindex=0x1000000
cryptomount -u <UUID> --protector tpm2
To remove the NV index handle:
# tpm2_nvundefine -C o 0x1000000
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Extract the logic to handle the file buffer from the SRK recover
function to prepare to load the sealed key from the NV index handle,
so the NV index mode can share the same code path in the later patch.
The SRK recover function now only reads the file and sends the file
buffer to the new function.
Besides this, to avoid introducing more options for the NV index mode,
the file format is detected automatically before unmarshaling the data,
so there is no need to use the command option to specify the file format
anymore. In other words, "-T" and "-k" are the same now.
Also update grub.text to address the change.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The following TPM 2.0 commands are introduced to tss2 to access the
TPM non-volatile memory associated with the NV index handles:
- TPM2_NV_DefineSpace,
- TPM2_NV_UndefineSpace,
- TPM2_NV_ReadPublic,
- TPM2_NV_Read,
- TPM2_NV_Write.
The related marshal/unmarshal functions are also introduced.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
grub_tpm2_readpublic() and grub_tpm2_testparms() didn't check
authCommand when marshaling the input data buffer. Currently, there is
no caller using non-NULL authCommand. However, to avoid the potential
issue, the conditional check is added to insert authCommand into the
input buffer if necessary.
Also fix a few pointer checks.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The user may need to inspect the TPM 2.0 PCR values with the GRUB shell,
so the new tpm2_dump_pcr command is added to print all PCRs of the
specified bank.
Also update the document for the new command.
Signed-off-by: Gary Lin <glin@suse.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
PCR mismatch is one common cause of TPM key unsealing fail. Since the
system may be compromised, it is not safe to boot into OS to get the PCR
values and TPM eventlog for the further investigation.
To provide some hints, GRUB now dumps PCRs on policy fail, so the user
can check the current PCR values. PCR 0~15 are chosen to cover the
firmware, bootloader, and OS.
The sample output:
PCR Mismatch! Check firmware and bootloader before typing passphrase!
TPM PCR [sha256]:
00: 17401f37710984c1d8a03a81fff3ab567ae9291bac61e21715b890ee28879738
01: 7a114329ba388445a96e8db2a072785937c1b7a8803ed7cc682b87f3ff3dd7a8
02: 11c2776849e8e24b7d80c926cbc4257871bffa744dadfefd3ed049ce25143e05
03: 6c33b362073e28e30b47302bbdd3e6f9cee4debca3a304e646f8c68245724350
04: 62d38838483ecfd2484ee3a2e5450d8ca3b35fc72cda6a8c620f9f43521c37d1
05: d8a85cb37221ab7d1f2cc5f554dbe0463acb6784b5b8dc3164ccaa66d8fff0e1
06: 9262e37cbe71ed4daf815b4a4881fb7251c9d371092dde827557d5368121e10e
07: 219d542233be492d62b079ffe46cf13396a8c27e520e88b08eaf2e6d3b7e70f5
08: de1f61c973b673e505adebe0d7e8fb65fde6c24dd4ab4fbaff9e28b18df6ecd3
09: c1de7274fa3e879a16d7e6e7629e3463d95f68adcfd17c477183846dccc41c89
10: 0000000000000000000000000000000000000000000000000000000000000000
11: 0000000000000000000000000000000000000000000000000000000000000000
12: 0000000000000000000000000000000000000000000000000000000000000000
13: 0000000000000000000000000000000000000000000000000000000000000000
14: 9ab9ebe4879a7f4dd00c04f37e79cfd69d0dd7a8bcc6b01135525b67676a3e40
15: 0000000000000000000000000000000000000000000000000000000000000000
16: 0000000000000000000000000000000000000000000000000000000000000000
17: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
18: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
19: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
20: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
21: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
22: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
23: 0000000000000000000000000000000000000000000000000000000000000000
error: failed to unseal sealed key (TPM2_Unseal: 0x99d).
error: no key protector provided a usable key for luks (af16e48f-746b-4a12-aae1-c14dcee429e0).
If the user happens to have the PCR values for key sealing, the PCR dump
can be used to identify the changed PCRs and narrow down the scope for
closer inspection.
Please note that the PCR dump is trustworthy only if the GRUB binary is
authentic, so the user has to check the GRUB binary thoroughly before
using the PCR dump.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Update linux_kernel_params to match the v6.13.7 upstream version of boot_params.
Refactor most things out into structs, as the Linux kernel does.
edid_info should be a struct with "unsigned char dummy[128]" and efi_info should
be a struct as well, starting at 0x1c0. However, for backwards compatibility,
GRUB can have efi_systab at 0x1b8 and padding at 0x1bc (or padding at both spots).
This cuts into the end of edid_info. Make edid_info inline and only make it go
up to 0x1b8.
Signed-off-by: Patrick Colp <patrick.colp@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In grub_xnu_load_kext_from_dir(), when the call to grub_device_open()
failed, it simply cleaned up previously allocated memory and returned
GRUB_ERR_NONE. However, it neglected to free ctx->newdirname which is
allocated before the call to grub_device_open().
Fixes: CID 473859
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In grub_cmd_initrd(), initrd_ctx is allocated before calling
grub_relocator_alloc_chunk_align(). When that function fails,
initrd_ctx should be freed before exiting grub_cmd_initrd().
Fixes: CID 473852
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Fix memory leaks in make_vg() with new helper functions, free_pv()
and free_lv(). Additionally, correct a check after allocating
comp->segments->nodes that mistakenly checked lv->segments->nodes
instead, likely due to a copy-paste error.
Fixes: CID 473878
Fixes: CID 473884
Fixes: CID 473889
Fixes: CID 473890
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
A regression was introduced recently as a part of the series of
filesystem related patches to address some CVEs found in GRUB.
This issue may cause either an infinite loop at startup when
accessing certain valid NTFS filesystems, or may cause a crash
due to a NULL pointer dereference on systems where NULL address
is invalid (such as may happen when calling grub-mount from
the operating system level).
Correct this issue by checking that at->attr_cur is within bounds
inside find_attr().
Fixes: https://savannah.gnu.org/bugs/?66855
Fixes: aff263187 (fs/ntfs: Fix out-of-bounds read)
Signed-off-by: B Horn <b@horn.uk>
Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
The grub_malloc() has been inadvertently removed from the code after it
has been modified to use safe math functions.
Fixes: 4beeff8a (net: Use safe math macros to prevent overflows)
Signed-off-by: Nicolas Frayer <nfrayer@redhat.com>
Tested-by: Marta Lewandowska <mlewando@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Change RMA size from 512 MB to 768 MB which will result in more memory
at boot time for PowerPC. When vTPM, Secure Boot or FADump are enabled
on PowerPC the 512 MB RMA memory is not sufficient for boot. With this
512 MB RMA, GRUB runs out of memory and fails to boot the machine.
Sometimes even usage of CDROM requires more memory for installation and
along with the options mentioned above exhausts the boot memory which
results in boot failures. Increasing the RMA size will resolves multiple
out of memory issues observed on PowerPC machines.
Failure details (GRUB debug console dump):
kern/ieee1275/init.c:550: mm requested region of size 8513000, flags 1
kern/ieee1275/init.c:563: Cannot satisfy allocation and retain minimum runtime space
kern/ieee1275/init.c:550: mm requested region of size 8513000, flags 0
kern/ieee1275/init.c:563: Cannot satisfy allocation and retain minimum runtime space
kern/file.c:215: Closing `/ppc/ppc64/initrd.img' ...
kern/disk.c:297: Closing `ieee1275//vdevice/v-scsi@30000067/disk@8300000000000000'...
kern/disk.c:311: Closing `ieee1275//vdevice/v-scsi@30000067/disk@8300000000000000' succeeded.
kern/file.c:225: Closing `/ppc/ppc64/initrd.img' failed with 3.
kern/file.c:148: Opening `/ppc/ppc64/initrd.img' succeeded.
error: ../../grub-core/kern/mm.c:552:out of memory.
Signed-off-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Without this fix the GRUB failed to boot linux with "out of memory" after
trying to run a "search --fs-uuid..." on a system that has 7 ZFS pools
across about 80 drives.
Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This removes a lot of empty grub-shell working directories in the TMPDIR directory.
Signed-off-by: Thomas Schmitt <scdbackup@gmx.net>
Signed-off-by: Glenn Washburn <development@efficientek.com>
Tested-by: Thomas Schmitt <scdbackup@gmx.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
grub_cmd_cryptomount creates a directory per subtest. If a subtest is
successful and debugging is not on, the directory should be empty.
So, it can be deleted.
Signed-off-by: Thomas Schmitt <scdbackup@gmx.net>
Signed-off-by: Glenn Washburn <development@efficientek.com>
Tested-by: Thomas Schmitt <scdbackup@gmx.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This fixes behavior where grub_cmd_cryptomount temporary files, which are
some times not cleaned up, are left in the / directory. Set TMPDIR if your
system does not have /tmp or it can not be used for some reason.
Reported-by: Thomas Schmitt <scdbackup@gmx.net>
Signed-off-by: Glenn Washburn <development@efficientek.com>
Tested-by: Thomas Schmitt <scdbackup@gmx.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This fixes an issue where the grub_cmd_cryptomount test leaves a file
with an ambiguous name in the / directory when TMPDIR is not set.
Reported-by: Thomas Schmitt <scdbackup@gmx.net>
Signed-off-by: Glenn Washburn <development@efficientek.com>
Tested-by: Thomas Schmitt <scdbackup@gmx.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
grub-shell-luks-tester only cleans up generated files when the test it
runs returns success. Sometimes tests are run that should fail. Add
a --xfail argument to grub-shell-luks-tester and pass it from
grub_cmd_cryptomount when invoking a test that is expected to fail.
Reported-by: Thomas Schmitt <scdbackup@gmx.net>
Signed-off-by: Glenn Washburn <development@efficientek.com>
Tested-by: Thomas Schmitt <scdbackup@gmx.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Set the RET variable to the exit status of the script, as was assumed in
the cleanup() function.
Reported-by: Thomas Schmitt <scdbackup@gmx.net>
Signed-off-by: Glenn Washburn <development@efficientek.com>
Tested-by: Thomas Schmitt <scdbackup@gmx.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
GRUB has the capability to search all the disks for a cryptodisk of a
given UUID. Use this instead of hardcoding which disk is the cryptodisk,
which can change when devices are added or removed, or potentially when
QEMU is upgraded. This can not be done for the detached header tests
because the header contains the UUID.
Also, capitalize comment lines for consistency.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Fix a regression where qemuopts was mistakenly defaulted to the empty
string. This prevents the sending of arbitrary QEMU options to tests,
which may be desirable for overriding the machine type. There was a
concern that allowing the tester to accept arbitrary options would add
headaches for another developer trying to diagnose why a test failed on
the testers machine because he could not be sure if any additional
options were passed to make the test fail. However, all the options are
recorded in the run.sh generated script, so this concern is unwarranted.
Fixes: 6d729ced70 (tests/util/grub-shell: Add $GRUB_QEMU_OPTS to run.sh to easily see unofficial QEMU arguments)
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Mark cachevol LV's as ignored features, which is true only if they are
configured as "writethrough". This patch does not let GRUB boot from
"writeback" cache-enabled LV's.
Signed-off-by: Patrick Plenefisch <simonpatp@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The LV matching must be done after processing the ignored feature
indirections, as integrity volumes & caches may have several levels
of indirection that the segments must be shifted through.
Signed-off-by: Patrick Plenefisch <simonpatp@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The PV matching must be completely finished before validating a volume,
otherwise referenced RAID stripes may not have PV data applied yet.
This change is required for integrity & cachevol support.
Signed-off-by: Patrick Plenefisch <simonpatp@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The cache_pool is never read or used, remove it.
Signed-off-by: Patrick Plenefisch <simonpatp@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch isn't necessary by itself, but when combined with subsequent
patches it enhances readability as ignored_features_lv is then used for
multiple types of extra LV's, not just cache LV's.
Signed-off-by: Patrick Plenefisch <simonpatp@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Like the GNU ls, first print a line with the directory path before printing
files in the directory, which will not have a directory component, but only
if there is more than one argument.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
For arguments that are paths to files, print the full path of the file.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The modification time for paths to files was not being printed because
the grub_dirhook_info, which contains the mtime, was initialized to NULL.
Instead of calling print_file() directly, use fs->fs_dir() to call
print_file() with a properly filled in grub_dirhook_info. This has the
added benefit of reducing code complexity.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Simplify the code by removing logic around which file printer to call.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Update documentation to capture that all memrw commands, the minicmd
dump command, and raw memory dumping via hexdump are restricted when
lockdown is enabled. This aligns to recent GRUB code updates.
Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Document which filesystems are not allowed when lockdown
is enabled to align to recent GRUB changes.
Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
FreeBSD loader always passes "elf kernel". We currently pass "elf64 kernel"
when loading 64-bit kernel. The -CURRENT, HEAD, kernel accepts only
"elf kernel". Older kernel accepts either.
Tested with FreeBSD and DragonFlyBSD.
Reference: https://cgit.freebsd.org/src/commit/?id=b72ae900d4348118829fe04abdc11b620930c30f
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When using syntax "hd0,gtp3,dfly1" then ptr points to trailing part, ",dfly1".
So, it's improper to consider it as an invalid partition.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
grub-core/lib/tss2/tss2_structs.h contains a duplicate typedef as follows:
typedef TPMS_SCHEME_HASH_t TPMS_SCHEME_KDF2_t;
This causes a build failure when compiling with clang. Remove the
duplicate typedef which allows successfully building GRUB with clang.
Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Reviewed-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The grub_script_execute_sourcecode() parses and executes code one line
at a time, updating the return code each time because only the last line
determines the final status. However, trailing new lines were also
executed, masking any failure on the previous line. Fix this by only
trying to execute the command when there is actually one present.
This has presumably never been noticed because this code is not used by
regular functions, only in special cases like eval and menu entries. The
latter generally don't return at all, having booted an OS. When failing
to boot, upstream GRUB triggers the fallback mechanism regardless of the
return code.
We noticed the problem while using Red Hat's patches, which change this
behaviour to take account of the return code. In that case, a failure
takes you back to the menu rather than triggering a fallback.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The commit 504058e8 (libtasn1: Compile into asn1 module) generates files
into the grub-core/lib/libtasn1-grub directory and commit 99cda678
(asn1_test: Test module for libtasn1) generates files into the
grub-core/tests/asn1/tests directory. Ignore these directories as they
are not under revision control.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
On systems which support multiple boot platforms such as BIOS and
EFI, it makes no sense to show menu entries which are not supported
by the current boot platform. Menu entries generated from os-prober
"chain" boot type use boot sector chainloading which is supported
on PC BIOS platform only.
Show "chain" menu entries only if boot platform is PC BIOS.
Show "efi" menu entries only if boot platform is EFI.
This is aimed to allow os-prober to report both EFI and PC BIOS
boot loaders regardless of the current boot mode on x86 systems
which support both EFI and legacy BIOS boot, in order to generate
a config file which can be used with either BIOS or EFI boot.
Signed-off-by: Pascal Hambourg <pascal@plouf.fr.eu.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
GRUB documentation states:
GRUB_OS_PROBER_SKIP_LIST
List of space-separated FS UUIDs of filesystems to be ignored from
os-prober output. For efi chainloaders it’s <UUID>@<EFI FILE>
But the actual behaviour does not match this description.
GRUB_OS_PROBER_SKIP_LIST="<UUID>"
does nothing. In order to skip non-EFI bootloaders, you must set
GRUB_OS_PROBER_SKIP_LIST="<UUID>@<DEVICE>"
which is both absurd, <UUID> and <DEVICE> are redundant, and wrong,
<DEVICE> such as /dev/sd* may not be persistent across boots.
Also, any non-word character is accepted as a separator, including "-"
and "@" which may be present in UUIDs. This can cause false positives
because of partial UUID match.
This patch fixes these flaws while retaining some backward compatibility
with previous behaviour which may be expected by existing setups:
- also accept <UUID>@/dev/* (with warning) for non-EFI bootloaders,
- also accept comma and semicolon as separator.
Fixes: 55e706c9 (Add GRUB_OS_PROBER_SKIP_LIST to selectively skipping systems)
Signed-off-by: Pascal Hambourg <pascal@plouf.fr.eu.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This appears to be a relic from GRUB legacy that used a --dumb option for
its terminal command. The proper way to do this in GRUB2 is to set the
terminal to "dumb" via the terminfo command.
Fixes: https://savannah.gnu.org/bugs/?66302
Reported-by: Jernej Jakob <jernej.jakob+savgnu@gmail.com>
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Support for @lbracechar{} and @rbracechar{} was added in GNU Texinfo 5.0
but many older systems may have versions lower than this. Use @{ and @}
to support a wider range of GNU Texinfo versions.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Commit ef7850c757 (fs/xfs: Fix issues found while fuzzing the XFS
filesystem) introduced multiple boundary checks in grub_xfs_iterate_dir()
but handled the error incorrectly returning error code instead of 0.
Fix it. Also change the error message so that it doesn't match the
message in grub_xfs_read_inode().
Fixes: ef7850c757 (fs/xfs: Fix issues found while fuzzing the XFS filesystem)
Signed-off-by: Egor Ignatov <egori@altlinux.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The Linux port of XFS added a few new features in 2024. The existing
GRUB driver doesn't attempt to read or write any of the new metadata,
so, all three can be added to the incompat allowlist.
On the occasion align XFS_SB_FEAT_INCOMPAT_NREXT64 value.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Previously, the number of extent entries was not properly capped based
on the actual available space. This could lead to insufficient reads for
external extents since the computation was based solely on the inline
extent layout.
In this patch, when processing the extent header we determine whether
the header is stored inline, i.e. at inode->blocks.dir_blocks, or in an
external extent block. We then clamp the number of entries accordingly
(using max_inline_ext for inline extents and max_external_ext for
external extent blocks).
This change ensures that only the valid number of extent entries is
processed preventing out-of-bound reads and potential filesystem
corruption.
Fixes: 7e2f750f0a (fs/ext2: Fix out-of-bounds read for inline extents)
Signed-off-by: Michael Chang <mchang@suse.com>
Tested-by: Christian Hesse <mail@eworm.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The conditional makes no sense when the two possible expressions have
the same value, so, remove it (perhaps the compiler does it for us but
better to remove it). This change makes spinup argument unused. So, drop
it as well.
Signed-off-by: Leo Sandoval <lsandova@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The Microsoft spec for SPCR says "The base address of the Serial Port
register set described using the ACPI Generic Address Structure, or
0 if console redirection is disabled". So, return early if redirection
is disabled (base address = 0). If this check is not done we may get
invalid ports on machines with redirection disabled and boot may hang
when reading the grub.cfg file.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Leo Sandoval <lsandova@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The pointer returned by grub_elf_file() is not checked to verify it is
not NULL before use. A NULL pointer may be returned when the given file
does not have a valid ELF header.
Fixes: https://savannah.gnu.org/bugs/?61960
Signed-off-by: Glenn Washburn <development@efficientek.com>
Signed-off-by: Lukas Fink <lukas.fink1@gmail.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
%s/hueristic/heuristic/
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The EFI Boot Services can be used after ExitBootServices() call because
the GRUB code still may allocate memory.
An example call stack is:
grub_multiboot_boot
grub_multiboot2_make_mbi
grub_efi_finish_boot_services
b->exit_boot_services
normal_boot
grub_relocator32_boot
grub_relocator_alloc_chunk_align_safe
grub_relocator_alloc_chunk_align
grub_malloc
grub_memalign
grub_mm_add_region_fn
[= grub_efi_mm_add_regions]
grub_efi_allocate_any_pages
grub_efi_allocate_pages_real
b->allocate_pages
This can lead to confusing errors. After ExitBootServices() call
b->allocate_pages may point to the NULL address resulting in something like:
!!!! X64 Exception Type - 01(#DB - Debug) CPU Apic ID - 00000000 !!!!
RIP - 000000000000201F, CS - 0000000000000038, RFLAGS - 0000000000200002
RAX - 000000007F9EE010, RCX - 0000000000000001, RDX - 0000000000000002
RBX - 0000000000000006, RSP - 00000000001CFBEC, RBP - 0000000000000000
RSI - 0000000000000000, RDI - 00000000FFFFFFFF
R8 - 0000000000000006, R9 - 000000007FEDFFB8, R10 - 0000000000000000
R11 - 0000000000000475, R12 - 0000000000000001, R13 - 0000000000000002
R14 - 00000000FFFFFFFF, R15 - 000000007E432C08
DS - 0000000000000030, ES - 0000000000000030, FS - 0000000000000030
GS - 0000000000000030, SS - 0000000000000030
CR0 - 0000000080010033, CR2 - 0000000000000000, CR3 - 000000007FC01000
CR4 - 0000000000000668, CR8 - 0000000000000000
DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
GDTR - 000000007F9DE000 0000000000000047, LDTR - 0000000000000000
IDTR - 000000007F470018 0000000000000FFF, TR - 0000000000000000
FXSAVE_STATE - 00000000001CF840
Ideally we would like to avoid all memory allocations after exiting EFI
Boot Services altogether but that requires significant code changes. This
patch adds a simple workaround that resets grub_mm_add_region_fn to NULL
after ExitBootServices() call, so:
- Memory allocations have a better chance of succeeding because grub_memalign()
will try to reclaim the disk cache if it sees a NULL in grub_mm_add_region_fn.
- At worst it will fail to allocate memory but it will explicitly tell users
that it's out of memory, which is still much better than the current
situation where it fails in a fairly random way and triggers a CPU fault.
Signed-off-by: Ruihan Li <lrh2000@pku.edu.cn>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch is used to fix GRUB menu gets stuck in server AC
poweron/poweroff stress test of x86_64, which is reproduced with
1/200 ratio. The root cause analysis as below:
Q: What's the code logic?
A: The grub_tsc_init() function will init tsc by setting grub_tsc_rate,
which call stack is:
grub_tsc_init() -> grub_tsc_calibrate_from_pmtimer() -> grub_divmod64()
Among, grub_divmod64() function needs tsc_diff as the second parameter.
In grub_pmtimer_wait_count_tsc(), we will call grub_get_tsc() function
to get time stamp counter value to assign to start_tsc variable, and
get into while (1) loop space to get end_tsc variable value with same
function, after 3580 ticks, return "end_tsc - start_tsc". Actually,
rdtsc instruction will be called in grub_get_tsc, but rdtsc instruction
is not reliable (for the reason see the next question), which will cause
tsc_diff to be a very big number larger than (1UL << 32) or a negative
number, so that grub_tsc_rate will be zero. When run_menu() function is
startup, and calls grub_tsc_get_time_ms() function to get current time
to check if timeout time reach, at this time, grub_tsc_get_time_ms()
function will return zero due to zero grub_tsc_rate variable, then GRUB
menu gets stuck...
Q: What's the difference between rdtsc and rdtscp instructions in x86_64
architecture? Here is more explanations from Intel® 64 and IA-32
Architectures Software Developer’s Manual Volume 2B (December 2024):
https://cdrdv2.intel.com/v1/dl/getContent/671241
A: In page 4-558 -> RDTSC—Read Time-Stamp Counter:
The RDTSC instruction is not a serializing instruction. It does not
necessarily wait until all previous instructions have been executed
before reading the counter. Similarly, subsequent instructions may
begin execution before the read operation is performed. The following
items may guide software seeking to order executions of RDTSC:
- If software requires RDTSC to be executed only after all previous
instructions have executed and all previous loads are globally
visible, it can execute LFENCE immediately before RDTSC.
- If software requires RDTSC to be executed only after all previous
instructions have executed and all previous loads and stores are
globally visible, it can execute the sequence MFENCE;LFENCE
immediately before RDTSC.
- If software requires RDTSC to be executed prior to execution of any
subsequent instruction (including any memory accesses), it can execute
the sequence LFENCE immediately after RDTSC.
A: In page 4-560 -> RDTSCP—Read Time-Stamp Counter and Processor ID:
The RDTSCP instruction is not a serializing instruction, but it does wait
until all previous instructions have executed and all previous loads are
globally visible. But it does not wait for previous stores to be globally
visible, and subsequent instructions may begin execution before the read
operation is performed. The following items may guide software seeking to
order executions of RDTSCP:
- If software requires RDTSCP to be executed only after all previous
stores are globally visible, it can execute MFENCE immediately before
RDTSCP.
- If software requires RDTSCP to be executed prior to execution of any
subsequent instruction (including any memory accesses), it can execute
LFENCE immediately after RDTSCP.
Q: Why there is a cpuid serializing instruction before rdtsc instruction,
but "grub_get_tsc" still cannot work as expect?
A: From Intel® 64 and IA-32 Architectures Software Developer's Manual
Volume 2A: Instruction Set Reference, A-L (December 2024):
https://cdrdv2.intel.com/v1/dl/getContent/671199
In page 3-222 -> CPUID—CPU Identification:
CPUID can be executed at any privilege level to serialize instruction execution.
Serializing instruction execution guarantees that any modifications to flags,
registers, and memory for previous instructions are completed before
the next instruction is fetched and executed.
So we only kept the instruction rdtsc and its previous instruction in order
currently. But it is still out-of-order possibility between rdtsc instruction
and its subsequent instruction.
Q: Why do we do this fix?
A: In the one hand, add cpuid instruction after rdtsc instruction to make sure
rdtsc instruction to be executed prior to execution of any subsequent instruction,
about serializing execution that all previous instructions have been executed
before rdtsc, there is a cpuid usage in original code. In the other hand, using
cpuid instruction rather than lfence can make sure a forward compatibility for
previous HW.
Base this fix, we did 1500 cycles power on/off stress test, and did not reproduce
this issue again.
Fixes: https://savannah.gnu.org/bugs/?66257
Signed-off-by: Duan Yayong <duanyayong@bytedance.com>
Signed-off-by: Li Yongqiang <liyongqiang@huaqin.com>
Signed-off-by: Sun Ming <simon.sun@huaqin.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The grub_divmod64() may return 0 but grub_tsc_calibrate_from_pmtimer()
still returns 1 saying calibration succeeded. Of course it is not true.
So, return 0 when grub_divmod64() returns 0. This way other calibration
functions can be called subsequently.
Signed-off-by: Duan Yayong <duanyayong@bytedance.com>
Signed-off-by: Li Yongqiang <liyongqiang@huaqin.com>
Signed-off-by: Sun Ming <simon.sun@huaqin.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Simply returning from grub_cmd_linux() doesn't free "file" resource nor
calls grub_dl_ref(my_mod). Jump to "fail" label for proper cleanup like
other error checks do.
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The operation kern_end - kern_start may underflow when we input it into
grub_relocator_alloc_chunk_addr() call. To avoid this we can use safe
math for this subtraction.
Fixes: CID 73845
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The Coverity complains that we might overflow into a negative value when
setting linux_params.kernel_alignment to (1 << align). We can remedy
this by casting it to grub_uint32_t.
Fixes: CID 473876
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When the format string, fmt0, includes a positional argument
grub_strtoul() or grub_strtoull() is called to extract the argument
position. However, the returned argument position isn't fully validated.
If the format is something like "%0$x" then these functions return
0 which leads to an underflow in the calculation of the args index, curn.
The fix is to add a check to ensure the extracted argument position is
greater than 0 before computing curn. Additionally, replace one
grub_strtoull() with grub_strtoul() and change curn type to make code
more correct.
Fixes: CID 473841
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The current code incorrectly assumes that both the input and the values
returned by grub_strtoul() are always valid which can lead to potential
errors. This fix ensures proper validation to prevent any unintended issues.
Fixes: CID 473843
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The Coverity indicates that the variable current_entry might overflow.
To prevent this use safe math when adding GRUB_MENU_PAGE_SIZE to current_entry.
On the occasion fix limiting condition which was broken.
Fixes: CID 473853
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The Coverity indicates that GRUB_EHCI_TOGGLE is an int that contains
a negative value and we are using it for the variable token which is
grub_uint32_t. To remedy this we can cast the definition to grub_uint32_t.
Fixes: CID 473851
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Update the overflow error messages to make them consistent
across the GRUB code.
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The entry_len is initialized in grub_find_root_devices_from_mountinfo()
to 0 before the while loop iterates through /proc/self/mountinfo. If the
file is empty or contains only invalid entries entry_len remains
0 causing entry_len - 1 in the subsequent for loop initialization
to underflow. To prevent this add a check to ensure entry_len > 0 before
entering the for loop.
Fixes: CID 473877
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
The result is initialized to 0 in grub_script_arglist_to_argv().
If the for loop condition is not met both result.args and result.argc
remain 0 causing result.argc - 1 to underflow and/or result.args NULL
dereference. Fix the issues by adding relevant checks.
Fixes: CID 473880
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When using grub_zalloc(), if we are out of memory, this function can fail.
After allocating memory, we should check if grub_zalloc() returns NULL.
If so, we should handle this error.
Fixes: CID 473856
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When using grub_malloc(), the function can fail if we are out of memory.
After allocating memory we should check if this function returned NULL
and handle this error if it did.
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Use grub_calloc() when allocating memory for arrays to ensure proper
overflow checks are in place.
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Replace direct arithmetic operations with macros from include/grub/safemath.h
to prevent potential overflow issues when calculating the memory sizes.
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When using grub_malloc() or grub_zalloc(), these functions can fail if
we are out of memory. After allocating memory we should check if these
functions returned NULL and handle this error if they did.
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Use grub_calloc() when allocating memory for arrays to ensure proper
overflow checks are in place.
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Replace direct arithmetic operations with macros from include/grub/safemath.h
to prevent potential overflow issues when calculating the memory sizes.
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The direct assignment of the unsigned long long value returned by
read_number() can potentially lead to an overflow on a 32-bit systems.
The fix replaces the direct assignments with calls to grub_cast()
which detects the overflows and safely assigns the values if no
overflow is detected.
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Use grub_calloc() when allocating memory for arrays to ensure proper
overflow checks are in place.
The HFS+ and squash4 security vulnerabilities were reported by
Jonathan Bar Or <jonathanbaror@gmail.com>.
Fixes: CVE-2025-0678
Fixes: CVE-2025-1125
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Replace direct arithmetic operations with macros from include/grub/safemath.h
to prevent potential overflow issues when calculating the memory sizes.
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In the dev_iterate() function a handle is opened but isn't closed when
grub_malloc() returns NULL. We should fix this by closing it on error.
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When using grub_malloc(), grub_zalloc() or grub_calloc(), these functions can
fail if we are out of memory. After allocating memory we should check if these
functions returned NULL and handle this error if they did.
On the occasion make a NULL check in ATA code more obvious.
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Use grub_calloc() when allocating memory for arrays to ensure proper
overflow checks are in place.
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Replace direct arithmetic operations with macros from include/grub/safemath.h
to prevent potential overflow issues when calculating the memory sizes.
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The idea is to permit the following: btrfs, cpio, exfat, ext, f2fs, fat,
hfsplus, iso9660, squash4, tar, xfs and zfs.
The JFS, ReiserFS, romfs, UDF and UFS security vulnerabilities were
reported by Jonathan Bar Or <jonathanbaror@gmail.com>.
Fixes: CVE-2025-0677
Fixes: CVE-2025-0684
Fixes: CVE-2025-0685
Fixes: CVE-2025-0686
Fixes: CVE-2025-0689
Suggested-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The BFS is not fuzz-clean. Don't allow it to be loaded under lockdown.
This will also disable the AFS.
Fixes: CVE-2024-45778
Fixes: CVE-2024-45779
Reported-by: Nils Langius <nils@langius.de>
Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
With the rest of module being blocked in lockdown mode it does not make
a lot of sense to leave memory reading enabled. This also goes in par
with disabling the dump command.
Reported-by: B Horn <b@horn.uk>
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The dump enables a user to read memory which should not be possible
in lockdown mode.
Fixes: CVE-2025-1118
Reported-by: B Horn <b@horn.uk>
Reported-by: Jonathan Bar Or <jonathanbaror@gmail.com>
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The test_parse() evaluates test expression recursively. Due to lack of
recursion depth check a specially crafted expression may cause a stack
overflow. The recursion is only triggered by the parentheses usage and
it can be unlimited. However, sensible expressions are unlikely to
contain more than a few parentheses. So, this patch limits the recursion
depth to 100, which should be sufficient.
Reported-by: Nils Langius <nils@langius.de>
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The grub_getline() function currently has a signed integer variable "i"
that can be overflown when user supplies more than 2^31 characters.
It results in a memory corruption of the allocated line buffer as well
as supplying large negative values to grub_realloc().
Fixes: CVE-2025-0690
Reported-by: Jonathan Bar Or <jonathanbaror@gmail.com>
Signed-off-by: Jonathan Bar Or <jonathanbaror@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The size calculation of the translation buffer in
grub_gettext_getstr_from_position() may overflow
to 0 leading to heap OOB write. This patch fixes
the issue by using grub_add() and checking for
an overflow.
Fixes: CVE-2024-45777
Reported-by: Nils Langius <nils@langius.de>
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Alec Brown <alec.r.brown@oracle.com>
Calculation of ctx->grub_gettext_msg_list size in grub_mofile_open() may
overflow leading to subsequent OOB write or read. This patch fixes the
issue by replacing grub_zalloc() and explicit multiplication with
grub_calloc() which does the same thing in safe manner.
Fixes: CVE-2024-45776
Reported-by: Nils Langius <nils@langius.de>
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Alec Brown <alec.r.brown@oracle.com>
The gettext module does not entirely cleanup after itself in
its GRUB_MOD_FINI() leaving a few variables hooks in place.
It is not possible to unload gettext module because normal
module depends on it. Though fix the issues for completeness.
Fixes: CVE-2025-0622
Reported-by: B Horn <b@horn.uk>
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The normal module does not entirely cleanup after itself in
its GRUB_MOD_FINI() leaving a few variables hooks in place.
It is not possible to unload normal module now but fix the
issues for completeness.
On the occasion replace 0s with NULLs for "pager" variable
hooks unregister.
Fixes: CVE-2025-0622
Reported-by: B Horn <b@horn.uk>
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
If the hooks are not removed they can be called after the module has
been unloaded leading to an use-after-free.
Fixes: CVE-2025-0622
Reported-by: B Horn <b@horn.uk>
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The grub_strrchr() may return NULL when the dirname do not contain "/".
This can happen on broken filesystems.
Reported-by: B Horn <b@horn.uk>
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The grub_extcmd_dispatcher() calls grub_arg_list_alloc() to allocate
a grub_arg_list struct but it does not verify the allocation was successful.
In case of failed allocation the NULL state pointer can be accessed in
parse_option() through grub_arg_parse() which may lead to a security issue.
Fixes: CVE-2024-45775
Reported-by: Nils Langius <nils@langius.de>
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Alec Brown <alec.r.brown@oracle.com>
The grub_dl_relocate_symbols() iterates through the sections in
an ELF looking for relocation sections. According to the spec [1]
the SHF_INFO_LINK flag should be set if the sh_info field is meant
to be a section index.
[1] https://refspecs.linuxbase.org/elf/gabi4+/ch4.sheader.html
Reported-by: B Horn <b@horn.uk>
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The previous code would never actually call grub_update_mem_attrs()
as sh_info will always be zero for the sections that exist in memory.
Reported-by: B Horn <b@horn.uk>
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
It was possible to overflow the value of mod->ref_count, a signed
integer, by repeatedly invoking insmod on an already loaded module.
This led to a use-after-free. As once ref_count was overflowed it became
possible to unload the module while there was still references to it.
This resolves the issue by using grub_add() to check if the ref_count
will overflow and then stops further increments. Further changes were
also made to grub_dl_unref() to check for the underflow condition and
the reference count was changed to an unsigned 64-bit integer.
Reported-by: B Horn <b@horn.uk>
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Otherwise a subsequent header could change the height and width
allowing future OOB writes.
Fixes: CVE-2024-45774
Reported-by: Nils Langius <nils@langius.de>
Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
An overly long filename can be passed to tftp_open() which would cause
grub_normalize_filename() to write out of bounds.
Fixed by adding an extra argument to grub_normalize_filename() for the
space available, making it act closer to a strlcpy(). As several fixed
strings are strcpy()'d after into the same buffer, their total length is
checked to see if they exceed the remaining space in the buffer. If so,
return an error.
On the occasion simplify code a bit by removing unneeded rrqlen zeroing.
Reported-by: B Horn <b@horn.uk>
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The function included a call to grub_strcpy() which copied data from an
environment variable to a buffer allocated in grub_cmd_normal(). The
grub_cmd_normal() didn't consider the length of the environment variable.
So, the copy operation could exceed the allocation and lead to an OOB
write. Fix the issue by replacing grub_strcpy() with grub_strlcpy() and
pass the underlying buffers size to the grub_net_search_config_file().
Fixes: CVE-2025-0624
Reported-by: B Horn <b@horn.uk>
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The grub_net_network_level_interface_unregister(), previously
implemented in a header, did not remove the variables hooks that
were registered in grub_net_network_level_interface_register().
Fix this by implementing the same logic used to register the
variables and move the function into the grub-core/net/net.c.
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The net module is a dependency of normal. So, it shouldn't be possible
to unload the net. Though unregister variables hooks as a precaution.
It also gets in line with unregistering the other net module hooks.
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
If unbounded recursion is allowed it becomes possible to collide the
stack with the heap. As UEFI firmware often lacks guard pages this
becomes an exploitable issue as it is possible in some cases to do
a controlled overwrite of a section of this heap region with
arbitrary data.
Reported-by: B Horn <b@horn.uk>
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The part_iterate() is used by grub_partition_iterate() as a callback in
the partition iterate functions. However, part_iterate() may also call
the partition iterate functions which may lead to recursion. Fix potential
issue by limiting the recursion depth.
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The grub_disk_read() may trigger other disk reads, e.g. via loopbacks.
This may lead to very deep recursion which can corrupt the heap. So, fix
the issue by limiting reads depth.
Reported-by: B Horn <b@horn.uk>
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
It was possible to delete a loopback while there were still references
to it. This led to an exploitable use-after-free.
Fixed by implementing a reference counting in the grub_loopback struct.
Reported-by: B Horn <b@horn.uk>
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The GRUB may use TPM to verify the integrity of boot components and the
result can determine whether a previously sealed key can be released. If
everything checks out, showing nothing has been tampered with, the key
is released and GRUB unlocks the encrypted root partition for the next
stage of booting.
However, the liberal Command Line Interface (CLI) can be misused by
anyone in this case to access files in the encrypted partition one way
or another. Despite efforts to keep the CLI secure by preventing utility
command output from leaking file content, many techniques in the wild
could still be used to exploit the CLI, enabling attacks or learning
methods to attack. It's nearly impossible to account for all scenarios
where a hack could be applied.
Therefore, to mitigate potential misuse of the CLI after the root device
has been successfully unlocked via TPM, the user should be required to
authenticate using the LUKS password. This added layer of security
ensures that only authorized users can access the CLI reducing the risk
of exploitation or unauthorized access to the encrypted partition.
Fixes: CVE-2024-49504
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The grub_file_open() and grub_file_close() should be the only places
that allow a reference to a filesystem to stay open. So, add grub_dl_t
to grub_fs_t and set this in the GRUB_MOD_INIT() for each filesystem to
avoid issues when filesystems forget to do it themselves or do not track
their own references, e.g. squash4.
The fs_label(), fs_uuid(), fs_mtime() and fs_read() should all ref and
unref in the same function but it is essentially redundant in GRUB
single threaded model.
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This is to avoid a generic issue were some filesystems would not set
data and also not set a grub_errno. This meant it was possible for many
filesystems to grub_dl_unref() themselves multiple times resulting in
it being possible to unload the filesystems while there were still
references to them, e.g., via a loopback.
Reported-by: B Horn <b@horn.uk>
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
It was previously possible for grub_xfs_mount() to return NULL without
setting grub_errno if the XFS version was invalid. This resulted in it
being possible for grub_dl_unref() to be called twice allowing the XFS
module to be unloaded while there were still references to it.
Fixing this problem in general by ensuring a grub_errno is set if the
fail label is reached.
Reported-by: B Horn <b@horn.uk>
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The number of records in the root key array read from disk was not being
validated against the size of the root node. This could lead to an
out-of-bounds read.
This patch adds a check to ensure that the number of records in the root
key array does not exceed the expected size of a root node read from
disk. If this check detects an out-of-bounds condition the operation is
aborted to prevent random errors due to metadata corruption.
Reported-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
It was possible to read OOB when an attribute had a size that exceeded
the allocated buffer. This resolves that by making sure all attributes
that get read are fully in the allocated space by implementing
a function to validate them.
Defining the offsets in include/grub/ntfs.h but they are only used in
the validation function and not across the rest of the NTFS code.
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Right now to access the next attribute the code reads the length of the
current attribute and adds that to the current pointer. This is error
prone as bounds checking needs to be performed all over the place. So,
implement a helper and ensure its used across find_attr() and read_attr().
This commit does *not* implement full bounds checking. It is just the
preparation work for this to be added into the helper.
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The end of the attribute buffer should be stored alongside the rest of
the attribute struct as right now it is not possible to implement bounds
checking when accessing attributes sequentially.
This is done via:
- updating init_attr() to set at->end and check is is not initially out of bounds,
- implementing checks as init_attr() had its type change in its callers,
- updating the value of at->end when needed.
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When parsing NTFS file records the presence of the 0xFF marker indicates
the end of the attribute list. This value signifies that there are no
more attributes to process.
However, when the end marker is missing due to corrupted metadata the
loop continues to read beyond the attribute list resulting in out-of-bounds
reads and potentially entering an infinite loop.
This patch adds a check to provide a stop condition for the loop ensuring
it stops at the end of the attribute list or at the end of the Master File
Table. This guards against out-of-bounds reads and prevents infinite loops.
Reported-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When inline extents are used, i.e. the extent tree depth equals zero,
a maximum of four entries can fit into the inode's data block. If the
extent header states a number of entries greater than four the current
ext2 implementation causes an out-of-bounds read. Fix this issue by
capping the number of extents to four when reading inline extents.
Reported-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The getblk() returns a value of type grub_int64_t which is assigned to
iagblk and inoblk, both of type grub_uint64_t, in grub_jfs_read_inode()
via grub_jfs_blkno(). This patch fixes the type mismatch in the
functions. Additionally, the getblk() will return 0 instead of -1 on
failure cases. This change is safe because grub_errno is always set in
getblk() to indicate errors and it is later checked in the callers.
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
An extent's logical offset and address are represented as a 40-bit value
split into two parts: the most significant 8 bits and the least
significant 32 bits. Currently the JFS code uses only the least
significant 32 bits value for offsets and addresses assuming the data
size will never exceed the 32-bit range. This approach ignores the most
significant 8 bits potentially leading to incorrect offsets and
addresses for larger values. The patch fixes it by incorporating the
most significant 8 bits into the calculation to get the full 40-bits
value for offsets and addresses.
https://jfs.sourceforge.net/project/pub/jfslayout.pdf
"off1,off2 is a 40-bit field, containing the logical offset of the first
block in the extent.
...
addr1,addr2 is a 40-bit field, containing the address of the extent."
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
While fuzz testing JFS with ASAN enabled an OOB read was detected in
grub_jfs_opendir(). The issue occurred due to an invalid directory slot
index in the first entry of the sorted directory slot array in the inode
directory header. The fix ensures the slot index is validated before
accessing it. Given that an internal or a leaf node in a directory B+
tree is a 4 KiB in size and each directory slot is always 32 bytes, the
max number of slots in a node is 128. The validation ensures that the
slot index doesn't exceed this limit.
[1] https://jfs.sourceforge.net/project/pub/jfslayout.pdf
JFS will allocate 4K of disk space for an internal node of the B+ tree.
An internal node looks the same as a leaf node.
- page 10
Fixed number of Directory Slots depending on the size of the node. These are
the slots to be used for storing the directory slot array and the directory
entries or router entries. A directory slot is always 32 bytes.
...
A Directory Slot Array which is a sorted array of indices to the directory
slots that are currently in use.
...
An internal or a leaf node in the directory B+ tree is a 4K page.
- page 25
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Alec Brown <alec.r.brown@oracle.com>
The JFS fuzzing revealed an OOB read in grub_jfs_getent(). The crash
was caused by an invalid leaf nodes count, diro->dirpage->header.count,
which was larger than the maximum number of leaf nodes allowed in an
inode. This fix is to ensure that the leaf nodes count is validated in
grub_jfs_opendir() before calling grub_jfs_getent().
On the occasion replace existing raw numbers with newly defined constant.
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Alec Brown <alec.r.brown@oracle.com>
The ctx->filename can point to either a string literal or a dynamically
allocated string. The ctx->filename_alloc field is used to indicate the
type of allocation.
An issue has been identified where ctx->filename is reassigned to
a string literal in susp_iterate_dir() but ctx->filename_alloc is not
correctly handled. This oversight causes a memory leak and an invalid
free operation later.
The fix involves checking ctx->filename_alloc, freeing the allocated
string if necessary and clearing ctx->filename_alloc for string literals.
Reported-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
It was possible for a grub_errno to not be set if mount of an ISO 9660
filesystem failed when set_rockridge() returned 0.
This isn't known to be exploitable as the other filesystems due to
filesystem helper checking the requested file type. Though fixing
as a precaution.
Reported-by: B Horn <b@horn.uk>
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
It was possible for mount to fail but not set grub_errno. This led to
a possible double decrement of the module reference count if the NULL
page was mapped.
Fixing in general as a similar bug was fixed in commit 61b13c187
(fs/hfsplus: Set grub_errno to prevent NULL pointer access) and there
are likely more variants around.
Fixes: CVE-2024-45783
Reported-by: B Horn <b@horn.uk>
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
It was previously possible for grub_errno to not be set when
grub_f2fs_mount() failed if nat_bitmap_ptr() returned NULL.
This issue is solved by ensuring a grub_errno is set in the fail case.
Reported-by: B Horn <b@horn.uk>
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Both namesize and linksize are derived from hd.size, a 12-digit octal
number parsed by read_number(). Later direct arithmetic calculation like
"namesize + 1" and "linksize + 1" may exceed the maximum value of
grub_size_t leading to heap OOB write. This patch fixes the issue by
using grub_add() and checking for an overflow.
Fixes: CVE-2024-45780
Reported-by: Nils Langius <nils@langius.de>
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Alec Brown <alec.r.brown@oracle.com>
It was possible to iterate through grub_cpio_find_file() without
allocating name and not setting mode to GRUB_ARCHELP_ATTR_END, which
would cause the uninitialized value for name to be used as an argument
for canonicalize() in grub_archelp_dir().
Reported-by: B Horn <b@horn.uk>
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
grub_strcpy() was used to copy a symlink name from the filesystem
image to a heap allocated buffer. This led to a OOB write to adjacent
heap allocations. Fix by using grub_strlcpy().
Fixes: CVE-2024-45781
Reported-by: B Horn <b@horn.uk>
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
grub_strlcpy() acts the same way as strlcpy() does on most *NIX,
returning the length of src and ensuring dest is always NUL
terminated except when size is 0.
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Follow recent extensions of EFI support providing a TCG2 driver with
a public API for getting the maximum TPM command size and passing a TPM
command through to the TPM 2. Implement this functionality using ieee1275
PowerPC firmware API calls. Move tcg2.c into the TCG2 driver.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Move tpm_get_tpm_version() into grub_ieee1275_tpm_init() and invalidate
grub_ieee1275_tpm_ihandle in case no TPM 2 could be detected. Try the
initialization only once so that grub_tpm_present() will always return
the same result. Use the grub_ieee1275_tpm_ihandle as indicator for an
available TPM instead of grub_ieee1275_tpm_version, which can now be
removed.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Move common initialization functions from the ibmvtpm driver module into
tcg2.c that will be moved into the new TCG2 driver in a subsequent patch.
Make the functions available to the ibmvtpm driver as public functions
and variables.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Consolidate repeated definitions of IEEE1275_IHANDLE_INVALID that are cast
to the type grub_ieee1275_ihandle_t. On the occasion add "GRUB_" prefix to
the constant name.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Cast 0 to proper type grub_ieee1275_ihandle_t. This type is
used for struct grub_serial_port's handle that assigns or
compares with IEEE1275_IHANDLE_INVALID.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The TPM bit fields need to be in reverse order for big endian targets,
such as ieee1275 PowerPC platforms that run GRUB in big endian mode.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Update the user manual to address TPM2 key protector including the two
related commands, tpm2_key_protector_init and tpm2_key_protector_clear,
and the user-space utility: grub-protect.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
For the tpm2_key_protector module, the TCG2 command submission function
is the only difference between a QEMU instance and grub-emu. To test
TPM2 key unsealing with a QEMU instance, it requires an extra OS image
to invoke grub-protect to seal the LUKS key, rather than a simple
grub-shell rescue CD image. On the other hand, grub-emu can share the
emulated TPM2 device with the host, so that we can seal the LUKS key on
host and test key unsealing with grub-emu.
This test script firstly creates a simple LUKS image to be loaded as a
loopback device in grub-emu. Then an emulated TPM2 device is created by
"swtpm chardev" and PCR 0 and 1 are extended.
There are several test cases in the script to test various settings. Each
test case uses grub-protect or tpm2-tools to seal the LUKS password
with PCR 0 and PCR 1. Then grub-emu is launched to load the LUKS image,
try to mount the image with tpm2_key_protector_init and cryptomount, and
verify the result.
Based on the idea from Michael Chang.
Cc: Michael Chang <mchang@suse.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Cc: Glenn Washburn <development@efficientek.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
As a preparation to test tpm2_key_protector with grub-emu, the new
option, --tpm-device, is introduced to specify the TPM device for
grub-emu so that grub-emu can access an emulated TPM device from
the host.
Since grub-emu can directly access the device on host, it's easy to
implement the essential TCG2 command submission function with the
read/write functions and enable tpm2_key_protector module for grub-emu,
so that we can further test TPM2 key unsealing with grub-emu.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
When using disk auto-unlocking with TPM 2.0, the typical grub.cfg may
look like this:
tpm2_key_protector_init --tpm2key=(hd0,gpt1)/boot/grub/sealed.tpm
cryptomount -u <PART-UUID> -P tpm2
search --fs-uuid --set=root <FS-UUID>
Since the disk search order is based on the order of module loading, the
attacker could insert a malicious disk with the same FS-UUID root to
trick GRUB to boot into the malicious root and further dump memory to
steal the unsealed key.
Do defend against such an attack, we can specify the hint provided by
"grub-probe" to search the encrypted partition first:
search --fs-uuid --set=root --hint='cryptouuid/<PART-UUID>' <FS-UUID>
However, for LVM on an encrypted partition, the search hint provided by
"grub-probe" is:
--hint='lvmid/<VG-UUID>/<LV-UUID>'
It doesn't guarantee to look up the logical volume from the encrypted
partition, so the attacker may have the chance to fool GRUB to boot
into the malicious disk.
To minimize the attack surface, this commit tweaks the disk device search
in diskfilter to look up cryptodisk devices first and then others, so
that the auto-unlocked disk will be found first, not the attacker's disk.
Cc: Fabian Vogt <fvogt@suse.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
An attacker may insert a malicious disk with the same crypto UUID and
trick GRUB to mount the fake root. Even though the key from the key
protector fails to unlock the fake root, it's not wiped out cleanly so
the attacker could dump the memory to retrieve the secret key. To defend
such attack, wipe out the cached key when we don't need it.
Cc: Fabian Vogt <fvogt@suse.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
If a protector is specified, but it fails to unlock the disk, fall back
to asking for the passphrase.
Before requesting the passphrase, the error from the key protector(s)
has to be cleared, or the later code, e.g., LUKS code, may stop as
grub_errno is set. This commit prints error from the key protector(s)
and sets grub_errno to GRUB_ERR_NONE to have a fresh start.
Signed-off-by: Patrick Colp <patrick.colp@oracle.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Currently with the TPM2 protector, only SRK mode is supported and
NV index support is just a stub. Implement the NV index option.
Note: This only extends support on the unseal path. grub-protect
has not been updated. tpm2-tools can be used to insert a key into
the NV index.
An example of inserting a key using tpm2-tools:
# Get random key.
tpm2_getrandom 32 > key.dat
# Create primary object.
tpm2_createprimary -C o -g sha256 -G ecc -c primary.ctx
# Create policy object. `pcrs.dat` contains the PCR values to seal against.
tpm2_startauthsession -S session.dat
tpm2_policypcr -S session.dat -l sha256:7,11 -f pcrs.dat -L policy.dat
tpm2_flushcontext session.dat
# Seal key into TPM.
cat key.dat | tpm2_create -C primary.ctx -u key.pub -r key.priv -L policy.dat -i-
tpm2_load -C primary.ctx -u key.pub -r key.priv -n sealing.name -c sealing.ctx
tpm2_evictcontrol -C o -c sealing.ctx 0x81000000
Then to unseal the key in GRUB, add this to grub.cfg:
tpm2_key_protector_init --mode=nv --nvindex=0x81000000 --pcrs=7,11
cryptomount -u <UUID> --protector tpm2
Signed-off-by: Patrick Colp <patrick.colp@oracle.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
This commit handles the TPM2_PolicyAuthorize command from the key file
in TPM 2.0 Key File format.
TPM2_PolicyAuthorize is the essential command to support authorized
policy which allows the users to sign TPM policies with their own keys.
Per TPM 2.0 Key File [1], CommandPolicy for TPM2_PolicyAuthorize
comprises "TPM2B_PUBLIC pubkey", "TPM2B_DIGEST policy_ref", and
"TPMT_SIGNATURE signature". To verify the signature, the current policy
digest is hashed with the hash algorithm written in "signature", and then
"signature" is verified with the hashed policy digest and "pubkey". Once
TPM accepts "signature", TPM2_PolicyAuthorize is invoked to authorize the
signed policy.
To create the key file with authorized policy, here are the pcr-oracle [2]
commands:
# Generate the RSA key and create the authorized policy file
$ pcr-oracle \
--rsa-generate-key \
--private-key policy-key.pem \
--auth authorized.policy \
create-authorized-policy 0,2,4,7,9
# Seal the secret with the authorized policy
$ pcr-oracle \
--key-format tpm2.0 \
--auth authorized.policy \
--input disk-secret.txt \
--output sealed.key \
seal-secret
# Sign the predicted PCR policy
$ pcr-oracle \
--key-format tpm2.0 \
--private-key policy-key.pem \
--from eventlog \
--stop-event "grub-file=grub.cfg" \
--after \
--input sealed.key \
--output /boot/efi/efi/grub/sealed.tpm \
sign 0,2,4,7,9
Then specify the key file and the key protector to grub.cfg in the EFI
system partition:
tpm2_key_protector_init -a RSA --tpm2key=(hd0,gpt1)/efi/grub/sealed.tpm
cryptomount -u <PART_UUID> -P tpm2
For any change in the boot components, just run the "sign" command again
to update the signature in sealed.tpm, and TPM can unseal the key file
with the updated PCR policy.
[1] https://www.hansenpartnership.com/draft-bottomley-tpm2-keys.html
[2] https://github.com/okirch/pcr-oracle
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
To utilize the key protectors framework, there must be a way to protect
full-disk encryption keys in the first place. The grub-protect tool
includes support for the TPM2 key protector but other protectors that
require setup ahead of time can be supported in the future.
For the TPM2 key protector, the intended flow is for a user to have
a LUKS 1 or LUKS 2-protected fully-encrypted disk. The user then creates
a new LUKS key file, say by reading /dev/urandom into a file, and creates
a new LUKS key slot for this key. Then, the user invokes the grub-protect
tool to seal this key file to a set of PCRs using the system's TPM 2.0.
The resulting sealed key file is stored in an unencrypted partition such
as the EFI System Partition (ESP) so that GRUB may read it. The user also
has to ensure the cryptomount command is included in GRUB's boot script
and that it carries the requisite key protector (-P) parameter.
Sample usage:
$ dd if=/dev/urandom of=luks-key bs=1 count=32
$ sudo cryptsetup luksAddKey /dev/sdb1 luks-key --pbkdf=pbkdf2 --hash=sha512
To seal the key with TPM 2.0 Key File (recommended):
$ sudo grub-protect --action=add \
--protector=tpm2 \
--tpm2-pcrs=0,2,4,7,9 \
--tpm2key \
--tpm2-keyfile=luks-key \
--tpm2-outfile=/boot/efi/efi/grub/sealed.tpm
Or, to seal the key with the raw sealed key:
$ sudo grub-protect --action=add \
--protector=tpm2 \
--tpm2-pcrs=0,2,4,7,9 \
--tpm2-keyfile=luks-key \
--tpm2-outfile=/boot/efi/efi/grub/sealed.key
Then, in the boot script, for TPM 2.0 Key File:
tpm2_key_protector_init --tpm2key=(hd0,gpt1)/efi/grub/sealed.tpm
cryptomount -u <SDB1_UUID> -P tpm2
Or, for the raw sealed key:
tpm2_key_protector_init --keyfile=(hd0,gpt1)/efi/grub/sealed.key --pcrs=0,2,4,7,9
cryptomount -u <SDB1_UUID> -P tpm2
The benefit of using TPM 2.0 Key File is that the PCR set is already
written in the key file, so there is no need to specify PCRs when
invoking tpm2_key_protector_init.
Signed-off-by: Hernan Gatta <hegatta@linux.microsoft.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Add a new parameter to cryptomount to support the key protectors framework: -P.
The parameter is used to automatically retrieve a key from specified key
protectors. The parameter may be repeated to specify any number of key
protectors. These are tried in order until one provides a usable key for any
given disk.
Signed-off-by: Hernan Gatta <hegatta@linux.microsoft.com>
Signed-off-by: Michael Chang <mchang@suse.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
The TPM2 key protector is a module that enables the automatic retrieval
of a fully-encrypted disk's unlocking key from a TPM 2.0.
The theory of operation is such that the module accepts various
arguments, most of which are optional and therefore possess reasonable
defaults. One of these arguments is the keyfile/tpm2key parameter, which
is mandatory. There are two supported key formats:
1. Raw Sealed Key (--keyfile)
When sealing a key with TPM2_Create, the public portion of the sealed
key is stored in TPM2B_PUBLIC, and the private portion is in
TPM2B_PRIVATE. The raw sealed key glues the fully marshalled
TPM2B_PUBLIC and TPM2B_PRIVATE into one file.
2. TPM 2.0 Key (--tpm2key)
The following is the ASN.1 definition of TPM 2.0 Key File:
TPMPolicy ::= SEQUENCE {
CommandCode [0] EXPLICIT INTEGER
CommandPolicy [1] EXPLICIT OCTET STRING
}
TPMAuthPolicy ::= SEQUENCE {
Name [0] EXPLICIT UTF8STRING OPTIONAL
Policy [1] EXPLICIT SEQUENCE OF TPMPolicy
}
TPMKey ::= SEQUENCE {
type OBJECT IDENTIFIER
emptyAuth [0] EXPLICIT BOOLEAN OPTIONAL
policy [1] EXPLICIT SEQUENCE OF TPMPolicy OPTIONAL
secret [2] EXPLICIT OCTET STRING OPTIONAL
authPolicy [3] EXPLICIT SEQUENCE OF TPMAuthPolicy OPTIONAL
description [4] EXPLICIT UTF8String OPTIONAL,
rsaParent [5] EXPLICIT BOOLEAN OPTIONAL,
parent INTEGER
pubkey OCTET STRING
privkey OCTET STRING
}
The TPM2 key protector only expects a "sealed" key in DER encoding,
so "type" is always 2.23.133.10.1.5, "emptyAuth" is "TRUE", and
"secret" is empty. "policy" and "authPolicy" are the possible policy
command sequences to construct the policy digest to unseal the key.
Similar to the raw sealed key, the public portion (TPM2B_PUBLIC) of
the sealed key is stored in "pubkey", and the private portion
(TPM2B_PRIVATE) is in "privkey".
For more details: https://www.hansenpartnership.com/draft-bottomley-tpm2-keys.html
This sealed key file is created via the grub-protect tool. The tool
utilizes the TPM's sealing functionality to seal (i.e., encrypt) an
unlocking key using a Storage Root Key (SRK) to the values of various
Platform Configuration Registers (PCRs). These PCRs reflect the state
of the system as it boots. If the values are as expected, the system
may be considered trustworthy, at which point the TPM allows for a
caller to utilize the private component of the SRK to unseal (i.e.,
decrypt) the sealed key file. The caller, in this case, is this key
protector.
The TPM2 key protector registers two commands:
- tpm2_key_protector_init: Initializes the state of the TPM2 key
protector for later usage, clearing any
previous state, too, if any.
- tpm2_key_protector_clear: Clears any state set by tpm2_key_protector_init.
The way this is expected to be used requires the user to, either
interactively or, normally, via a boot script, initialize/configure
the key protector and then specify that it be used by the "cryptomount"
command (modifications to this command are in a different patch).
For instance, to unseal the raw sealed key file:
tpm2_key_protector_init --keyfile=(hd0,gpt1)/efi/grub/sealed-1.key
cryptomount -u <PART1_UUID> -P tpm2
tpm2_key_protector_init --keyfile=(hd0,gpt1)/efi/grub/sealed-2.key --pcrs=7,11
cryptomount -u <PART2_UUID> -P tpm2
Or, to unseal the TPM 2.0 Key file:
tpm2_key_protector_init --tpm2key=(hd0,gpt1)/efi/grub/sealed-1.tpm
cryptomount -u <PART1_UUID> -P tpm2
tpm2_key_protector_init --tpm2key=(hd0,gpt1)/efi/grub/sealed-2.tpm --pcrs=7,11
cryptomount -u <PART2_UUID> -P tpm2
If a user does not initialize the key protector and attempts to use it
anyway, the protector returns an error.
Before unsealing the key, the TPM2 key protector follows the "TPMPolicy"
sequences to enforce the TPM policy commands to construct a valid policy
digest to unseal the key.
For the TPM 2.0 Key files, "authPolicy" may contain multiple "TPMPolicy"
sequences, the TPM2 key protector iterates "authPolicy" to find a valid
sequence to unseal key. If "authPolicy" is empty or all sequences in
"authPolicy" fail, the protector tries the one from "policy". In case
"policy" is also empty, the protector creates a "TPMPolicy" sequence
based on the given PCR selection.
For the raw sealed key, the TPM2 key protector treats the key file as a
TPM 2.0 Key file without "authPolicy" and "policy", so the "TPMPolicy"
sequence is always based on the PCR selection from the command
parameters.
This commit only supports one policy command: TPM2_PolicyPCR. The
command set will be extended to support advanced features, such as
authorized policy, in the later commits.
Cc: James Bottomley <jejb@linux.ibm.com>
Signed-off-by: Hernan Gatta <hegatta@linux.microsoft.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
A Trusted Platform Module (TPM) Software Stack (TSS) provides logic to
compose and submit TPM commands and parse responses.
A limited number of TPM commands may be accessed via the EFI TCG2
protocol. This protocol exposes functionality that is primarily geared
toward TPM usage within the context of Secure Boot. For all other TPM
commands, however, such as sealing and unsealing, this protocol does not
provide any help, with the exception of passthrough command submission.
The SubmitCommand method allows a caller to send raw commands to the
system's TPM and to receive the corresponding response. These
command/response pairs are formatted using the TPM wire protocol. To
construct commands in this way, and to parse the TPM's response, it is
necessary to, first, possess knowledge of the various TPM structures, and,
second, of the TPM wire protocol itself.
As such, this patch includes implementations of various grub_tpm2_* functions
(inventoried below), and logic to write and read command and response
buffers, respectively, using the TPM wire protocol.
Functions:
- grub_tpm2_create(),
- grub_tpm2_createprimary(),
- grub_tpm2_evictcontrol(),
- grub_tpm2_flushcontext(),
- grub_tpm2_load(),
- grub_tpm2_pcr_read(),
- grub_tpm2_policygetdigest(),
- grub_tpm2_policypcr(),
- grub_tpm2_readpublic(),
- grub_tpm2_startauthsession(),
- grub_tpm2_unseal(),
- grub_tpm2_loadexternal(),
- grub_tpm2_hash(),
- grub_tpm2_verifysignature(),
- grub_tpm2_policyauthorize(),
- grub_tpm2_testparms().
Signed-off-by: Hernan Gatta <hegatta@linux.microsoft.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
This commit adds the necessary TPM2 types and structs as the preparation
for the TPM2 Software Stack (TSS2) support. The Marshal/Unmarshal
functions are also added to handle the data structure to be submitted to
TPM2 commands and to be received from the response.
Signed-off-by: Hernan Gatta <hegatta@linux.microsoft.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
As the preparation to support TPM2 Software Stack (TSS2), this commit
implements the TPM2 buffer handling functions to pack data for the TPM2
commands and unpack the data from the response.
Cc: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Hernan Gatta <hegatta@linux.microsoft.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
A key protector encapsulates functionality to retrieve an unlocking key
for a fully-encrypted disk from a specific source. A key protector
module registers itself with the key protectors framework when it is
loaded and unregisters when unloaded. Additionally, a key protector may
accept parameters that describe how it should operate.
The key protectors framework, besides offering registration and
unregistration functions, also offers a one-stop routine for finding and
invoking a key protector by name. If a key protector with the specified
name exists and if an unlocking key is successfully retrieved by it, the
function returns to the caller the retrieved key and its length.
Cc: Vladimir Serbinenko <phcoder@gmail.com>
Signed-off-by: Hernan Gatta <hegatta@linux.microsoft.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Document libtasn1 in docs/grub-dev.texi and add the upgrade steps.
Also add the patches to make libtasn1 compatible with GRUB code.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Import tests from libtasn1 that use functionality we import.
This test module is integrated into functional_test so that the
user can run the test in GRUB shell.
This doesn't test the full decoder but that will be exercised in
test suites for coming patch sets.
Add testcase target in accordance with commit 5e10be48e5 (tests: Add
check-native and check-nonnative make targets).
Cc: Vladimir Serbinenko <phcoder@gmail.com>
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Create a wrapper file that specifies the module license.
Set up the makefile so it is built.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
There is a testcase to test the values larger than "int" but smaller
than "long". However, for some architectures, "long" and "int" are the
same and the compiler may issue a warning like this:
grub-core/tests/asn1/tests/Test_overflow.c:48:50: error: left shift of negative value [-Werror=shift-negative-value]
unsigned long num = ((long) GRUB_UINT_MAX) << 2;
^~
To avoid unnecessary error the testcase is enabled only when
GRUB_LONG_MAX is larger than GRUB_INT_MAX.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
This commit replaces printf() and fprintf() with grub_printf() to print
the error messages for the testcases. Besides, asn1_strerror() is used
to convert the result code to strings instead of asn1_perror().
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
This commit removes the "verbose" variables and the unnecessary printf()
to simplify the output.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Some testcases use exit() to end the test. Since all the asn1 testcases
are invoked as functions, this commit replaces exit() with return to
reflect the test results, so that the main test function can check the
results.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
This commit changes the main functions in the testcases to the test
names so that the real "main" test function can invokes them.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
This commit removes all the headers and only uses asn1_test.h.
To avoid including int.h from grub-core/lib/libtasn1-grub/lib,
CONST_DOWN is defined in reproducers.c.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
In _asn1_tag_der(), the first while loop for the long form may end up
with a "k" value with "ASN1_MAX_TAG_SIZE" and cause the buffer overrun
in the second while loop. This commit tweaks the conditional check to
avoid producing a too large "k".
This is a quick fix and may differ from the official upstream fix.
libtasn1 issue: https://gitlab.com/gnutls/libtasn1/-/issues/49
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Replace a 64-bit division with a call to grub_divmod64(), preventing
creation of __udivdi3() calls on 32-bit platforms.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Since libtasn1.h is the header to be included by users, including the
standard POSIX headers in libtasn1.h would force the user to add the
CFLAGS/CPPFLAGS for the POSIX headers.
This commit adjusts the header paths to use the grub headers instead of
the standard POSIX headers, so that users only need to include
libtasn1.h to use libtasn1 functions.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
strcat() is not available in GRUB. This commit replaces strcat() and
_asn1_strcat() with the bounds-checking _asn1_str_cat().
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
strcat() is not available in GRUB. This commit replaces strcat() with
strcpy() in _asn1_str_cat() as the preparation to replace other strcat()
with the bounds-checking _asn1_str_cat().
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
We don't expect to be able to write ASN.1, only read it,
so we can disable some code.
Do that with #if 0/#endif, rather than deletion. This means
that the difference between upstream and GRUB is smaller,
which should make updating libtasn1 easier in the future.
With these exclusions we also avoid the need for minmax.h,
which is convenient because it means we don't have to
import it from gnulib.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Cc: Vladimir Serbinenko <phcoder@gmail.com>
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Unlike files accessed via a normal file system, the file->read_hook() is
not honoured when using blocklist notation.
This means that when trying to use a dedicated, 1 KiB, raw partition
for the environment block and hence does something like
save_env --file=(hd0,gpt9)0+2 X Y Z
this fails with "sparse file not allowed", which is rather unexpected,
as I've explicitly said exactly which blocks should be used. Adding
a little debugging reveals that grub_file_size(file) is 1024 as expected,
but total_length is 0, simply because the callback was never invoked, so
blocklists is an empty list.
Fix that by honouring the ->read_hook() set by the caller, also when
a "file" is specified with blocklist notation.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Correct the documentation for the grub.cfg searching via network that
will be done based on ethernet type, -01, which was missing, and a given
MAC address.
Fixes: https://savannah.gnu.org/bugs/?65152
Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Correct documentation for UEFI secure boot to remove statement that
chainloader does not work with secure boot. This was fixed by the commit
6d05264 (kern/efi/sb: Add chainloaded image as shim's verifiable object).
Fixes: https://savannah.gnu.org/bugs/?62004
Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Correct documentation for pxe_default_server, pxe_default_gatway and
pxe_blksize. Only pxe_default_server is actually used (alias for
net_default_server). So, capture this and remove the other two.
Fixes: https://savannah.gnu.org/bugs/?54480
Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Multiboot modules that could not be read successfully, e.g. via network,
should not be added to the list of modules to forward to the operating
system that is to be booted subsequently.
This patch is necessary because even if a grub.cfg checks whether or not
a module was successfully downloaded, it is futile to retry a failed
download as the corrupted module will be forwarded either way.
Signed-off-by: Valentin Gehrke <valentin.gehrke@kernkonzept.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The SBAT metadata is read from CSV file and transformed into an ELF note
with the -s option.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In order to store the SBAT data we create a new ELF note. The string
".sbat", zero-padded to 4 byte alignment, shall be entered in the name
field. The string "SBAT"'s ASCII values, 0x53424154, should be entered
in the type field.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Rename has been skipped by mistake in the original commit.
Fixes: 94649c026 (nx: Set page permissions for loaded modules)
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
The calculation of the size of the table was incorrect (copy/pasta from
grub_acpi_rsdt_find_table() I assume...). The entries are 64-bit long.
This causes us to access beyond the end of the table which is causing
crashes during boot on some systems. Typically this is causing a crash
on VMWare when using UEFI and enabling serial autodetection, as
grub_acpi_find_table (GRUB_ACPI_SPCR_SIGNATURE);
will goes past the end of the table (the SPCR table doesn't exits).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Tested-by: Renata Ravanelli <rravanel@redhat.com>
For NX the GRUB binary has to announce that it is compatible with the
NX feature. This implies that when loading the executable GRUB image
several attributes are true:
- the binary doesn't need an executable stack,
- the binary doesn't need sections to be both executable and writable,
- the binary knows how to use the EFI Memory Attributes Protocol on code
it is loading.
This patch:
- adds a definition for the PE DLL Characteristics flag GRUB_PE32_NX_COMPAT,
- changes grub-mkimage to set that flag.
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Jan Setje-Eilers <jan.setjeeilers@oracle.com>
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
For NX we need to set write and executable permissions on the sections
of GRUB modules when we load them. All allocatable sections are marked
readable. In addition:
- SHF_WRITE sections are marked as writable,
- and SHF_EXECINSTR sections are marked as executable.
Where relevant for the platform the tramp and GOT areas are marked non-writable.
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Jan Setje-Eilers <jan.setjeeilers@oracle.com>
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
For NX we need to set the page access permission attributes for write
and execute permissions. This patch adds two new primitives, grub_set_mem_attrs()
and grub_clear_mem_attrs(), and associated constants definitions used
for that purpose. For most platforms it adds a dummy implementation.
On EFI platforms it implements the primitives using the EFI Memory
Attribute Protocol, defined in UEFI 2.10 specification.
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Jan Setje-Eilers <jan.setjeeilers@oracle.com>
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Currently we load module sections at whatever alignment gcc+ld happened
to dump into the ELF section header which is often less then the page
size. Since NX protections are page based this alignment must be rounded
up to page size on platforms supporting NX protections. This patch
switches EFI platforms to load module sections at 4 KiB page-aligned
addresses. It then changes the allocation size computation and the
loader code in grub_dl_load_segments() to align the locations and sizes
up to these boundaries and fills any added padding with zeros. All of
this happens before relocations are applied, so the relocations factor
that in with no change.
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Jan Setje-Eilers <jan.setjeeilers@oracle.com>
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Currently when loading GRUB modules we allocate space for all sections
including those without SHF_ALLOC set. We then copy the sections that
/do/ have SHF_ALLOC set into the allocated memory leaving some of our
allocation untouched forever. Additionally, on platforms with GOT fixups
and trampolines we currently compute alignment round-ups for the
sections and sections with sh_size = 0. This patch removes the extra
space from the allocation computation and makes the allocation
computation loop skip empty sections as the loading loop does.
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Jan Setje-Eilers <jan.setjeeilers@oracle.com>
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-By: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Currently GRUB modules built with Clang or GCC have several sections
which we don't actually need or support. We already have a list of
sections to skip in genmod.sh and this patch adds the following
sections to that list (as well as a few newlines):
- .note.gnu.property
- .llvm*
Note that the glob there won't work without a new enough linker but the
failure is just reversion to the status quo. So, that's not a big problem.
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Jan Setje-Eilers <jan.setjeeilers@oracle.com>
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-By: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Currently .module_license is set writable, that is, the section has the
SHF_WRITE flag set, in the module's ELF headers. This probably never
actually matters but it can't possibly be correct. The patch sets that
data as "const" which causes that flag not to be set.
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Jan Setje-Eilers <jan.setjeeilers@oracle.com>
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-By: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This is an x86-specific thing and should be available globally.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This fixes naming inconsistency that goes against coding style as well
as helps to avoid potential conflicts and confusion as this constant is
used in multiple places.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Currently rdmsr and wrmsr commands have own MSR support detection code.
This code is the same. So, it is duplicated. Additionally, this code
cannot be reused by others. Hence, extract this code to a function and
make it public. By the way, improve a code a bit.
Additionally, use GRUB_ERR_BAD_DEVICE instead of GRUB_ERR_BUG to signal
an error because errors encountered by this new routine are not bugs.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Use more obvious names which match corresponding instructions:
* grub_msr_read() => grub_rdmsr(),
* grub_msr_write() => grub_wrmsr().
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
It does not make sense to have separate headers for individual static
functions. So, make one common place to store them.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The loopback image is configured to function as a disk by being mapped
as a block device. Instead of measuring the entire block device we
should focus on tracking the individual files accessed from it. For
example, we do not directly measure block devices like hd0 disk but the
files opened from it.
This method is important to avoid running out of memory since loopback
images can be very large. Trying to read and measure the whole image at
once could cause out of memory errors and disrupt the boot process.
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Similarly to the issue described in commit c52ae4057 (efinet: skip
virtual IPv4 and IPv6 devices during card enumeration) the UEFI PXE
driver creates additional VLAN child devices when a VLAN ID is
configured on a network interface associated with a physical NIC. These
virtual VLAN devices must be skipped during card enumeration to ensure
that the subsequent SNP exclusive open operation targets the correct
physical card instances. Otherwise packet transfer would fail.
A device path example with VLAN nodes:
/MAC(123456789ABC,0x1)/Vlan(20)/IPv4(0.0.0.0,0x0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
A regression in GRUB 2.12 causes the GRUB screen to become cluttered
with artifacts from the previous screen whether it's the UEFI post UI,
UEFI shell or any graphical UI running before GRUB. This issue occurs
in situations like booting GRUB from the UEFI shell and going straight
to the rescue or command shell causing visual discomfort.
The regression was introduced by commit 2d7c3abd8 (efi/console: Do not
set text-mode until it is actually needed). To address the screen
flickering issue this commit suppresses the text-mode setting until the
first output is requested. Before text-mode is set any attempt to clear
the screen has no effect. This inactive period renders the clear screen
ineffective in early boot stages, potentially leaving leftover artifacts
that will clutter the GRUB console display, as there is no guarantee
there will always be a clear screen after the first output.
The issue is fixed by ensuring grub_console_cls() to work through lazy
mode-setting, while also avoiding screen clearing for the hidden menu
which the flicker-free patch aims to improve.
Fixes: 2d7c3abd8 (efi/console: Do not set text-mode until we actually need it)
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The cycle register is not guaranteed to count at constant frequency.
If it is counting at all depends on the state the performance monitoring
unit. Use the time register to measure time.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Avoid dangling pointer. Code should not be reached but better safe than sorry.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
They are single 64-bit values. Used in other assembly files too.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The instruction uses a 64-bit immediate.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The function called is grub_utf8_to_utf16().
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Assembly code looks for modules at __bss_start. Make this position explicit
rather than matching BSS alignment and module alignment.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Module structure has natural alignment of 4. Respect it explicitly
rather than relying on the fact that _end is usually aligned.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Otherwise it breaks the decompressors for MIPS targets.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Without it compiler generates GPREL16 references which do not work
with our memory layout.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
BCJ is not available for all platforms hence arguments may end up unused.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Otherwise depending on compiler we end up with umoddi3 reference and
failed module dependency resolution.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Users have no reason to see this and it can break graphical boot.
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add documentation for all GRUB modules contained in the source code tree.
When possible, cross-references to additional detail on commands was added
from their corresponding module documentation. In addition, documentation
for the file command was added.
Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The get_part_uuid() function made an assumption that the target GRUB
device is a partition device and accessed device->disk->partition
without checking for NULL. There are four situations where this
assumption is problematic:
1. The device is a net device instead of a disk.
2. The device is an abstraction device, like LVM, RAID, or CRYPTO, which
is mostly logical "disk" ((lvmid/<UUID>) and so on).
3. Firmware RAID may present the ESP to GRUB as an EFI disk (hd0) device
if it is contained within a Linux software RAID.
4. When booting from a CD-ROM, the ESP is a VFAT image indexed by the El
Torito boot catalog. The boot device is set to (cd0), corresponding
to the CD-ROM image mounted as an ISO 9660 filesystem.
As a result, get_part_uuid() could lead to a NULL pointer dereference
and trigger a synchronous exception during boot if the ESP falls into
one of these categories. This patch fixes the problem by adding the
necessary checks to handle cases where the ESP is not a partition device.
Additionally, to avoid disrupting the boot process, this patch relaxes
the severity of the errors in this context to non-critical. Errors will
be logged, but they will not prevent the boot process from continuing.
Fixes: e0fa7dc84 (bli: Add a module for the Boot Loader Interface)
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-By: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
As reported by Victoriia Egorova in bug 65880, grub-mkrescue does not
verify that the expected argument of an option like -d or -k does really
exist in argv. So, check the loop counter before incrementing it inside
the loop which copies argv to argp_argv. Issue an error message similar
to what older versions of grub-mkrescue did with a missing argument,
e.g. 2.02.
Fixes: https://savannah.gnu.org/bugs/index.php?65880
Signed-off-by: Thomas Schmitt <scdbackup@gmx.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The fdtdump command allows dumping arbitrary device tree properties
and saving them to a variable similar to the smbios command.
This is useful in scripts where further actions such as selecting
a kernel or loading another device tree depend on the compatible
or model values of the device tree provided by the firmware.
For now only the root level properties of the dtb are exposed.
Signed-off-by: Tobias Heider <tobias.heider@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
First they're use macros so they can't be translated as-is.
Second there is no point in translating them as they're too technical.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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>
Silently keeping entries in the list if the address matches, but the
page count doesn't is a bad idea, and can lead to double frees.
grub_efi_free_pages() have already freed parts of this block by this
point, and thus keeping the whole block in the list and freeing it again
at exit can lead to double frees.
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
If the firmware happens to return 0 as an address of allocated pages,
grub_efi_allocate_pages_real() tries to allocate a new set of pages,
and then free the ones at address 0.
However at that point grub_efi_store_alloc() wasn't yet called, so
freeing the pages at 0 using grub_efi_free_pages() which calls
grub_efi_drop_alloc() isn't necessary, so let's call b->free_pages()
instead.
The call to grub_efi_drop_alloc() doesn't seem particularly harmful,
because it seems to do nothing if the allocation it is asked to drop
isn't on the list, but the call to it is obviously unnecessary here.
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
If the map was too big for the initial allocation, it was freed and replaced
with a bigger one, but the free call still used the hard-coded size.
Seems like this wasn't hit for a long time, because most firmware maps
fit into 12K.
This bug was triggered on Project Mu firmware with a big memory map, and
results in the heap getting trashed and the firmware ASSERTING on
corrupted heap guard values when GRUB exits.
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
mkfs.erofs with version < 1.6 does not support the -L option.
Let's detect the version of mkfs.erofs and skip the label tests
if it is not supported.
Suggested-by: Glenn Washburn <development@efficientek.com>
Signed-off-by: Yifan Zhao <zhaoyifan@sjtu.edu.cn>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The current Debian stable, now 12, has dropped the exfat-utils package
that the exfat filesystem test requires to run. There is an exfatprogs
package that replaces exfat-utils, though it is not a drop-in replacement
because mkfs.exfat has differing command line option names. Note, that
we're not yet switching to using the exfat kernel module because this
allows the testings on kernels that do not have the module.
Update mkfs.exfat usage to adhere to the different exfatprogs usage. Also,
the exfatprogs mkfs.exfat, following the exfat specification more closely,
only allows a maximum of 22 bytes of UTF-16 characters in the volume label
compared to 30 bytes from exfat-utils. So the exfat label test is updated
accordingly.
Update documentation to note that exfatprogs is now needed and also
exfat-fuse, which is needed do the fuse mount.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When $detached_header was set 1, $luksdiskfile was set to the LUKS header
file path with "${detached_header:-$luksfile}" appended, which evaluates
to "1". Fix this by using two statements to set $luksdiskfile. The first
sets it to the header file if $detached_header is set, otherwise leave it
unset. The second statement sets it to itself if it is already set,
otherwise it is set to $luksfile.
Fixes: a7b540e6e (tests: Add cryptomount functional test)
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
First look for firmware files in the source directory and then, if not
found, look for them in locations where Debian installs them. Prefer to
use the unified firmware file and, if not found, use the pflash firmware
files split in to code and variables. By looking for files in the source
directory first, system firmware files can be overridden and it can be
ensured that the tests can be run regardless of the distro or where the
system firmware files are stored. If no firmware files are found, print
an error message and exit with error.
If a firmware VARS file is found, use it with snapshot mode enabled, which
makes the VARS writable to the virtual machine, but does not write back
the changes to the file. This allows using the readonly system VARS file
without copying it or using it in readonly mode, which causes the ARM
machine to fail. This also gives tests effectively their own ephemeral VARS
file that can be written to without causing side-effects for other tests.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
According to the OVMF whitepaper [1]:
IMPORTANT: Never pass OVMF.fd to qemu with the -bios option. That option
maps the firmware image as ROM into the guest's address space, and forces
OVMF to emulate non-volatile variables with a fallback driver that is
bound to have insufficient and confusing semantics.
Use the pflash interface instead. Currently the unified firmware file is
used, which contains both firmware code and variable sections. By enabling
snapshot on the pflash device, the firmware can be loaded in such a way
that variables can be written to without writing to the backing file.
Since pflash does no searching for firmware paths that are not absolute,
unlike the -bios option, also make firmware paths absolute. Additionally,
update the previous firmware paths or file names that did not correspond to
ones installed by Debian.
Use the q35 machine, instead of the default i440fx, for i386-efi because
the default machine type does not emulate a flash device, which is now
needed to load the firmware.
[1] http://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Allow using GDB to debug a failing QEMU test. This output does not cause
issues for tests because it happens before the trim line, and so will be
ignored.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Type 0x01 was introduced with the ACPI DBGP table and type 0x12 was introduced
with the ACPI DBG2 table. Type 0x12 is used by the ACPI SPCR table on recent
AWS bare-metal instances (c6i/c7i). Also give each debug type a proper name.
Signed-off-by: Udo Steinberg <udo@hypervisor.org>
Reviewed-by: Glenn Washburn <development@efficientek.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>
When GRUB image is netbooted on ppc64le, the keyboard input exhibits
significant latency, reports even say that characters are processed
about once per second. This issue makes interactively trying to debug
a ppc64le config very difficult.
It seems that the latency is largely caused by a 200 ms timeout in the
idle event loop, during which the network card interface is consistently
polled for incoming packets. Often, no packets arrive during this
period, so the timeout nearly always expires, which blocks the response
to key inputs.
Furthermore, this 200 ms timeout might not need to be enforced at this
basic layer, considering that GRUB performs synchronous reads and its
timeout management is actually handled by higher layers, not directly in
the card instance. Additionally, the idle polling, which reacts to
unsolicited packets like ICMP and SLAAC, would be fine at a less frequent
polling interval, rather than needing a timeout for receiving a response.
For these reasons, we believe the timeout in get_card_packet() should be
effectively removed. According to test results, the delay has disappeared,
and it is now much easier to use interactively.
Signed-Off-by: Michael Chang <mchang@suse.com>
Tested-by: Tony Jones <tonyj@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The measurements for confidential computing has been introduced in the
commit 4c76565b6 (efi/tpm: Add EFI_CC_MEASUREMENT_PROTOCOL support).
Recently the patch 30708dfe3 (tpm: Disable the tpm verifier if the TPM
device is not present) has been introduced to optimize the memory usage
when a TPM device is not available on platforms. This fix prevents the
tpm module to be loaded on confidential computing platforms, e.g. Intel
machines with TDX enabled, where the TPM device is not available.
In this patch, we propose to load the tpm module for this use case by
generalizing the tpm feature detection in order to cover CC platforms.
Basically, we do it by detecting the availability of the
EFI_CC_MEASUREMENT_PROTOCOL EFI protocol.
Fixes: https://savannah.gnu.org/bugs/?65821
Fixes: 30708dfe3 (tpm: Disable the tpm verifier if the TPM device is not present)
Signed-off-by: Hector Cao <hector.cao@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Allocate memory if needed, while saving the corresponding release
operation, reducing the amount of code and code complexity.
Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch adds support for Radix, Xive and Radix_gtse in Options
vector5 which is required for KVM LPARs. KVM LPARs ONLY support
Radix and not the Hash. Not enabling Radix on any PowerVM KVM LPARs
will result in boot failure.
Signed-off-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
We don't need any actual adjustments as we don't use the affected structures.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Without them, e.g., 0x80LL on 64-bit target is 32-bit byte-swapped to
0xffffffff80000000 instead of correct 0x80000000.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
ARRAY_SIZE() is the count of elements, but the element size is 4 bytes, so
this was only initing the first 1/4th of the table. Detected with valgrind.
This should only matter in error paths, and I've not been able to identify
any actual misbehaviour that results from reading in-bounds but uninited data.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This isn't intended to be a functional change, but it makes a lot of failures a lot
faster, which is extremely helpful for fuzzing.
Without this change, we keep trying and trying to read more bytes into our buffer,
never being able to (read always returns 0) and so we just return old buffer contents
over and over until the decompression process fails some other way.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add functionality to disable command line interface access and editing of GRUB
menu entries if GRUB image is built with --disable-cli.
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The EROFS [1] is a lightweight read-only filesystem designed for performance
which has already been shipped in most Linux distributions as well as widely
used in several scenarios, such as Android system partitions, container
images and rootfs for embedded devices.
This patch brings in the EROFS uncompressed support. Now, it's possible to
boot directly through GRUB with an EROFS rootfs.
Support for the EROFS compressed files will be added later.
[1] https://erofs.docs.kernel.org
Signed-off-by: Yifan Zhao <zhaoyifan@sjtu.edu.cn>
Tested-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The following EROFS patch will use this helper to handle
ALIGN_UP() overflow.
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This is required if the pathname contains spaces or GRUB shell
metacharacters else the generated config file check will fail.
Signed-off-by: Pascal Hambourg <pascal@plouf.fr.eu.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When handling a regular LVM volume, GRUB can fail with the message:
error: disk `lvmid/******-****-****-****-****-****-****/******-****-****-****-****-****-******' not found.
If the condition which triggers this exists, grub-probe will report the
error mentioned above. Similarly, the GRUB boot code will fail to detect
LVM volumes, resulting in a failure to boot off of LVM disks/partitions.
The condition can be created on any LVM VG by an LVM configuration change,
so any system with /boot on LVM can become unbootable at "any" time (after
any LVM configuration change).
The problem is caused by an incorrect computation of mda_end in disk/lvm.c,
when the metadata area wraps around. Apparently, this can start happening at
around 220 metadata changes to the VG.
Fixes: 879c4a834 (lvm: Fix two more potential data-dependent alloc overflows)
Fixes: https://savannah.gnu.org/bugs/?61620
Signed-off-by: Rogier <rogier777@gmail.com>
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-By: Michael Chang <mchang@suse.com>
Give the user a chance to re-enter their cryptodisk passphrase after a typo,
rather than immediately failing (and likely dumping them into a GRUB shell).
By default, we allow 3 tries before giving up. A value in the
cryptodisk_passphrase_tries environment variable will override this default.
The user can give up early by entering an empty passphrase, just as they
could before this patch.
Signed-off-by: Forest <forestix@nom.one>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The test corpus for version-1 RAID generated an infinite recursion
in grub_partition_iterate() while attempting to read the superblock.
The reason for the issue was that the data region overlapped with
the superblock.
The infinite call loop looks like this:
grub_partition_iterate() -> partmap->iterate() ->
-> grub_disk_read() -> grub_disk_read_small() ->
-> grub_disk_read_small_real() -> grub_diskfilter_read() ->
-> read_lv() -> read_segment() -> grub_diskfilter_read_node() ->
-> grub_disk_read() -> grub_disk_read_small() -> ...
The fix adds checks for both the superblock region and the data
region when parsing the superblock metadata in grub_mdraid_detect().
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The "ground truth" stack protector cookie value is kept in a global
variable, and loaded in every function prologue and epilogue to store
it into resp. compare it with the stack slot holding the cookie.
If the comparison fails, the program aborts, and this might occur
spuriously when the global variable changes values between the entry and
exit of a function. This implies that assigning the global variable at
boot should not involve any instrumented function calls, unless special
care is taken to ensure that the live call stack is synchronized, which
is non-trivial.
So avoid any function calls, including grub_memcpy(), which is
unnecessary given that the stack cookie is always a suitably aligned
variable of the native word size.
While at it, leave the last byte 0x0 to avoid inadvertent unbounded
strings on the stack.
Note that the use of __attribute__((optimize)) is described as
unsuitable for production use in the GCC documentation, so let's drop
this as well now that it is no longer needed.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add a new keyword, "depends", to the module definition syntax
used in Makefile.core.def. This allows specifying explicit module
dependencies together with the module definition.
Do not track the "extra_deps.lst" file in the repository anymore,
it is now auto-generated.
Make use of this new keyword in the bli module definition.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Otherwise the GRUB cannot start due to missing symbols when stack
protector is enabled on EFI platforms.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
_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>
The CMOS actually exists on most EFI platforms and in some cases is used to
store useful data that makes it justifiable for GRUB to read/write it.
As for date and time keep using EFI API and not CMOS one.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.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>
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.
grub_video_bitmap_load (&box->raw_pixmaps[i], path);
grub_free (path);
/* Ignore missing pixmaps. */
grub_errno = GRUB_ERR_NONE;
In any case, we cannot account on such random behavior and should only
return grub_errno if it is justified.
On the occasion move the grub_video_bitmap struct definition to the
beginning of the function.
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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>
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>
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>
The 64-bit ABI defines ld.so to be /lib/ld-x86-64.so.1.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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>
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>
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>
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>
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>
Fixes build failure due to the extra_deps.lst file not existing in the
tarball. Found while trying to package GRUB 2.12 for Gentoo.
make[3]: *** No rule to make target '/var/tmp/portage/sys-boot/grub-2.12/work/grub-2.12/grub-core/extra_deps.lst', needed by 'syminfo.lst'. Stop.
Fixes: 89fbe0cac (grub-core/Makefile.am: Make path to extra_deps.lst relative to $(top_srcdir)/grub-core)
Fixes: 154dcb1ae (build: Allow explicit module dependencies)
Signed-off-by: Oskari Pirhonen <xxc3ncoredxx@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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.
[1] https://reproducible-builds.org/specs/source-date-epoch
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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>
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.
[1] https://www.sans.org/blog/stack-canaries-gingerly-sidestepping-the-cage/
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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>
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>
NetBSD uses slightly different function names for the same functions.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
NetBSD gettext is older than the check but we don't actually need 0.18.3,
older one works fine. This is needed to make bootstrap work on NetBSD.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.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>
Without this build-time mkfont fails dynamic linking. This is not ideal
but improves the situation until a better solution is available.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
*BSD puts fonts in other places. Add them to the list.
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>
It's not critical, -Werror on it is inappropriate. We don't want to
modify gnulib too much. This warning is pretty much irrelevant.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
It's not available on NetBSD outside of syslog. Using strerror() is more
reliable as we retrieve errno immediately rather than down the stack.
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>
After recent change in blocklist types we have a type mismatch. Fixing it
requires a wrapper or large changes. I feel like wrapper makes more sense.
Without this patch we end up with a compilation problem and without wrapping
callback data is not passed properly anymore.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Variable e is set but never used. We can just remove it now.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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>
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>
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.
Fixes: 154dcb1ae (build: Allow explicit module dependencies)
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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>
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>
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>
Replace definition of HTTP_PORT with a pre-processor macro that converts
the constant to the correct grub_uint16_t type.
Change "port" local variable definition in http_establish() to have the
same type.
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com
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>
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>
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>
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>
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>
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>
Display upper_mem_limit and its rounded-down value in MiB.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.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>
Introduce flags to identify PowerVM and KVM on Power and set them where
each type of host has been detected.
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>
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>
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>
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>
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>
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>
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>
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 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>
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>
known_protocols isn't used anywhere else and even misses grub_ prefix, so
let's make it local (static).
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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>
Font might be located in different location, the default font might
not be available on all systems or other font might be preferred.
Signed-off-by: Richard Marko <srk@48.io>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Font might be located in different location, the default font might
not be available on all systems or other font might be preferred.
Signed-off-by: Mads Kiilerich <mads@kiilerich.com>
Signed-off-by: Richard Marko <srk@48.io>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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>
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>
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>
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.
See: https://lore.kernel.org/grub-devel/d42a11fa-2a59-b5e7-08b1-d2c60444bb99@valdikss.org.ru/
Signed-off-by: ValdikSS <iam@valdikss.org.ru>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The code flushes the cache on VIA processors unconditionally which
is excessive. Check for cpuid family and execute wbinvd only on C3
and earlier.
Fixes: https://savannah.gnu.org/bugs/?45149
Fixes: 25492a0f0 (Add wbinvd around bios call.)
Signed-off-by: ValdikSS <iam@valdikss.org.ru>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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.
Signed-off-by: Fabian Vogt <fvogt@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
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>
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>
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>
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>
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: 712309eaae (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>
E.g. 2.10 instead of 00020064 and 2.3.1 instead of 0002001f.
See UEFI 2.10 specification, chapter 4.2.1 EFI_TABLE_HEADER.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Move some calls used to access NTFS attribute header fields into
functions with human-readable names.
Suggested-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This fix introduces checks to ensure that an NTFS volume label is always
read from the corresponding file record segment.
The current NTFS code allows the volume label string to be read from an
arbitrary, attacker-chosen memory location. However, the bytes read are
always treated as UTF-16LE. So, the final string displayed is mostly
unreadable and it can't be easily converted back to raw bytes.
The lack of this check is a minor issue, likely not causing a significant
data leak.
Reported-by: Maxim Suhanov <dfirblog@gmail.com>
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This fix introduces checks to ensure that bitmaps for directory indices
are never read beyond their actual sizes.
The lack of this check is a minor issue, likely not exploitable in any way.
Reported-by: Maxim Suhanov <dfirblog@gmail.com>
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This fix introduces checks to ensure that index entries are never read
beyond the corresponding directory index.
The lack of this check is a minor issue, likely not exploitable in any way.
Reported-by: Maxim Suhanov <dfirblog@gmail.com>
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When reading a file containing resident data, i.e., the file data is stored in
the $DATA attribute within the NTFS file record, not in external clusters,
there are no checks that this resident data actually fits the corresponding
file record segment.
When parsing a specially-crafted file system image, the current NTFS code will
read the file data from an arbitrary, attacker-chosen memory offset and of
arbitrary, attacker-chosen length.
This allows an attacker to display arbitrary chunks of memory, which could
contain sensitive information like password hashes or even plain-text,
obfuscated passwords from BS EFI variables.
This fix implements a check to ensure that resident data is read from the
corresponding file record segment only.
Fixes: CVE-2023-4693
Reported-by: Maxim Suhanov <dfirblog@gmail.com>
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When parsing an extremely fragmented $MFT file, i.e., the file described
using the $ATTRIBUTE_LIST attribute, current NTFS code will reuse a buffer
containing bytes read from the underlying drive to store sector numbers,
which are consumed later to read data from these sectors into another buffer.
These sectors numbers, two 32-bit integers, are always stored at predefined
offsets, 0x10 and 0x14, relative to first byte of the selected entry within
the $ATTRIBUTE_LIST attribute. Usually, this won't cause any problem.
However, when parsing a specially-crafted file system image, this may cause
the NTFS code to write these integers beyond the buffer boundary, likely
causing the GRUB memory allocator to misbehave or fail. These integers contain
values which are controlled by on-disk structures of the NTFS file system.
Such modification and resulting misbehavior may touch a memory range not
assigned to the GRUB and owned by firmware or another EFI application/driver.
This fix introduces checks to ensure that these sector numbers are never
written beyond the boundary.
Fixes: CVE-2023-4692
Reported-by: Maxim Suhanov <dfirblog@gmail.com>
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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>
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>
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>
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>
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>
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>
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>
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>
Reading them is harmless but useless as they are empty by definition
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
We ended up comparing over unset values as we had dnode_phys on one side
and dnode on another
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This is a speedup used in some ZFS version. This trips GRUB and makes it
unable to access directories. Just skip it for now and revisit
if we ever need this speedup.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
If the EFI graphics pixel format is PixelBltOnly, we cannot write directly
to the frame buffer. We need the shadow frame buffer which we copy via
the BitBlt operation to the hardware.
If the pixel format is PixelBltOnly and allocation of the shadow frame
buffer fails, we must raise an error to signal that the EFI GOP protocol
is not usable.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
It has been reported that makeinfo version 4.13a complains and returns
error when menus for chapter structuring commands are not present. It
is also known that newer makeinfos, such as version 6.7, will create
default menus when needed. Since the menu will be created regardless,
explicitly create it to support older makeinfo versions. This also
enables building to be successful when an older makeinfo is installed
because in that case info files are attempted to be generated with the
"all" target.
Reported-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Olaf Hering <olaf@aepfle.de>
The @xref command is meant to be used at the beginning of a sentence
because its expansion creates a "See " prefix on all output formats, and
on older makeinfo versions is strict about enforcing a "." or "," after
the command. The @ref command has no such restriction and is just the
link, which allows more control over output. This also fixes an issue
where there was a repeated "see" in the output.
Reported-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Olaf Hering <olaf@aepfle.de>
Allow using the envvar GRUB_SHELL_LUKS_TIMEOUT to change the default
timeout. If not specified, use value of GRUB_SHELL_DEFAULT_TIMEOUT. And
if that is not specified, fallback to original 600s timeout.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This was causing the cryptomount command to return failure even though
the crypto device was successfully added. Of course, this meant that any
script using the return code would behave unexpectedly.
Fixes: 3cf2e848bc (disk/cryptodisk: Allows UUIDs to be compared in a dash-insensitive manner)
Suggested-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Patrich Steinhardt <ps@pks.im>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
To comply with C99 and POSIX standards, snprintf() should return the
number of bytes that would be written to the string (excluding the
terminating NUL byte) if the buffer size was big enough. Before this
change, the return value was the minimum of the standard return and the
length of the buffer. Rarely is the return value of grub_snprintf() or
grub_vsnprintf() used with current code, and the few places where it is
used do not need to be changed.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This test is meant to test output via various serial devices. Currently,
only the PCI serial device is tested.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
While here, move "-qemu=*" case to be next to the "--qemu-opts=*" case.
This causes no change in logic, but is more logically located.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In long list mode, if the file can not be opened, the file is not printed.
Instead, print the file but print the size as "????????????".
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
For each non-directory path argument to the ls command, the full path was
being sent to the print functions, instead of the dirname. The long output
print function expected dirname to be the directory containing the file
and so could not open the file to get the file size because the generated
path was incorrect. This caused the output to be a blank line.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Specifically, return GRUB_ERR_BAD_FILE_TYPE because this is what is
expected by the ls command when it is given a path to a non-directory.
This fixes a bug where calling ls with a list of non-directory paths
outputs a blank line for each such argument.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The videoinfo command will initialize all non-active video adapters. Video
drivers tend to zero out the global framebuffer object on initialization.
This is not a problem when there is no active video adapter. However, when
there is, then outputting to the video adapter will cause a crash because
methods in the framebuffer object are reinitialized. For example, this
command sequence will cause a crash.
terminal_output --append gfxterm; videoinfo
When running in a QEMU headless with GRUB built for the x86_64-efi target,
the first command initializes the Bochs video adapter, which, among
other things, sets the set_page() member function. Then when videoinfo is
run, all non-Bochs video adapters will be initialized, each one wiping
the framebuffer and thus setting set_page to NULL. Soon after the videoinfo
command finishes there will be a call to grub_refresh(), which will
ultimately call the framebuffer's set_page which will be NULL and cause
a crash when called.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
A list of improvements:
* Remove reference to "initial ramdisk" and replace with "initrd". This
then covers the case of ramdisk and ramfs, which is the usual method
with kernels 2.6 and newer.
* Add sentence with URL to initrd documentation Linux kernel.
* Add a section documenting how to have the initrd command generate
a new-style initrd via a specially crafted argument and include an example.
* Update initrd16 to refer to the initrd section and make note that
initrd16 is only on the pc platform.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Oskari Pirhonen <xxc3ncoredxx@gmail.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
According to commit 0231d00082 (ACPI: SPCR: Make SPCR available to x86)
to the Linux kernel, "On x86, many systems have a valid SPCR table but the
table version is not 2 so the table version check must be a warning."
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The cat command should not be used to print binary data because it can
show bytes not in the binary data and not show bytes that are in the data,
which can lead to confusion. This happens because cat does some processing
of the data stream, namely trying to decode substrings as UTF-8.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Oskari Pirhonen <xxc3ncoredxx@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
During configuration of SDL2, variable enable_grub_emu_sdl2 is checked
whether to throw an error message. However, error could not happen
because two unequal strings were compared. Fix this by referencing
value of enable_grub_emu_sdl2, not name.
Fixes: 17d6ac1a7 (emu: Add SDL2 support)
Signed-off-by: Michał Grzelak <mchl.grzlk@gmail.com>
Reviewed-by: Julian Andres Klode <julian.klode@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Also reword a prior sentence to be more clear.
Fixes: 5a3d2b4742 (docs: Add debugging chapter to development documentation)
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Oskari Pirhonen <xxc3ncoredxx@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
On an unmerged-usr system, grub-mkconfig errors out with the following
error due to /usr/bin/sh not existing:
/usr/sbin/grub-mkconfig: /etc/grub.d/25_bli: /usr/bin/sh: bad interpreter: No such file or directory
Use a /bin/sh shebang to fix the error as well as match the other
existing files.
Fixes: 158a6583e (util/grub.d/25_bli.in: Activate bli module on EFI)
Signed-off-by: Oskari Pirhonen <xxc3ncoredxx@gmail.com>
Reviewed-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Oliver Steffen <osteffen@redhat.com>
This allows an invocation of grub-shell to set the value of debug regardless
of the global default environment variable GRUB_SHELL_DEFAULT_DEBUG.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Since this is fairly verbose output, do not enable first level of debug
is turned on.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
2023-08-14 16:58:15 +02:00
323 changed files with 32149 additions and 1949 deletions
@ -1799,9 +1876,15 @@ if test x"$starfield_excuse" = x && test x"$enable_build_grub_mkfont" = xno ; th
starfield_excuse="No build-time grub-mkfont"
fi
if test x"$starfield_excuse" = x; then
AC_ARG_WITH([dejavufont],
AS_HELP_STRING([--with-dejavufont=FILE],
[set the DejeVu source [[guessed]]]))
if test "x$with_dejavufont" = x; then
# search in well-known directories
if test x"$starfield_excuse" = x; then
for ext in pcf pcf.gz bdf bdf.gz ttf ttf.gz; do
for dir in . /usr/src /usr/share/fonts/X11/misc /usr/share/fonts/truetype/ttf-dejavu /usr/share/fonts/dejavu /usr/share/fonts/truetype; do
for dir in . /usr/src /usr/share/fonts/X11/misc /usr/share/fonts/truetype/ttf-dejavu /usr/share/fonts/dejavu /usr/share/fonts/truetype /usr/pkg/share/fonts/X11/TTF /usr/local/share/fonts/dejavu /usr/X11R6/lib/X11/fonts/TTF /usr/share/fonts/dejavu-sans-fonts /usr/share/fonts/truetype/dejavu; do
if test -f "$dir/DejaVuSans.$ext"; then
DJVU_FONT_SOURCE="$dir/DejaVuSans.$ext"
break 2
@ -1812,6 +1895,9 @@ if test x"$starfield_excuse" = x; then
if test "x$DJVU_FONT_SOURCE" = x; then
starfield_excuse="No DejaVu found"
fi
fi
else
DJVU_FONT_SOURCE="$with_dejavufont"
fi
if test x"$enable_grub_themes" = xyes && test x"$starfield_excuse" != x; then
@ -1820,10 +1906,14 @@ fi
AC_SUBST([DJVU_FONT_SOURCE])
FONT_SOURCE=
AC_ARG_WITH([unifont],
AS_HELP_STRING([--with-unifont=FILE],
[set the unifont source [[guessed]]]))
for ext in pcf pcf.gz bdf bdf.gz ttf ttf.gz; do
for dir in . /usr/src /usr/share/fonts/X11/misc /usr/share/fonts/unifont /usr/share/fonts/uni /usr/share/fonts/truetype/unifont /usr/share/fonts/misc; do
if test "x$with_unifont" = x; then
# search in well-known directories
for ext in pcf pcf.gz bdf bdf.gz ttf ttf.gz otf otf.gz; do
for dir in . /usr/src /usr/share/fonts/X11/misc /usr/share/fonts/unifont /usr/share/fonts/uni /usr/share/fonts/truetype/unifont /usr/share/fonts/misc /usr/pkg/share/fonts/X11/misc /usr/local/share/fonts/gnu-unifont /usr/local/share/fonts/unifont; do
returngrub_error(GRUB_ERR_BAD_ARGUMENT,N_("empty entry in PCR list"));
if(next_pcr!=NULL)
*next_pcr='\0';
pcr=grub_strtoul(current_pcr,&pcr_end,10);
if(*current_pcr=='\0'||*pcr_end!='\0')
returngrub_error(GRUB_ERR_BAD_NUMBER,N_("entry '%s' in PCR list is not a number"),current_pcr);
if(pcr>TPM_MAX_PCRS-1)
returngrub_error(GRUB_ERR_OUT_OF_RANGE,N_("entry %llu in PCR list is too large to be a PCR number, PCR numbers range from 0 to %u"),(unsignedlonglong)pcr,TPM_MAX_PCRS-1);
pcrs[i]=(grub_uint8_t)pcr;
++(*pcr_count);
if(next_pcr==NULL)
break;
current_pcr=next_pcr+1;
if(*current_pcr=='\0')
returngrub_error(GRUB_ERR_BAD_ARGUMENT,N_("trailing comma at the end of PCR list"));
}
if(i==TPM_MAX_PCRS)
returngrub_error(GRUB_ERR_OUT_OF_RANGE,N_("too many PCRs in PCR list, the maximum number of PCRs is %u"),TPM_MAX_PCRS);
returngrub_error(GRUB_ERR_BAD_NUMBER,N_("TPM handle value '%s' is not a number"),value);
if(num>GRUB_UINT_MAX)
returngrub_error(GRUB_ERR_OUT_OF_RANGE,N_("value %llu is too large to be a TPM handle, TPM handles are unsigned 32-bit integers"),(unsignedlonglong)num);
