Daniel Axtens [Sun, 21 Aug 2022 12:22:35 +0000 (22:22 +1000)]
disk/diskfilter: Check calloc() result for NULL
With wildly corrupt inputs, we can end up trying to calloc a very
large amount of memory, which will fail and give us a NULL pointer.
We need to check that to avoid a crash. (And, even if we blocked
such inputs, it is good practice to check the results of allocations
anyway.)
Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Fri, 19 Aug 2022 23:06:15 +0000 (18:06 -0500)]
disk/cryptodisk: Allows UUIDs to be compared in a dash-insensitive manner
A user can now specify UUID strings with dashes, instead of having to remove
dashes. This is backwards-compatibility preserving and also fixes a source
of user confusion over the inconsistency with how UUIDs are specified
between file system UUIDs and cryptomount UUIDs. Since cryptsetup, the
reference implementation for LUKS, displays and generates UUIDs with dashes
there has been additional confusion when using the UUID strings from
cryptsetup as exact input into GRUB does not find the expected cryptodisk.
A new function grub_uuidcasecmp() is added that is general enough to be used
other places where UUIDs are being compared.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Patrick Steinhardt <ps@pks.im> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Fri, 26 Aug 2022 00:53:51 +0000 (19:53 -0500)]
kern/corecmd: Quote variable values when displayed by the set command
Variable values may contain spaces at the end or newlines. However, when
displayed without quotes this is not obvious and can lead to confusion as
to the actual contents of variables. Also for some variables grub_env_get()
returns a NULL pointer instead of a pointer to an empty string and
previously would be printed as "var=(null)". Now such variables will be
displayed as "var=''".
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Allow treating util/grub-module-verifierXX.c as a file you can build
directly so syntax checkers like vim's "syntastic" plugin, which uses
"gcc -x c -fsyntax-only" to build it, will work.
One still has to do whatever setup is required to make it pick the
right include dirs, which -I options we use, etc., but this makes
it so you can do the checking on the file you're editing, rather
than on a different file.
Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Robbie Harwood <rharwood@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Mon, 19 Sep 2022 14:30:30 +0000 (00:30 +1000)]
efi: Increase default memory allocation to 32 MiB
We have multiple reports of things being slower with a 1 MiB initial static
allocation, and a report (more difficult to nail down) of a boot failure
as a result of the smaller initial allocation.
Make the initial memory allocation 32 MiB.
Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Christian Hesse [Mon, 19 Sep 2022 13:31:28 +0000 (15:31 +0200)]
templates: Filter C.UTF-8 locale for translation
In addition to C locale there is also C.UTF-8 locale now. Filter that as
well, by using ${grub_lang}, which contains a stripped value.
This fixes the following message and resulting boot failure:
error: file `/boot/grub/locale/C.gmo' not found.
Signed-off-by: Christian Hesse <mail@eworm.de> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Steve McIntyre [Sun, 18 Sep 2022 22:12:02 +0000 (23:12 +0100)]
tests: Explicitly unset SOURCE_DATE_EPOCH before running fs tests
In some filesystem utils like mksquashfs, they will silently change
behaviour and cause timestamps to unexpectedly change. Build
environments like Debian's set SOURCE_DATE_EPOCH in the environment,
so remove it. Reproducible builds are good and useful for shipped
artifacts, but this causes build-time tests to fail.
Signed-off-by: Steve McIntyre <steve@einval.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
commands/efi/lsefisystab: Short text for EFI_CONFORMANCE_PROFILES_TABLE
The EFI_CONFORMANCE_PROFILES_TABLE_GUID is used for a table of GUIDs for conformance
profiles (cf. UEFI specification 2.10, 4.6.5 EFI_CONFORMANCE_PROFILE_TABLE).
The lsefisystab command is used to display installed EFI configuration tables.
Currently it only shows the GUID but not a short text for the table.
Provide a short text for the EFI_CONFORMANCE_PROFILES_TABLE_GUID.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Theodore Ts'o [Wed, 31 Aug 2022 02:41:59 +0000 (22:41 -0400)]
fs/ext2: Ignore the large_dir incompat feature
Recently, ext4 added the large_dir feature, which adds support for
a 3 level htree directory support.
The GRUB supports existing file systems with htree directories by
ignoring their existence, and since the index nodes for the hash tree
look like deleted directory entries (by design), the GRUB can simply do
a brute force O(n) linear search of directories. The same is true for
3 level deep htrees indicated by large_dir feature flag.
Hence, it is safe for the GRUB to ignore the large_dir incompat feature.
Fixes: https://savannah.gnu.org/bugs/?61606 Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Fri, 26 Aug 2022 04:08:57 +0000 (23:08 -0500)]
disk/loopback: Support transparent decompression of backing file
A new option is added to the loopback command, -D or --decompress, which
when specified transparently decompresses the backing file. This allows
compressed images to be used as if they were uncompressed.
Add documentation to support this change.
Suggested-by: Li Gen <ligenlive@gmail.com> Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Fri, 26 Aug 2022 03:52:26 +0000 (22:52 -0500)]
configure: Add -DGRUB_HAS_PCI when compiling C/C++ files on targets that support PCI
The list of targets that support PCI is in gentpl.py. However, there is no
support for generating makefile script from a .def file that will apply
globally to the makefile, but on a per target basis. So instead, use
gentpl.py in configure to get the list of targets and check if the current
build target is one of them. If it is, set the automake conditional
COND_HAVE_PCI. Then in conf/Makefile.common add -DGRUB_HAS_PCI for the
platform if COND_HAVE_PCI is true.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Li Gen [Fri, 26 Aug 2022 00:59:09 +0000 (19:59 -0500)]
commands/read: Fix overflow in grub_getline()
Store returned value from grub_getkey() in int instead of char to
prevent throwing away the extended bits. This was a problem because,
for instance, the left arrow key press would return
(GRUB_TERM_EXTENDED | 0x4b), which would have the GRUB_TERM_EXTENDED
thrown away leaving 0x4b or 'K'. These extended keys should either
work as intended or do nothing. This change has them do nothing,
instead of inserting a key not pressed by the user.
Signed-off-by: Li Gen <ligenlive@gmail.com> Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Li Gen [Thu, 25 Aug 2022 05:12:17 +0000 (00:12 -0500)]
efi: Correct function prototype for register_key_notify() method of grub_efi_simple_text_input_ex_interface
The register_key_notify() method should have an output parameter which is
a pointer to the unique handle assigned to the registered notification.
Signed-off-by: Li Gen <ligenlive@gmail.com> Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Masahiro Matsuya [Wed, 24 Aug 2022 17:36:37 +0000 (13:36 -0400)]
net/drivers/ieee1275/ofnet: Fix incorrect netmask
The netmask configured in firmware is not respected on ppc64 (big endian).
When 255.255.252.0 is set as netmask in firmware, the following is the
value of bootpath string in grub_ieee1275_parse_bootpath():
The netmask in this bootpath is not a problem, since it's a value specified
in firmware. But the value of subnet_mask.ipv4 was set with 0xfffffc00, and
__builtin_ctz(~grub_le_to_cpu32(subnet_mask.ipv4)) returned 16 (not 22).
As a result, 16 was used for netmask wrongly:
Ross Philipson [Wed, 24 Aug 2022 14:47:02 +0000 (10:47 -0400)]
loader/i386/bsd: Initialize BSD relocator state variables
Numerous register fields in the relocator state are simply not
used depending on the relocator. This causes Coverity to flag
these fields but there is no real bug here. Simply initializing
the variable to {0} solves the issue. Fixed in the else case too
for consistency.
Fixes: CID 396932 Signed-off-by: Ross Philipson <ross.philipson@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This is trivial, but it might save some time to beginners.
Signed-off-by: Andrea G. Monaco <andrea.monaco@autistici.org> Reviewed-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
commands/efi/efifwsetup: Print an error if boot to firmware setup is not supported
The "fwsetup" command is only registered if the firmware supports booting
to the firmware setup UI. But it could be possible that the GRUB config
already contains a "fwsetup" entry, because it was generated in a machine
that has support for this feature.
if it is not supported by the firmware, let's just always register the
command but print a more accurate message if the firmware doesn't
support this option.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Robbie Harwood <rharwood@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
templates: Check for EFI at runtime instead of config generation time
The 30_uefi-firmware template checks if an OsIndicationsSupported UEFI var
exists and EFI_OS_INDICATIONS_BOOT_TO_FW_UI bit is set, to decide whether
a "fwsetup" menu entry would be added or not to the GRUB menu.
But this has the problem that it will only work if the configuration file
was created on an UEFI machine that supports booting to a firmware UI.
This for example doesn't support creating GRUB config files when executing
on systems that support both UEFI and legacy BIOS booting. Since creating
the config file from legacy BIOS wouldn't allow to access the firmware UI.
To prevent this, make the template to unconditionally create the grub.cfg
snippet but check at runtime if was booted through UEFI to decide if this
entry should be added. That way it won't be added when booting with BIOS.
There's no need to check if EFI_OS_INDICATIONS_BOOT_TO_FW_UI bit is set,
since that's already done by the "fwsetup" command when is executed.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Robbie Harwood <rharwood@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
disk/luks2: Fix decoding of digests and salts with escaped chars
It was reported in the #grub IRC channel on Libera that decryption of
LUKS2 partitions fails with errors about invalid digests and/or salts.
In all of these cases, what failed was decoding the Base64
representation of these, where the encoded data contained invalid
characters.
As it turns out, the root cause is that json-c, which is used by
cryptsetup to read and write the JSON header, will escape some
characters by prepending a backslash when writing JSON strings by
default. Most importantly, json-c also escapes the forward slash, which
is part of the Base64 alphabet. Because GRUB doesn't know to unescape
such characters, decoding this string will rightfully fail.
Interestingly, this issue has until now only been reported by users of
Ubuntu 18.04. And a bit of digging in fact reveals that cryptsetup has
changed the logic in a054206d (Suppress useless slash escaping in json
lib, 2018-04-20), which has been released with cryptsetup v2.0.3. Ubuntu
18.04 is still shipping with cryptsetup v2.0.2 though, which explains
why this is not a more frequent issue.
Fix the issue by using our new grub_json_unescape() helper function
that handles unescaping for us.
Reported-by: Afdal Signed-off-by: Patrick Steinhardt <ps@pks.im> Reviewed-by: Daniel Kiper <dkiper@net-space.pl>
lib/json/json: Add function to unescape JSON-encoded strings
JSON strings require certain characters to be encoded, either by using
a single reverse solidus character "\" for a set of popular characters,
or by using a Unicode representation of "\uXXXXX". The jsmn library
doesn't handle unescaping for us, so we must implement this functionality
for ourselves.
Add a new function grub_json_unescape() that takes a potentially
escaped JSON string as input and returns a new unescaped string.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Reviewed-by: Daniel Kiper <dkiper@net-space.pl>
Nikita Ermakov [Thu, 18 Aug 2022 14:51:28 +0000 (16:51 +0200)]
loader: Drop argv[] argument in grub_initrd_load()
In the case of an error grub_initrd_load() uses argv[] to print the
filename that caused the error. It is also possible to obtain the
filename from the file handles and there is no need to duplicate that
information in argv[], so let's drop it.
Alec Brown [Fri, 12 Aug 2022 22:25:49 +0000 (18:25 -0400)]
loader: Update error conditionals to use enums
In grub-core/loader/i386/bsdXX.c and grub-core/loader/multiboot_elfxx.c, error
conditionals are simplified to statements such as "if (err)". Even though the
assumption that non-zero values give errors is correct, it would be clearer and
more consistent to compare these conditionals to GRUB_ERR_NONE.
Signed-off-by: Alec Brown <alec.r.brown@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Alec Brown [Fri, 12 Aug 2022 22:25:48 +0000 (18:25 -0400)]
util/grub-module-verifierXX: Changed get_shnum() return type
In util/grub-module-verifierXX.c, the function get_shnum() returns the variable
shnum, which is of the type Elf_Word. In the function, shnum can be obtained by
the e_shnum member of an Elf_Ehdr or the sh_size member of an Elf_Shdr. The
sh_size member can either be grub_uint32_t or grub_uint64_t, depending on the
architecture, but Elf_Word is only grub_uint32_t. To account for when sh_size is
grub_uint64_t, we can set shnum to have type Elf_Shnum and have get_shnum()
return an Elf_Shnum.
Signed-off-by: Alec Brown <alec.r.brown@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Alec Brown [Fri, 12 Aug 2022 22:25:47 +0000 (18:25 -0400)]
elf: Validate number of elf program header table entries
In bsdXX.c and multiboot_elfxx.c, e_phnum is used to obtain the number of
program header table entries, but it wasn't being checked if the value was
there.
According to the elf(5) manual page,
"If the number of entries in the program header table is larger than or equal to
PN_XNUM (0xffff), this member holds PN_XNUM (0xffff) and the real number of
entries in the program header table is held in the sh_info member of the
initial entry in section header table. Otherwise, the sh_info member of the
initial entry contains the value zero."
Since this check wasn't being made, grub_elfXX_get_phnum() is being added to
elfXX.c to make this check and use e_phnum if it doesn't have PN_XNUM as a
value, else use sh_info. We also need to make sure e_phnum isn't greater than
PN_XNUM and sh_info isn't less than PN_XNUM.
Note that even though elf.c and elfXX.c are located in grub-core/kern, they are
compiled as modules and don't need the EXPORT_FUNC() macro to define the functions
in elf.h.
Also, changed casts of phnum to match variables being set as well as dropped
casts when unnecessary.
Signed-off-by: Alec Brown <alec.r.brown@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Alec Brown [Fri, 12 Aug 2022 22:25:46 +0000 (18:25 -0400)]
elf: Validate elf section header table index for section name string table
In multiboot_elfxx.c, e_shstrndx is used to obtain the section header table
index of the section name string table, but it wasn't being checked if the value
was there.
According to the elf(5) manual page,
"If the index of section name string table section is larger than or equal to
SHN_LORESERVE (0xff00), this member holds SHN_XINDEX (0xffff) and the real
index of the section name string table section is held in the sh_link member of
the initial entry in section header table. Otherwise, the sh_link member of the
initial entry in section header table contains the value zero."
Since this check wasn't being made, grub_elfXX_get_shstrndx() is being added to
elfXX.c to make this check and use e_shstrndx if it doesn't have SHN_XINDEX as a
value, else use sh_link. We also need to make sure e_shstrndx isn't greater than
or equal to SHN_LORESERVE and sh_link isn't less than SHN_LORESERVE.
Note that even though elf.c and elfXX.c are located in grub-core/kern, they are
compiled as modules and don't need the EXPORT_FUNC() macro to define the functions
in elf.h.
Signed-off-by: Alec Brown <alec.r.brown@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Alec Brown [Fri, 12 Aug 2022 22:25:45 +0000 (18:25 -0400)]
elf: Validate number of elf section header table entries
In bsdXX.c and multiboot_elfxx.c, e_shnum is used to obtain the number of
section header table entries, but it wasn't being checked if the value was
there.
According to the elf(5) manual page,
"If the number of entries in the section header table is larger than or equal to
SHN_LORESERVE (0xff00), e_shnum holds the value zero and the real number of
entries in the section header table is held in the sh_size member of the initial
entry in section header table. Otherwise, the sh_size member of the initial
entry in the section header table holds the value zero."
Since this check wasn't being made, grub_elfXX_get_shnum() is being added to
elfXX.c to make this check and use whichever member doesn't have a value of
zero. If both are zero, then we must return an error. We also need to make sure
that e_shnum doesn't have a value greater than or equal to SHN_LORESERVE and
sh_size isn't less than SHN_LORESERVE.
In order to get this function to work, the type ElfXX_Shnum is being added where
Elf32_Shnum defines Elf32_Word and Elf64_Shnum defines Elf64_Xword. This new
type is needed because if shnum obtains a value from sh_size, sh_size could be
of type El32_Word for Elf32_Shdr structures or Elf64_Xword for Elf64_Shdr
structures.
Note that even though elf.c and elfXX.c are located in grub-core/kern, they are
compiled as modules and don't need the EXPORT_FUNC() macro to define the functions
in elf.h.
For a few smaller changes, changed casts of shnum to match variables being set
as well as dropped casts when unnecessary and fixed spacing errors in bsdXX.c.
Also, shnum is an unsigned integer and is compared to int i in multiboot_elfxx.c,
it should be unsigned to match shnum.
Signed-off-by: Alec Brown <alec.r.brown@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
templates/linux_xen: Properly order the multiple initrd files
The linux_xen template orders the "early" initrd file(s) _first_
(i.e., before the "real" initrd files) and that seems reasonable,
as microcode updates usually come first.
However, this usually breaks Linux boot with initrd under Xen
because Xen assumes the real initrd is the first multiboot[2]
module after the kernel, passing its address over to Linux in
Xen's start_info struct.
So, if a microcode-only initrd (i.e., without init/userspace)
is found by grub-mkconfig, it ends up considered as a normal
initrd by the Linux kernel, which cannot do anything with it
(as it has no other files) and panic()s unable to mount root
if it depends on a initrd to do that (e.g., root=UUID=...).
...
Well, since Xen doesn't actually use the provided microcode
by default / unless the 'ucode=<module number|scan>' option
is enabled, this isn't used in the general case (and breaks).
Additionally, if an user enables the 'ucode=' option, that
either specifies which module is to be used for microcode,
or scans all modules (regardless of being first) for that.
Thus, for Xen:
- it is *not required* to have microcode first,
- but it is *required* to have real initrd first
So, fix it by ordering the real initrd before early initrd(s).
Corner case specific to Xen implementation details:
It is actually _possible_ to have a microcode initrd first,
but that requires a non-default option (so can't rely on it),
and it turns out to be inconsistent with its counterpart
(really shouldn't rely on it, as it may get confusing; below).
'ucode=1' does manually specify the first module is microcode
_AND_ clears its bit in the module bitmap. The next module is
now the 'new first', and gets passed to Linux as initrd. Good.
'ucode=scan' checks all modules for microcode, but does _NOT_
clear a bit if it finds one (reasonable, as it can find that
prepended in a "real" initrd anyway, which needs to be used).
The first module still gets passed to Linux as initrd. Bad.
Fixes: e86f6aafb8de (grub-mkconfig/20_linux_xen: Support multiple early initrd images) Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com> Acked-by: Juergen Gross <jgross@suse.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The linux_xen template can put multiple initrd files in the
same multiboot[2] module[2] command, which is against specs.
This causes ONLY the _first_ initrd file to be loaded; other
files just have filenames in a "cmdline" string of the first
initrd file and are NOT loaded.
Fix this by inserting a module[2] command per initrd file.
The code was copied from the linux template, which is *apparently*
equivalent.. but its initrd command grub_cmd_initrd() *supports*
multiple files (see grub_initrd_init()), while module/module2 in
grub_cmd_module() *does not* (see grub_multiboot[2]_add_module()).
See commit e86f6aafb8de (grub-mkconfig/20_linux_xen: Support multiple early initrd images):
'This is basically a copy of a698240d "grub-mkconfig/10_linux:
Support multiple early initrd images" ...'
Specs:
Both multiboot and multiboot2 specifications mention support for
'multiple boot modules' (struct/tag used for kernel/initrd files):
"Boot loaders don’t have to support multiple boot modules,
but they are strongly encouraged to" [1,2]
However, there is a 1:1 relationship between boot modules and files,
more or less clearly; note the usage of singular/plural "module(s)".
(Multiboot2, clearly: "One tag appears per module".)
Multiboot [1]:
"the ‘mods’ fields indicate ... what boot modules
were loaded ..., and where they can be found.
‘mods_count’ contains the number of modules loaded"
"The first two fields contain the start and end addresses
of the boot module itself."
Multiboot2 [2]:
"This tag indicates ... what boot module was loaded ...,
and where it can be found."
"The ‘mod_start’ and ‘mod_end’ contain the start and end
physical addresses of the boot module itself."
"One tag appears per module.
This tag type may appear multiple times."
And both clearly mention the 'string' field of a boot module,
which is to be used by the operating system, not boot loader:
"The ‘string’ field provides an arbitrary string to be
associated with that particular boot module ...
its exact use is specific to the operating system."
Links:
[1] https://www.gnu.org/software/grub/manual/multiboot/multiboot.html
3.3 Boot information format
Glenn Washburn [Thu, 11 Aug 2022 17:48:42 +0000 (12:48 -0500)]
misc: Add cast in grub_strncasecmp() to drop sign when calling grub_tolower()
Note this cast was fixed in grub_strcasecmp() in commit ce41ab7aab
(* grub-core/kern/misc.c (grub_strcmp): Use unsigned comparison as per
common usage and preffered in several parts of code.), but this commit
omitted fixing it in grub_strncasecmp().
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Thu, 11 Aug 2022 17:06:43 +0000 (12:06 -0500)]
tests/util/grub-shell: Only show grub-mkrescue output if it returns an error
The previous behavior ignored an error and the output from grub-mkrescue.
This made it difficult to discover that grub-mkrescue was the reason that
tests which rely on grub-shell were failing. Even after discovering
grub-mkrescue was the culprit, there was no output to indicate why it was
failing. It turns out that grub-mkrescue is a thin wrapper around xorriso.
So if you do not have xorriso installed it will fail with an error message
about not being able to find xorriso.
This change will allow grub-mkrescue output to be written to stderr, only
if grub-mkrescue fails. If grub-mkrescue succeeds, there will be no output
from grub-mkrescue so as not to interfere with the functioning of tests.
This change should have no effect on the running of tests or other uses of
grub-shell as it only modifies the error path.
Also, if grub-mkrescue fails, the script exits early. Since grub-shell
needs the ISO image created by grub-mkresue to boot the QEMU instance,
a failure here should be considered fatal.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Ard Biesheuvel [Thu, 11 Aug 2022 14:51:57 +0000 (16:51 +0200)]
loader/arm64/linux: Remove magic number header field check
The "ARM\x64" magic number in the file header identifies an image as one
that implements the bare metal boot protocol, allowing the loader to
simply move the file to a suitably aligned address in memory, with
sufficient headroom for the trailing .bss segment (the required memory
size is described in the header as well).
Note of this matters for GRUB, as it only supports EFI boot. EFI does
not care about this magic number, and nor should GRUB: this prevents us
from booting other PE linux images, such as the generic EFI zboot
decompressor, which is a pure PE/COFF image, and does not implement the
bare metal boot protocol.
So drop the magic number check.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Darren Kenny [Tue, 9 Aug 2022 13:29:05 +0000 (13:29 +0000)]
util/grub-install-common: Confirm directory creation in grub_install_mkdir_p()
Because grub_util_mkdir() is implemented to not return a value on any
platform, grub_instal_mkdir_p() can test for success by confirming that
the directory requested exists after attempting to create it, otherwise
it should fail with an error and exit.
While fixing this, a flaw in the logic was shown, where the first match
of the path separator, which almost always was the first character in
the path (e.g. /boot/grub2) would result in creating a directory with an
empty name (i.e. ""). To avoid that, it should skip the handling of the
path separator where p is pointing to the first character.
Signed-off-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Darren Kenny [Tue, 9 Aug 2022 13:29:04 +0000 (13:29 +0000)]
util: Ignore return value for grub_util_mkdir() on all platforms
Coverity signaled 2 issues where the return value of grub_util_mkdir()
was not being tested.
The Windows variant of this code defines the function as having no
return value (void), but the UNIX variants all are mapped using a macro
to the libc mkdir() function, which returns an int value.
To be consistent, the mapping should cast to void to for these too.
Fixes: CID 73583 Fixes: CID 73617 Signed-off-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Sun, 7 Aug 2022 05:18:52 +0000 (00:18 -0500)]
disk/cryptodisk: Support encrypted volumes using detached headers on a partition
Update the read hook to take into account encrypted volumes on a partition.
GRUB disk read hooks supply an absolute sector number at which the read is
started from. If the encrypted volume is in a partition, the sector number
given to the read hook will be offset by the number of the sector at the
start of the partition. The read hook then needs to subtract the partition
start from the supplied sector to get the correct start sector for the read
into the detached header file.
Glenn Washburn [Sat, 6 Aug 2022 06:26:31 +0000 (01:26 -0500)]
tests/util/grub-shell: Use shell variable instead of autoconf
By using shell variable that are set once by the expansion of an autoconf
variable, the resulting shell script is more easily moved and modified
from the build/install directory it was generated for. The resulting
script is more readable as well.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Peter Jones [Thu, 28 Jul 2022 18:34:16 +0000 (14:34 -0400)]
kern/i386/tsc_pmtimer: Make pmtimer tsc calibration not take 51 seconds to fail
On my laptop running at 2.4GHz, if I run a VM where tsc calibration
using pmtimer will fail presuming a broken pmtimer, it takes ~51 seconds
to do so (as measured with the stopwatch on my phone), with a tsc delta
of 0x1cd1c85300, or around 125 billion cycles.
If instead of trying to wait for 5-200ms to show up on the pmtimer, we
try to wait for 5-200us, it decides it's broken in ~0x2626aa0 TSCs, aka
~2.4 million cycles, or more or less instantly.
Additionally, this reading the pmtimer was returning 0xffffffff anyway,
and that's obviously an invalid return. I've added a check for that and
0 so we don't bother waiting for the test if what we're seeing is dead
pins with no response at all.
If "debug" includes "pmtimer", you will see one of the following three
outcomes. If pmtimer gives all 0 or all 1 bits, you will see:
This outcome was tested using qemu+kvm with UEFI (OVMF) firmware and
these options: -machine pc-q35-2.10 -cpu Broadwell-noTSX
If pmtimer gives any other bit patterns but is not actually marching
forward fast enough to use for clock calibration, you will see:
pmtimer delta is 0x0 (1904 iterations)
tsc delta is implausible: 0x2626aa0
This outcome was tested using GRUB patched to not ignore bad reads using
qemu+kvm with UEFI (OVMF) firmware, and these options:
-machine pc-q35-2.10 -cpu Broadwell-noTSX
If pmtimer actually works, you'll see something like:
pmtimer delta is 0xdff
tsc delta is 0x278756
This outcome was tested using qemu+kvm with UEFI (OVMF) firmware, and
these options: -machine pc-i440fx-2.4 -cpu Broadwell-noTSX
I've also tested this outcome on a real Intel Xeon E3-1275v3 on an Intel
Server Board S1200V3RPS using the SDV.RP.B8 "Release" build here:
https://www.intel.com/content/www/us/en/download/674448/firmware-update-for-the-intel-server-board-s1200rp-uefi-development-kit-release-vb8.html
Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Robbie Harwood <rharwood@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
disk/luks2: Continue trying all keyslots even if there are some failures
luks2_get_keyslot() can fail for a variety of reasons that do not necessarily
mean the next keyslot should not be tried (e.g. a new kdf type). So always
try the next slot. This will make GRUB more resilient to non-spec json data
that 3rd party systems may add. We do not care if some of the keyslots are
unusable, only if there is at least one that is.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
efi: Add efitextmode command for getting/setting the text mode resolution
This command is meant to behave similarly to the "mode" command of the EFI
Shell application. In addition to allowing mode selection by giving the
number of columns and rows as arguments, the command allows specifying the
mode number to select the mode. Also supported are the arguments "min" and
"max", which set the mode to the minimum and maximum mode respectively as
calculated by the columns * rows of that mode.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This causes grub-probe failure, which in turn causes grub-mkconfig
failure. They are valid filesystems that appear intact, and the Linux
FAT stack is able to mount and manipulate them without complaint.
repeated for each filesystem. Any messages provided to grub_error() by
the filesystem are lost, and one has to break out gdb to figure out what
went wrong.
With this change, one instead sees:
grub-core/kern/fs.c:56:fs: Detecting fat...
grub-core/osdep/hostdisk.c:357:hostdisk: reusing open device
`/path/to/device'
grub-core/kern/fs.c:77:fs: error: invalid modification timestamp for /.
grub-core/kern/fs.c:79:fs: fat detection failed.
in the debug prints.
Signed-off-by: Robbie Harwood <rharwood@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Ross Philipson [Thu, 14 Jul 2022 13:41:28 +0000 (09:41 -0400)]
lib/relocator: Initialize local relocator subchunk struct to all zeros
The way the code is written the tofree variable would never be passed to
the free_subchunk() function uninitialized. Coverity cannot determine
this and flags the situation as "Using uninitialized value...". The fix
is just to initialize the local struct.
Fixes: CID 314016 Signed-off-by: Ross Philipson <ross.philipson@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Tested-by: Alec Brown <alec.r.brown@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Lu Ken [Wed, 13 Jul 2022 02:06:12 +0000 (10:06 +0800)]
efi/tpm: Add EFI_CC_MEASUREMENT_PROTOCOL support
The EFI_CC_MEASUREMENT_PROTOCOL abstracts the measurement for virtual firmware
in confidential computing environment. It is similar to the EFI_TCG2_PROTOCOL.
It was proposed by Intel and ARM and approved by UEFI organization.
It is defined in Intel GHCI specification: https://cdrdv2.intel.com/v1/dl/getContent/726790 .
The EDKII header file is available at https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/CcMeasurement.h .
Signed-off-by: Lu Ken <ken.lu@intel.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Nicholas Vinson [Thu, 7 Jul 2022 23:52:47 +0000 (19:52 -0400)]
configure: Warn if stack protector is not allowed
Introduce ERROR_PLATFORM_NOT_SUPPORT_SSP environment variable to treat
the "--enable-stack-protector is only supported on EFI platforms" message
as a warning instead of an error. If ERROR_PLATFORM_NOT_SUPPORT_SSP is
set to "no" (case-insensitive), then the message will be printed as
a warning. Otherwise, it prints as an error. The default behavior is to
print the message as an error.
For any wrapper build script that has some variation of:
for p in SELECTED_GRUB_PLATFORMS; do \
configure --enable-stack-protector \
--with-platform${P} ... || die; \
done
make
The GRUB will fail to build if SELECTED_GRUB_PLATFORMS contains a platform
that does not support SSP.
Such wrapper scripts need to work-around this issue by modifying the
above for-loop, so it conditionally passes --enable-stack-protector to
configure for the proper GRUB platform(s).
However, if the above example is modified to have to conditionally pass
in --enable-stack-protector, its behavior is effectively the same as the
proposed change. Additionally, The list of SSP supported platforms is
now in 2 places. One in the configure script and one in the build wrapper
script. If the second list is not properly maintained it could mistakenly
disable SSP for a platform that later gained support for it.
Signed-off-by: Nicholas Vinson <nvinson234@gmail.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Darren Kenny [Thu, 7 Jul 2022 15:34:38 +0000 (15:34 +0000)]
util/grub-mkfont: Fix tainted loop boundary issues with substitutions
With gsub substitutions the offsets should be validated against the
number of glyphs in a font face and the memory allocated for the gsub
substitution data.
Both the number of glyphs and the last address in the allocated data are
passed in to process_cursive(), where the number of glyphs validates the end
of the range.
Enabling memory allocation validation uses two macros, one to simply check the
address against the allocated space, and the other to check that the number of
items of a given size doesn't extend outside of the allocated space.
Fixes: CID 73770 Fixes: CID 314040 Signed-off-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
templates: Remove unused version comparison functions
There are no users left of version_find_latest(), version_test_gt(), and
version_test_numeric(). Remove those unused helper functions. Using
those helper functions is what caused the quadratic sorting performance
issues in the first place, so removing them is a net win.
templates/kfreebsd: Fix quadratic algorithm for sorting menu items
The current implementation of the 10_kfreebsd script implements its menu
items sorting in bash with a quadratic algorithm, calling "sed", "sort",
"head", and "grep" to compare versions between individual lines, which
is annoyingly slow for kernel developers who can easily end up with
50-100 kernels in their boot partition.
This fix is ported from the 10_linux script, which has a similar
quadratic code pattern.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: debian-bsd@lists.debian.org Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
templates/hurd: Fix quadratic algorithm for sorting menu items
The current implementation of the 10_hurd script implements its menu
items sorting in bash with a quadratic algorithm, calling "sed", "sort",
"head", and "grep" to compare versions between individual lines, which
is annoyingly slow for kernel developers who can easily end up with
50-100 kernels in their boot partition.
This fix is ported from the 10_linux script, which has a similar
quadratic code pattern.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Samuel Thibault <samuel.thibault@ens-lyon.org> Tested-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
templates/linux_xen: Fix quadratic algorithm for sorting menu items
The current implementation of the 20_linux_xen script implements its
menu items sorting in bash with a quadratic algorithm, calling "sed",
"sort", "head", and "grep" to compare versions between individual lines,
which is annoyingly slow for kernel developers who can easily end up
with 50-100 kernels in their boot partition.
This fix is ported from the 10_linux script, which has a similar
quadratic code pattern.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: xen-devel@lists.xenproject.org Tested-by: Jason Andryuk <jandryuk@gmail.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
templates/linux: Fix quadratic algorithm for sorting menu items
The current implementation of the 10_linux script implements its menu
items sorting in bash with a quadratic algorithm, calling "sed", "sort",
"head", and "grep" to compare versions between individual lines, which
is annoyingly slow for kernel developers who can easily end up with
50-100 kernels in /boot.
As an example, on a Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz, running:
/usr/sbin/grub-mkconfig > /dev/null
With 44 kernels in /boot, this command takes 10-15 seconds to complete.
After this fix, the same command runs in 5 seconds.
With 116 kernels in /boot, this command takes 40 seconds to complete.
After this fix, the same command runs in 8 seconds.
For reference, the quadratic algorithm here is:
while [ "x$list" != "x" ] ; do <--- outer loop
linux=`version_find_latest $list`
version_find_latest()
for i in "$@" ; do <--- inner loop
version_test_gt()
fork+exec sed
version_test_numeric()
version_sort
fork+exec sort
fork+exec head -n 1
fork+exec grep
list=`echo $list | tr ' ' '\n' | fgrep -vx "$linux" | tr '\n' ' '`
tr
fgrep
tr
So all commands executed under version_test_gt() are executed
O(n^2) times where n is the number of kernel images in /boot.
Here is the improved algorithm proposed:
- Prepare a list with all the relevant information for ordering by a single
sort(1) execution. This is done by renaming ".old" suffixes by " 1" and
by suffixing all other files with " 2", thus making sure the ".old" entries
will follow the non-old entries in reverse-sorted-order.
- Call version_reverse_sort on the list (sort -r -V): A single execution of
sort(1). For instance, GNU coreutils' sort will reverse-sort the list in
O(n*log(n)) with a merge sort.
- Replace the " 1" suffixes by ".old", and remove the " 2" suffixes.
- Iterate on the reverse-sorted list to output each menu entry item.
Therefore, the algorithm proposed has O(n*log(n)) complexity with GNU
coreutils' sort compared to the prior O(n^2) complexity. Moreover, the
constant time required for each list entry is much less because sorting
is done within a single execution of sort(1) rather than requiring
O(n^2) executions of sed(1), sort(1), head(1), and grep(1) in
sub-shells.
Glenn Washburn [Wed, 8 Jun 2022 15:34:03 +0000 (10:34 -0500)]
cryptodisk: Add support for using detached header files
Using the disk read hook mechanism, setup a read hook on the source disk
which will read from the given header file during the scan and recovery
cryptodisk backend functions. Disk read hooks are executed after the data
has been read from the disk. This is okay, because the read hook is given
the read buffer before its sent back to the caller. In this case, the hook
can then overwrite the data read from the disk device with data from the
header file sent in as the read hook data. This is transparent to the
read caller. Since the callers of this function have just opened the
source disk, there are no current read hooks, so there's no need to
save/restore them nor consider if they should be called or not.
This hook assumes that the header is at the start of the volume, which
is not the case for some formats (e.g. GELI). So GELI will return an
error if a detached header is specified. It also can only be used
with formats where the detached header file can be written to the
first blocks of the volume and the volume could still be unlocked.
So the header file can not be formatted differently from the on-disk
header. If these assumpts are not met, detached header file processing
must be specially handled in the cryptodisk backend module.
The hook will be called potentially many times by a backend. This is fine
because of the assumptions mentioned and the read hook reads from absolute
offsets and is stateless.
Also add a --header (short -H) option to cryptomount which takes a file
argument.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Patrick Steinhardt <ps@pks.im> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Wed, 8 Jun 2022 15:34:02 +0000 (10:34 -0500)]
disk: Allow read hook callback to take read buffer to potentially modify it
It will be desirable in the future to allow having the read hook modify the
data passed back from a read function call on a disk or file. This adds that
infrastructure and has no impact on code flow for existing uses of the read
hook. Also changed is that now when the read hook callback is called it can
also indicate what error code should be sent back to the read caller.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Patrick Steinhardt <ps@pks.im> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Adjust the interface of grub_efi_mm_add_regions() to take a set of
GRUB_MM_ADD_REGION_* flags, which most notably is currently only the
GRUB_MM_ADD_REGION_CONSECUTIVE flag. This allows us to set the function
up as callback for the memory subsystem and have it call out to us in
case there's not enough pages available in the current heap.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Tested-by: Patrick Steinhardt <ps@pks.im>
kern/efi/mm: Pass up errors from add_memory_regions()
The function add_memory_regions() is currently only called on system
initialization to allocate a fixed amount of pages. As such, it didn't
need to return any errors: in case it failed, we cannot proceed anyway.
This will change with the upcoming support for requesting more memory
from the firmware at runtime, where it doesn't make sense anymore to
fail hard.
Refactor the function to return an error to prepare for this. Note that
this does not change the behaviour when initializing the memory system
because grub_efi_mm_init() knows to call grub_fatal() in case
grub_efi_mm_add_regions() returns an error.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Tested-by: Patrick Steinhardt <ps@pks.im>
kern/efi/mm: Extract function to add memory regions
In preparation of support for runtime-allocating additional memory
region, this patch extracts the function to retrieve the EFI memory
map and add a subset of it to GRUB's own memory regions.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Tested-by: Patrick Steinhardt <ps@pks.im>
kern/efi/mm: Always request a fixed number of pages on init
When initializing the EFI memory subsystem, we will by default request
a quarter of the available memory, bounded by a minimum/maximum value.
Given that we're about to extend the EFI memory system to dynamically
request additional pages from the firmware as required, this scaling of
requested memory based on available memory will not make a lot of sense
anymore.
Remove this logic as a preparatory patch such that we'll instead defer
to the runtime memory allocator. Note that ideally, we'd want to change
this after dynamic requesting of pages has been implemented for the EFI
platform. But because we'll need to split up initialization of the
memory subsystem and the request of pages from the firmware, we'd have
to duplicate quite some logic at first only to remove it afterwards
again. This seems quite pointless, so we instead have patches slightly
out of order.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Tested-by: Patrick Steinhardt <ps@pks.im>
mm: Allow dynamically requesting additional memory regions
Currently, all platforms will set up their heap on initialization of the
platform code. While this works mostly fine, it poses some limitations
on memory management on us. Most notably, allocating big chunks of
memory in the gigabyte range would require us to pre-request this many
bytes from the firmware and add it to the heap from the beginning on
some platforms like EFI. As this isn't needed for most configurations,
it is inefficient and may even negatively impact some usecases when,
e.g., chainloading. Nonetheless, allocating big chunks of memory is
required sometimes, where one example is the upcoming support for the
Argon2 key derival function in LUKS2.
In order to avoid pre-allocating big chunks of memory, this commit
implements a runtime mechanism to add more pages to the system. When
a given allocation cannot be currently satisfied, we'll call a given
callback set up by the platform's own memory management subsystem,
asking it to add a memory area with at least "n" bytes. If this
succeeds, we retry searching for a valid memory region, which should
now succeed.
If this fails, we try asking for "n" bytes, possibly spread across
multiple regions, in hopes that region merging means that we end up
with enough memory for things to work out.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Daniel Axtens <dja@axtens.net> Tested-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Tested-by: Patrick Steinhardt <ps@pks.im>
In grub_memalign(), there's a commented section which would allow for
unloading of unneeded modules in case where there is not enough free
memory available to satisfy a request. Given that this code is never
compiled in, let's remove it together with grub_dl_unload_unneeded().
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Tested-by: Patrick Steinhardt <ps@pks.im>
Daniel Axtens [Thu, 21 Apr 2022 05:24:15 +0000 (15:24 +1000)]
mm: When adding a region, merge with region after as well as before
On x86_64-efi (at least) regions seem to be added from top down. The mm
code will merge a new region with an existing region that comes
immediately before the new region. This allows larger allocations to be
satisfied that would otherwise be the case.
On powerpc-ieee1275, however, regions are added from bottom up. So if
we add 3x 32MB regions, we can still only satisfy a 32MB allocation,
rather than the 96MB allocation we might otherwise be able to satisfy.
* Define 'post_size' as being bytes lost to the end of an allocation
due to being given weird sizes from firmware that are not multiples
of GRUB_MM_ALIGN.
* Allow merging of regions immediately _after_ existing regions, not
just before. As with the other approach, we create an allocated
block to represent the new space and the pass it to grub_free() to
get the metadata right.
Signed-off-by: Daniel Axtens <dja@axtens.net> Tested-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Tested-by: Patrick Steinhardt <ps@pks.im>
Daniel Axtens [Thu, 21 Apr 2022 05:24:14 +0000 (15:24 +1000)]
mm: Assert that we preserve header vs region alignment
grub_mm_region_init() does:
h = (grub_mm_header_t) (r + 1);
where h is a grub_mm_header_t and r is a grub_mm_region_t.
Cells are supposed to be GRUB_MM_ALIGN aligned, but while grub_mm_dump
ensures this vs the region header, grub_mm_region_init() does not.
It's better to be explicit than implicit here: rather than changing
grub_mm_region_init() to ALIGN_UP(), require that the struct is
explicitly a multiple of the header size.
Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Tested-by: Patrick Steinhardt <ps@pks.im>
Darren Kenny [Thu, 7 Apr 2022 15:18:12 +0000 (15:18 +0000)]
fs/btrfs: Fix more fuzz issues related to chunks
The corpus was generating issues in grub_btrfs_read_logical() when
attempting to iterate over stripe entries in the superblock's
bootmapping.
In most cases the reason for the failure was that the number of stripes
in chunk->nstripes exceeded the possible space statically allocated in
superblock bootmapping space. Each stripe entry in the bootmapping block
consists of a grub_btrfs_key followed by a grub_btrfs_chunk_stripe.
Another issue that came up was that while calculating the chunk size,
in an earlier piece of code in that function, depending on the data
provided in the btrfs file system, it would end up calculating a size
that was too small to contain even 1 grub_btrfs_chunk_item, which is
obviously invalid too.
Signed-off-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Darren Kenny [Tue, 29 Mar 2022 15:52:46 +0000 (15:52 +0000)]
fs/btrfs: Fix more ASAN and SEGV issues found with fuzzing
The fuzzer is generating btrfs file systems that have chunks with
invalid combinations of stripes and substripes for the given RAID
configurations.
After examining the Linux kernel fs/btrfs/tree-checker.c code, it
appears that sub-stripes should only be applied to RAID10, and in that
case there should only ever be 2 of them.
Similarly, RAID single should only have 1 stripe, and RAID1/1C3/1C4
should have 2. 3 or 4 stripes respectively, which is what redundancy
corresponds.
Some of the chunks ended up with a size of 0, which grub_malloc() still
returned memory for and in turn generated ASAN errors later when
accessed.
While it would be possible to specifically limit the number of stripes,
a more correct test was on the combination of the chunk item, and the
number of stripes by the size of the chunk stripe structure in
comparison to the size of the chunk itself.
Signed-off-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Darren Kenny [Tue, 29 Mar 2022 10:49:56 +0000 (10:49 +0000)]
fs/btrfs: Fix several fuzz issues with invalid dir item sizing
According to the btrfs code in Linux, the structure of a directory item
leaf should be of the form:
|struct btrfs_dir_item|name|data|
in GRUB the name len and data len are in the grub_btrfs_dir_item
structure's n and m fields respectively.
The combined size of the structure, name and data should be less than
the allocated memory, a difference to the Linux kernel's struct
btrfs_dir_item is that the grub_btrfs_dir_item has an extra field for
where the name is stored, so we adjust for that too.
Signed-off-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
A corrupt f2fs file system might specify a name length which is greater
than the maximum name length supported by the GRUB f2fs driver.
We will allocate enough memory to store the overly long name, but there
are only F2FS_NAME_LEN bytes in the source, so we would read past the end
of the source.
While checking directory entries, do not copy a file name with an invalid
length.
Signed-off-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com> Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
A corrupt f2fs filesystem could have a block offset or a bitmap
offset that would cause us to read beyond the bounds of the nat
bitmap.
Introduce the nat_bitmap_size member in grub_f2fs_data which holds
the size of nat bitmap.
Set the size when loading the nat bitmap in nat_bitmap_ptr(), and
catch when an invalid offset would create a pointer past the end of
the allocated space.
Check against the bitmap size in grub_f2fs_test_bit() test bit to avoid
reading past the end of the nat bitmap.
Signed-off-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com> Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Tue, 8 Mar 2022 08:04:40 +0000 (19:04 +1100)]
net/http: Error out on headers with LF without CR
In a similar vein to the previous patch, parse_line() would write
a NUL byte past the end of the buffer if there was an HTTP header
with a LF rather than a CRLF.
RFC-2616 says:
Many HTTP/1.1 header field values consist of words separated by LWS
or special characters. These special characters MUST be in a quoted
string to be used within a parameter value (as defined in section 3.6).
We don't support quoted sections or continuation lines, etc.
If we see an LF that's not part of a CRLF, bail out.
Fixes: CVE-2022-28734 Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Tue, 8 Mar 2022 07:17:03 +0000 (18:17 +1100)]
net/http: Fix OOB write for split http headers
GRUB has special code for handling an http header that is split
across two packets.
The code tracks the end of line by looking for a "\n" byte. The
code for split headers has always advanced the pointer just past the
end of the line, whereas the code that handles unsplit headers does
not advance the pointer. This extra advance causes the length to be
one greater, which breaks an assumption in parse_line(), leading to
it writing a NUL byte one byte past the end of the buffer where we
reconstruct the line from the two packets.
It's conceivable that an attacker controlled set of packets could
cause this to zero out the first byte of the "next" pointer of the
grub_mm_region structure following the current_line buffer.
Do not advance the pointer in the split header case.
Fixes: CVE-2022-28734 Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Tue, 1 Mar 2022 12:14:15 +0000 (23:14 +1100)]
net/http: Do not tear down socket if it's already been torn down
It's possible for data->sock to get torn down in tcp error handling.
If we unconditionally tear it down again we will end up doing writes
to an offset of the NULL pointer when we go to tear it down again.
Detect if it has been torn down and don't do it again.
Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Tue, 18 Jan 2022 03:29:20 +0000 (14:29 +1100)]
net/tftp: Avoid a trivial UAF
Under tftp errors, we print a tftp error message from the tftp header.
However, the tftph pointer is a pointer inside nb, the netbuff. Previously,
we were freeing the nb and then dereferencing it. Don't do that, use it
and then free it later.
This isn't really _bad_ per se, especially as we're single-threaded, but
it trips up fuzzers.
Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Sun, 19 Sep 2021 15:12:24 +0000 (01:12 +1000)]
net/tftp: Prevent a UAF and double-free from a failed seek
A malicious tftp server can cause UAFs and a double free.
An attempt to read from a network file is handled by grub_net_fs_read(). If
the read is at an offset other than the current offset, grub_net_seek_real()
is invoked.
In grub_net_seek_real(), if a backwards seek cannot be satisfied from the
currently received packets, and the underlying transport does not provide
a seek method, then grub_net_seek_real() will close and reopen the network
protocol layer.
For tftp, the ->close() call goes to tftp_close() and frees the tftp_data_t
file->data. The file->data pointer is not nulled out after the free.
If the ->open() call fails, the file->data will not be reallocated and will
continue point to a freed memory block. This could happen from a server
refusing to send the requisite ack to the new tftp request, for example.
The seek and the read will then fail, but the grub_file continues to exist:
the failed seek does not necessarily cause the entire file to be thrown
away (e.g. where the file is checked to see if it is gzipped/lzio/xz/etc.,
a read failure is interpreted as a decompressor passing on the file, not as
an invalidation of the entire grub_file_t structure).
This means subsequent attempts to read or seek the file will use the old
file->data after free. Eventually, the file will be close()d again and
file->data will be freed again.
Mark a net_fs file that doesn't reopen as broken. Do not permit read() or
close() on a broken file (seek is not exposed directly to the file API -
it is only called as part of read, so this blocks seeks as well).
As an additional defence, null out the ->data pointer if tftp_open() fails.
That would have lead to a simple null pointer dereference rather than
a mess of UAFs.
This may affect other protocols, I haven't checked.
Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Mon, 20 Dec 2021 10:55:43 +0000 (21:55 +1100)]
net/dns: Don't read past the end of the string we're checking against
I don't really understand what's going on here but fuzzing found
a bug where we read past the end of check_with. That's a C string,
so use grub_strlen() to make sure we don't overread it.
Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Wed, 15 Sep 2021 15:29:54 +0000 (01:29 +1000)]
net/dns: Fix double-free addresses on corrupt DNS response
grub_net_dns_lookup() takes as inputs a pointer to an array of addresses
("addresses") for the given name, and pointer to a number of addresses
("naddresses"). grub_net_dns_lookup() is responsible for allocating
"addresses", and the caller is responsible for freeing it if
"naddresses" > 0.
The DNS recv_hook will sometimes set and free the addresses array,
for example if the packet is too short:
if (ptr + 10 >= nb->tail)
{
if (!*data->naddresses)
grub_free (*data->addresses);
grub_netbuff_free (nb);
return GRUB_ERR_NONE;
}
Later on the nslookup command code unconditionally frees the "addresses"
array. Normally this is fine: the array is either populated with valid
data or is NULL. But in these sorts of error cases it is neither NULL
nor valid and we get a double-free.
Only free "addresses" if "naddresses" > 0.
It looks like the other use of grub_net_dns_lookup() is not affected.
Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Mon, 20 Dec 2021 08:41:21 +0000 (19:41 +1100)]
net/ip: Do IP fragment maths safely
We can receive packets with invalid IP fragmentation information. This
can lead to rsm->total_len underflowing and becoming very large.
Then, in grub_netbuff_alloc(), we add to this very large number, which can
cause it to overflow and wrap back around to a small positive number.
The allocation then succeeds, but the resulting buffer is too small and
subsequent operations can write past the end of the buffer.
Catch the underflow here.
Fixes: CVE-2022-28733 Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Tue, 13 Jul 2021 03:24:38 +0000 (13:24 +1000)]
normal/charset: Fix array out-of-bounds formatting unicode for display
In some cases attempting to display arbitrary binary strings leads
to ASAN splats reading the widthspec array out of bounds.
Check the index. If it would be out of bounds, return a width of 1.
I don't know if that's strictly correct, but we're not really expecting
great display of arbitrary binary data, and it's certainly not worse than
an OOB read.
Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Wed, 7 Jul 2021 05:38:19 +0000 (15:38 +1000)]
video/readers/jpeg: Block int underflow -> wild pointer write
Certain 1 px wide images caused a wild pointer write in
grub_jpeg_ycrcb_to_rgb(). This was caused because in grub_jpeg_decode_data(),
we have the following loop:
On a 64-bit platform, if that turns out to be negative, it will underflow,
be interpreted as unsigned 64-bit, then be added to the 64-bit pointer, so
we see data->bitmap_ptr jump, e.g.:
0x6180_0000_0480 to
0x6181_0000_0498
^
~--- carry has occurred and this pointer is now far away from
any object.
On a 32-bit platform, it will decrement the pointer, creating a pointer
that won't crash but will overwrite random data.
Catch the underflow and error out.
Fixes: CVE-2021-3697 Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Mon, 28 Jun 2021 04:25:17 +0000 (14:25 +1000)]
video/readers/jpeg: Refuse to handle multiple start of streams
An invalid file could contain multiple start of stream blocks, which
would cause us to reallocate and leak our bitmap. Refuse to handle
multiple start of streams.
Additionally, fix a grub_error() call formatting.
Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In fuzzing we observed crashes where a code would attempt to be inserted
into a huffman table before the start, leading to a set of heap OOB reads
and writes as table entries with negative indices were shifted around and
the new code written in.
Catch the case where we would underflow the array and bail.
Fixes: CVE-2021-3696 Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
projects / thirdparty / grub.git / log
