When both "dest" and "src" are aligned, copying the data in grub_addr_t
sized chunks is more efficient than a byte-by-byte copy.
Also tweak __aeabi_memcpy(), __aeabi_memcpy4(), and __aeabi_memcpy8(),
since grub_memcpy() is not inline anymore.
Optimization for unaligned buffers was omitted to maintain code
simplicity and readability. The current chunk-copy optimization
for aligned buffers already provides a noticeable performance
improvement (*) for Argon2 keyslot decryption.
(*) On my system, for a LUKS2 keyslot configured with a 1 GB Argon2
memory requirement, this patch reduces the decryption time from
22 seconds to 12 seconds.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This commit introduces grub_crypto_argon2() which leverages the
_gcry_kdf_*() functions from libgcrypt to provide Argon2 support.
Due to the dependency of the _gcry_kdf_*() functions, the order of
"ldadd" entries have to be tweaked in Makefile.util.def so that the
linker can discover these functions.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This commit introduces the necessary changes to crypto.h in preparation
for implementing Argon2 support via the generic KDF functions, _gcry_kdf_*():
- add new GPG error types required by kdf.c,
- declare _gcry_digest_spec_blake2b_512 to enable BLAKE2b-512 digest calculations,
- define the gcrypt KDF algorithm IDs for Argon2,
- add the prototypes of _gcry_kdf_*() functions.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This commit implements grub_tcg2_cap_pcr() for ieee1275 with the
firmware function, 2hash-ext-log, to extend the target PCR with an
EV_SEPARATOR event and record the event into the TPM event log.
To avoid duplicate code, ibmvtpm_2hash_ext_log() is moved to tcg2.c
and exported as a global function.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The Linux kernel's struct bootparams provides a field at offset 0x140
for storing an EDID header. Copy the video adapter's data to the field.
The edid_info field was added in 2003 (see "[FBDEV] EDID support from
OpenFirmware on PPC platoforms and from the BIOS on intel platforms."),
but only got useable in 2004 (see "[PATCH] Fix EDID_INFO in zero-page").
The boot protocol was at version 2.03 at that time.
The field was never used much, but with the recent addition of the efidrm
and vesadrm drivers to the kernel, it becomes much more useful. As with
the initial screen setup, these drivers can make use of the provided
EDID information for basic display output.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
Reviewed-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
With the following change, we see standard (grub_dprintf) and
error (grub_error) logs with the function name embedded (see below)
into the log which is particular useful when debugging:
commands/efi/tpm.c:grub_tpm_measure:281:tpm: log_event, pcr = 8, size = 0xb,
Including one more field on the print log impacts the binary sizes
and in turn their respective distro packages. For Fedora rpm packages
the increase is 20k approximately.
Signed-off-by: Leo Sandoval <lsandova@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Introducing the following GRUB commands to manage certificate/binary
hashes.
1. append_list_dbx:
Show the list of distrusted certificates and binary/certificate
hashes from the dbx list.
2. append_add_db_hash:
Add the trusted binary hash to the db list.
3. append_add_dbx_hash:
Add the distrusted certificate/binary hash to the dbx list.
Note that if signature verification (check_appended_signatures) is set to yes,
the append_add_db_hash and append_add_dbx_hash commands only accept the file
‘hash_file’ that is signed with an appended signature.
Signed-off-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Tested-by: Sridhar Markonda <sridharm@linux.ibm.com>
Reviewed-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
If secure boot is enabled with static key management mode, the trusted
certificates will be extracted from the GRUB ELF Note and added to db list.
If secure boot is enabled with dynamic key management mode, the trusted
certificates and certificate/binary hash will be extracted from the PKS
and added to db list. The distrusted certificates, certificate/binary hash
are read from the PKS and added to dbx list. Both dbx and db lists usage is
added by a subsequent patch.
Note:
- If db does not exist in the PKS storage, then read the static keys as a db
default keys from the GRUB ELF Note and add them into the db list.
- If the certificate or the certificate hash exists in the dbx list, then do not
add that certificate/certificate hash to the db list.
Signed-off-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Enhancing the infrastructure to enable the Platform Keystore (PKS) feature,
which provides access to the SB_VERSION, db, and dbx secure boot variables
from PKS.
If PKS is enabled, it will read secure boot variables such as db and dbx
from PKS and extract EFI Signature List (ESL) from it. The ESLs would be
saved in the Platform Keystore buffer, and the appendedsig module would
read it later to extract the certificate's details from ESL.
In the following scenarios, static key management mode will be activated:
1. When Secure Boot is enabled with static key management mode
2. When SB_VERSION is unavailable but Secure Boot is enabled
3. When PKS support is unavailable but Secure Boot is enabled
Note:
SB_VERSION: Key Management Mode
1 - Enable dynamic key management mode. Read the db and dbx variables from PKS,
and use them for signature verification.
0 - Enable static key management mode. Read keys from the GRUB ELF Note and
use it for signature verification.
Signed-off-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Building on the parsers and the ability to embed X.509 certificates, as well
as the existing gcrypt functionality, add a module for verifying appended
signatures.
This includes a signature verifier that requires that the Linux kernel and
GRUB modules have appended signatures for verification.
Signature verification must be enabled by setting check_appended_signatures.
If secure boot is enabled with enforce mode when the appendedsig module is
loaded, signature verification will be enabled, and trusted keys will be
extracted from the GRUB ELF Note and stored in the db and locked automatically.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Read secure boot mode from 'ibm,secure-boot' property and if the secure boot
mode is set to 2 (enforce), enter lockdown. Else it is considered as disabled.
There are three secure boot modes. They are
0 - disabled
No signature verification is performed. This is the default.
1 - audit
Signature verification is performed and if signature verification fails,
display the errors and allow the boot to continue.
2 - enforce
Lockdown the GRUB. Signature verification is performed and if signature
verification fails, display the errors and stop the boot.
Now, only support disabled and enforce.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This code allows us to parse:
- X.509 certificates: at least enough to verify the signatures on the PKCS#7
messages. We expect that the certificates embedded in GRUB will be leaf
certificates, not CA certificates. The parser enforces this.
- X.509 certificates support the Extended Key Usage extension and handle it by
verifying that the certificate has a Code Signing usage.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> # EKU support
Reported-by: Michal Suchanek <msuchanek@suse.com> # key usage issue
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
To support verification of appended signatures, we need a way to embed the
necessary public keys. Existing appended signature schemes in the Linux kernel
use X.509 certificates, so allow certificates to be embedded in the GRUB core
image in the same way as PGP keys.
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Prior to the addition of the X.509 public key support for appended signature,
current PGP signature relied on the GPG public key. Changing the enum name
from "OBJ_TYPE_PUBKEY" to "OBJ_TYPE_GPG_PUBKEY" to differentiate between x509
certificate based appended signature and GPG certificate based PGP signature.
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add infrastructure to allow firmware to verify the integrity of GRUB
by use of a Linux-kernel-module-style appended signature. We initially
target powerpc-ieee1275, but the code should be extensible to other
platforms.
Usually these signatures are appended to a file without modifying the
ELF file itself. (This is what the 'sign-file' tool does, for example.)
The verifier loads the signed file from the file system and looks at the
end of the file for the appended signature. However, on powerpc-ieee1275
platforms, the bootloader is often stored directly in the PReP partition
as raw bytes without a file-system. This makes determining the location
of an appended signature more difficult.
To address this, we add a new ELF Note.
The name field of shall be the string "Appended-Signature", zero-padded
to 4 byte alignment. The type field shall be 0x41536967 (the ASCII values
for the string "ASig"). It must be the final section in the ELF binary.
The description shall contain the appended signature structure as defined
by the Linux kernel. The description will also be padded to be a multiple
of 4 bytes. The padding shall be added before the appended signature
structure (not at the end) so that the final bytes of a signed ELF file
are the appended signature magic.
A subsequent patch documents how to create a GRUB core.img validly signed
under this scheme.
Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Attempts to build GRUB with Clang were failing due to errors such as:
error: redefinition of typedef 'gcry_md_hd_t' is a C11 feature
Correct this by adding a compiler pragma to disable the Clang
"typedef-redefinition" warnings. This required an update to
include/grub/crypto.h and the util/import_gcry.py script to add the
pragma to libgcrypt-grub's types.h due to u16 and similar types.
Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
A Unified Kernel Image (UKI) is a single UEFI PE file that combines
a UEFI boot stub, a Linux kernel image, an initrd, and further resources.
The uki command will locate where the UKI file is and create a GRUB menu
entry to load it.
The Unified Kernel Image Specification: https://uapi-group.org/specifications/specs/unified_kernel_image/
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Irritatingly, BLS defines paths relative to the mountpoint of the
filesystem which contains its snippets, not / or any other fixed
location. So grub-emu needs to know whether /boot is a separate
filesystem from / and conditionally prepend a path.
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Adding filevercmp support to grub-core/commands/blsuki.c from gnulib will cause
issues with the type of the offset parameter for grub_util_write_image_at() for
emu builds. To fix this issue, we can change the type from off_t to grub_off_t.
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The BootLoaderSpec (BLS) defines a scheme where different bootloaders can
share a format for boot items and a configuration directory that accepts
these common configurations as drop-in files.
The BLS Specification: https://uapi-group.org/specifications/specs/boot_loader_specification/
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Will Thompson <wjt@endlessm.com>
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add the functions grub_strtok() and grub_strtok_r() to help parse strings into
tokens separated by characters in the "delim" parameter. These functions are
present in gnulib but calling them directly from the gnulib code is quite
challenging since the call "#include <string.h>" would include the header file
grub-core/lib/posix_wrap/string.h instead of grub-core/lib/gnulib/string.h,
where strtok() and strtok_r() are declared. Since this overlap is quite
problematic, the simpler solution was to implement the code in the GRUB based
on gnulib's implementation. For more information on these functions, visit the
Linux Programmer's Manual, man strtok.
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Xen traditionally allows customizing guest behavior by passing arguments
to the VM kernel via the kernel command line. This is no longer possible
when using GRUB with Xen, as the kernel command line is decided by the
GRUB configuration file within the guest, not data passed to the guest
by Xen.
To work around this limitation, enable GRUB to parse a command line
passed to it by Xen, and expose data from the command line to the GRUB
configuration as environment variables. These variables can be used in
the GRUB configuration for any desired purpose, such as extending the
kernel command line passed to the guest. The command line format is
inspired by the Linux kernel's command line format.
To reduce the risk of misuse, abuse, or accidents in production, the
command line will only be parsed if it consists entirely of 7-bit ASCII
characters, only alphabetical characters and underscores are permitted
in variable names, and all variable names must start with the string
"xen_grub_env_". This also allows room for expanding the command line
arguments accepted by GRUB in the future, should other arguments end up
becoming desirable in the future.
Signed-off-by: Aaron Rainbolt <arraybolt3@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The cmd_line field of the start_info struct is not guaranteed to be
NUL-terminated, even though it is intended to contain a NUL-terminated
string. Add a warning about this in a comment so future consumers of
this field know to check it for a NUL terminator before using it.
Signed-off-by: Aaron Rainbolt <arraybolt3@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
We need to avoid clobbering existing table between starting of chunk movers
and the moment we install target page table. Generate temporary table for
this rather than hoping that we don't clobber existing one.
Fixes 64-bit GhostBSD on 64-bit EFI.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The include/xen/xen.h header was using an overly generic name to refer
to the maximum length of the command line passed from Xen to a guest.
Rename it to avoid confusion or conflicts in the future.
Signed-off-by: Aaron Rainbolt <arraybolt3@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
It turns out checking from userspace is not 100% reliable to figure out
whether the firmware had TPM2 support enabled or not. For example with
EDK2 arm64, the default upstream build config bundles TPM2 support with
SecureBoot support, so if the latter is disabled, TPM2 is also unavailable.
But still, the ACPI TPM2 table is created just as if it was enabled. So,
/sys/firmware/acpi/tables/TPM2 exists and looks correct but there are no
measurements, neither the firmware nor the loader/stub can do them, and
/sys/kernel/security/tpm0/binary_bios_measurements does not exist.
So, userspace cannot really tell what was going on in UEFI mode.
The loader can use the apposite UEFI protocol to check, which is a more
definitive answer. Export the bitmask with the list of active banks as-is.
If it's not 0, then in userspace we can be sure a working TPM2 was available
in UEFI mode.
systemd-boot and systemd-stub v258 (current main) set this variable and
userspace portion consumes it to be able to tell what was available in
the firmware context.
Signed-off-by: Luca Boccassi <luca.boccassi@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patches modifies the GRUB-libgcrypt API to match new libgcrypt 1.11.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Not reusing these handles will result in image measurements showing up
twice in the event log.
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Use loader protocol for image verification where available, otherwise
fall back to the old shim lock protocol.
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
These can be used to register a different implementation later,
for example, when shim provides a protocol with those functions.
Signed-off-by: Julian Andres Klode <julian.klode@canonical.com>
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When attempting to build grub-emu the compilation failed with the
following error message:
include/grub/dl.h: In function ‘grub_dl_is_persistent’:
include/grub/dl.h:262:1: error: no return statement in function returning non-void [-Werror=return-type]
To avoid the error make the function always return 0.
Fixes: ba8eadde6be1 (dl: Provide a fake grub_dl_set_persistent() and grub_dl_is_persistent() for the emu target)
Signed-off-by: Gary Lin <glin@suse.com>
Cc: Daniel Axtens <dja@axtens.net>
Cc: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
(grub_size_t) -1 is never returned, the function always return
a not negative values. This is important for overflows considerations.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Trying to start grub-emu with a module that calls grub_dl_set_persistent()
and grub_dl_is_persistent() will crash because grub-emu fakes modules and
passes NULL to the module init function.
Provide an empty function for the emu case.
Fixes: ee7808e2197c (dl: Add support for persistent modules)
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Avnish Chouhan <avnish@linux.ibm.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>
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>
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>
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>
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>
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 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>
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>
