Colin Watson [Mon, 13 Jan 2014 12:13:06 +0000 (12:13 +0000)]
"single" -> "recovery" when friendly-recovery is installed
If configured with --enable-ubuntu-recovery, also set nomodeset for
recovery mode, and disable 'set gfxpayload=keep' even if the system
normally supports it. See
https://launchpad.net/ubuntu/+spec/desktop-o-xorg-tools-and-processes.
Author: Stéphane Graber <stgraber@ubuntu.com>
Forwarded: no
Last-Update: 2013-12-25
Colin Watson [Mon, 13 Jan 2014 12:13:05 +0000 (12:13 +0000)]
Fall back to non-EFI if booted using EFI but -efi is missing
It may be possible, particularly in recovery situations, to be booted
using EFI on x86 when only the i386-pc target is installed, or on ARM
when only the arm-uboot target is installed. There's nothing actually
stopping us installing i386-pc or arm-uboot from an EFI environment, and
it's better than returning a confusing error.
Author: Steve McIntyre <93sam@debian.org>
Forwarded: no
Last-Update: 2019-05-24
Colin Watson [Mon, 13 Jan 2014 12:13:01 +0000 (12:13 +0000)]
Restore grub-mkdevicemap
This is kind of a mess, requiring lots of OS-specific code to iterate
over all possible devices. However, we use it in a number of scripts to
discover devices and reimplementing those in terms of something else
would be very complicated.
Author: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Forwarded: no
Last-Update: 2021-09-24
Colin Watson [Mon, 13 Jan 2014 12:13:00 +0000 (12:13 +0000)]
Handle filesystems loop-mounted on file images
Improve prepare_grub_to_access_device to emit appropriate commands for
such filesystems, and ignore them in Linux grub.d scripts.
This is needed for Ubuntu's Wubi installation method.
This patch isn't inherently Debian/Ubuntu-specific. losetup and
/proc/mounts are Linux-specific, though, so we might need to refine this
before sending it upstream. The changes to the Linux grub.d scripts
might be better handled by integrating 10_lupin properly instead.
Colin Watson [Mon, 13 Jan 2014 12:12:57 +0000 (12:12 +0000)]
Disable gfxpayload=keep by default
Setting gfxpayload=keep has been known to cause efifb to be
inappropriately enabled. In any case, with the current Linux kernel the
result of this option is that early kernelspace will be unable to print
anything to the console, so (for example) if boot fails and you end up
dumped to an initramfs prompt, you won't be able to see anything on the
screen. As such it shouldn't be enabled by default in Debian, no matter
what kernel options are enabled.
gfxpayload=keep is a good idea but rather ahead of its time ...
Bug-Debian: http://bugs.debian.org/567245
Forwarded: no
Last-Update: 2013-12-25
Daniel Kiper [Wed, 12 May 2021 14:37:54 +0000 (16:37 +0200)]
SECURITY: Add SECURITY file
The SECURITY file describes the GRUB project security policy.
It is based on https://github.com/wireapp/wire/blob/master/SECURITY.md
Signed-off-by: Alex Burmashev <alexander.burmashev@oracle.com> Signed-off-by: Vladimir Serbinenko <phcoder@google.com> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Kiper [Wed, 12 May 2021 14:36:57 +0000 (16:36 +0200)]
MAINTAINERS: Add MAINTAINERS file
The MAINTAINERS file provides basic information about the GRUB project
and its maintainers.
Signed-off-by: Alex Burmashev <alexander.burmashev@oracle.com> Signed-off-by: Vladimir Serbinenko <phcoder@google.com> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Refactor clean_grub_dir() to create a backup of all the files, instead
of just irrevocably removing them as the first action. If available,
register atexit() handler to restore the backup if errors occur before
point of no return, or remove the backup if everything was successful.
If atexit() is not available, the backup remains on disk for manual
recovery.
Some platforms defined a point of no return, i.e. after modules & core
images were updated. Failures from any commands after that stage are
ignored, and backup is cleaned up. For example, on EFI platforms update
is not reverted when efibootmgr fails.
Extra care is taken to ensure atexit() handler is only invoked by the
parent process and not any children forks. Some older GRUB codebases
can invoke parent atexit() hooks from forks, which can mess up the
backup.
This allows safer upgrades of MBR & modules, such that
modules/images/fonts/translations are consistent with MBR in case of
errors. For example accidental grub-install /dev/non-existent-disk
currently clobbers and upgrades modules in /boot/grub, despite not
actually updating any MBR.
This patch only handles backup and restore of files copied to /boot/grub.
This patch does not perform backup (or restoration) of MBR itself or
blocklists. Thus when installing i386-pc platform, corruption may still
occur with MBR and blocklists which will not be attempted to be
automatically recovered.
Also add modinfo.sh and *.efi to the cleanup/backup/restore code path,
to ensure it is also cleaned, backed up and restored.
Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
osdep/unix/exec: Avoid atexit() handlers when child execvp() fails
The functions grub_util_exec_pipe() and grub_util_exec_pipe_stderr()
currently call execvp(). If the call fails for any reason, the child
currently calls exit(127). This in turn executes the parents
atexit() handlers from the forked child, and then the same handlers
are called again from parent. This is usually not desired, and can
lead to deadlocks, and undesired behavior. So, change the exit() calls
to _exit() calls to avoid calling atexit() handlers from child.
Fixes: e75cf4a58 (unix exec: avoid atexit handlers when child exits) Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This fixes cross-compiling to x86 (e.g., the Hurd) from x86-linux of
grub-core/lib/i386/relocator64.S
This file has six sections that only build with a 64-bit assembler,
yet only the first two sections had support for a 32-bit assembler.
This patch completes this for the remaining sections.
To reproduce, update the GRUB source description in your local Guix
archive and run
The XFS now has an incompat feature flag to indicate that a filesystem
needs to be repaired. The Linux kernel refuses to mount the filesystem
that has it set and only the xfs_repair tool is able to clear that flag.
The GRUB doesn't have the concept of mounting filesystems and just
attempts to read the files. But it does some sanity checking before
attempting to read from the filesystem. Among the things which are tested,
is if the super block only has set of incompatible features flags that
are supported by GRUB. If it contains any flags that are not listed as
supported, reading the XFS filesystem fails.
Since the GRUB doesn't attempt to detect if the filesystem is inconsistent
nor replays the journal, the filesystem access is a best effort. For this
reason, ignore if the filesystem needs to be repaired and just print a debug
message. That way, if reading or booting fails later, the user is able to
figure out that the failures can be related to broken XFS filesystem.
Suggested-by: Eric Sandeen <esandeen@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Carlos Maiolino [Mon, 24 May 2021 17:40:06 +0000 (19:40 +0200)]
fs/xfs: Add bigtime incompat feature support
The XFS filesystem supports a bigtime feature to overcome y2038 problem.
This patch makes the GRUB able to support the XFS filesystems with this
feature enabled.
The XFS counter for the bigtime enabled timestamps starts at 0, which
translates to GRUB_INT32_MIN (Dec 31 20:45:52 UTC 1901) in the legacy
timestamps. The conversion to Unix timestamps is made before passing the
value to other GRUB functions.
For this to work properly, GRUB requires an access to flags2 field in the
XFS ondisk inode. So, the grub_xfs_inode structure has been updated to
cover full ondisk inode.
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Carlos Maiolino [Mon, 24 May 2021 17:40:05 +0000 (19:40 +0200)]
fs: Use 64-bit type for filesystem timestamp
Some filesystems nowadays use 64-bit types for timestamps. So, update
grub_dirhook_info struct to use an grub_int64_t type to store mtime.
This also updates the grub_unixtime2datetime() function to receive
a 64-bit timestamp argument and do 64-bit-safe divisions.
All the remaining conversion from 32-bit to 64-bit should be safe, as
32-bit to 64-bit attributions will be implicitly casted. The most
critical part in the 32-bit to 64-bit conversion is in the function
grub_unixtime2datetime() where it needs to deal with the 64-bit type.
So, for that, the grub_divmod64() helper has been used.
These changes enables the GRUB to support dates beyond y2038.
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
types: Define PRI{x,d}GRUB_INT{32,64}_T format specifiers
There are already PRI*_T constants defined for unsigned integers but not
for signed integers. Add format specifiers for the latter.
Suggested-by: Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
util/mkimage: Fix wrong PE32+ section sizes for some arches
The commit f60ba9e5945 (util/mkimage: Refactor section setup to use a helper)
added a helper function to setup PE sections. But it also changed how the
raw data offsets were calculated since all the section sizes are aligned.
However, for some platforms, i.e ia64-efi and arm64-efi, the kernel image
size is not aligned using the section alignment. This leads to the situation
in which the mods section offset in its PE section header does not match its
real placement in the PE file. So, finally the GRUB is not able to locate
and load built-in modules.
The problem surfaces on ia64-efi and arm64-efi because both platforms
require additional relocation data which is added behind .bss section.
So, we have to add some padding behind this extra data to make the
beginning of mods section properly aligned in the PE file. Fix it by
aligning the kernel_size to the section alignment. That makes the sizes
and offsets in the PE section headers to match relevant sections in the
PE32+ binary file.
Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
i18n: Format large integers before the translation message
The GNU gettext only supports the ISO C99 macros for integral
types. If there is a need to use unsupported formatting macros,
e.g. PRIuGRUB_UINT64_T, according to [1] the number to a string
conversion should be separated from the code printing message
requiring the internationalization. So, the function grub_snprintf()
is used to print the numeric values to an intermediate buffer and
the internationalized message contains a string format directive.
Daniel Axtens [Thu, 1 Apr 2021 15:22:04 +0000 (02:22 +1100)]
video/fb/fbfill: Use unsigned integers for width/height
Since commit 7ce3259f67ac (video/fb/fbfill: Fix potential integer
overflow), clang builds of grub-emu have failed with messages like:
/usr/bin/ld: libgrubmods.a(libgrubmods_a-fbfill.o): in function `grub_video_fbfill_direct24':
fbfill.c:(.text+0x28e): undefined reference to `__muloti4'
This appears to be due to a weird quirk in how clang compiles
which is grub_mul(unsigned int, int, &grub_size_t).
It looks like clang somewhere promotes everything to 128-bit maths
before ultimately reducing down to 64 bit for grub_size_t. I think
this is because width is signed, and indeed converting width to an
unsigned int makes the problem go away.
This conversion also makes more sense generally:
- the caller of all the fbfill_directN functions is
grub_video_fb_fill_dispatch() and it takes width and height as
unsigned ints already,
- it doesn't make sense to fill a negative width or height.
Convert the width and height arguments and associated loop counters
to unsigned ints.
Fixes: 7ce3259f67ac (video/fb/fbfill: Fix potential integer overflow) Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Colin Watson [Fri, 19 Mar 2021 23:54:38 +0000 (23:54 +0000)]
buffer: Sync up out-of-range error message
The messages associated with other similar GRUB_ERR_OUT_OF_RANGE errors
were lacking the trailing full stop. Syncing up the strings saves a small
amount of precious core image space on i386-pc.
The ext2 (and ext3, ext4) filesystems write the number of free inodes to
location 0x410.
On a MINIX filesystem, that same location is used for the MINIX superblock
magic number.
If the number of free inodes on an ext2 filesystem is equal to any
of the four MINIX superblock magic values plus any multiple of 65536,
GRUB's MINIX filesystem code will probe it as a MINIX filesystem.
In the case of an OS using ext2 as the root filesystem, since there will
ordinarily be some amount of file creation and deletion on every bootup,
it effectively means that this situation has a 1:16384 chance of being hit
on every reboot.
This will cause GRUB's filesystem probing code to mistakenly identify an
ext2 filesystem as MINIX. This can be seen by e.g. "search --label"
incorrectly indicating that no such ext2 partition with matching label
exists, whereas in fact it does.
After spotting the rough cause of the issue I was facing here, I borrowed
much of the diagnosis/explanation from meierfra who found and investigated
the same issue in util-linux in 2010:
Ard Biesheuvel [Sun, 25 Oct 2020 13:49:34 +0000 (14:49 +0100)]
arm/linux: Fix ARM Linux header layout
The hdr_offset member of the ARM Linux image header appears at
offset 0x3c, matching the PE/COFF spec's placement of the COFF
header offset in the MS-DOS header. We're currently off by four,
so fix that.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Fri, 5 Mar 2021 00:22:43 +0000 (18:22 -0600)]
fs/zfs/zfs: Use format code "%llu" for 64-bit uint bp->blk_prop in grub_error()
This is a temporary, less-intrusive change to get the build to success with
compiler format string checking turned on. There is a better fix which
addresses this issue, but it needs more testing. Use this change so that
format string checking on grub_error() can be turned on until the better
change is fully tested.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Fri, 5 Mar 2021 00:22:41 +0000 (18:22 -0600)]
dl/elf: Use format code PRIxGRUB_UINT64_T for 64-bit arg in grub_error()
The macro ELF_R_TYPE does not change the underlying type. Here its argument
is a 64-bit Elf64_Xword. Make sure the format code matches.
For the RISC-V architecture, rel->r_info could be either Elf32_Xword or
Elf64_Xword depending on if 32 or 64-bit RISC-V is being built. So cast
to 64-bit value regardless.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Fri, 5 Mar 2021 00:22:38 +0000 (18:22 -0600)]
kern/efi/mm: Format string error in grub_error()
The second format string argument, GRUB_EFI_MAX_USABLE_ADDRESS, is a macro
to a number literal. However, depending on what the target architecture, the
type can be 32 or 64 bits. Cast to a 64-bit integer. Also, change the
format string literals "%llx" to use PRIxGRUB_UINT64_T.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Fri, 5 Mar 2021 00:22:37 +0000 (18:22 -0600)]
commands/pgp: Format code for grub_error() is incorrect
The format code is for a 32-bit int, but the argument, keyid, is declared as
a 64 bit int. The comment above says keyid is 32-bit. I'm not sure if the
comment or declaration is wrong, so force the display of a 64-bit int for now.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Fri, 5 Mar 2021 00:22:35 +0000 (18:22 -0600)]
disk/dmraid_nvidia: Format string error in grub_error()
The grub_error() has a format string expecting two arguments, but only one
provided. According to the comments in the struct grub_nv_super definition,
the version field looks like a version number where major.minor is encoded
as each a byte in the two-byte short.
Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Philip Müller [Tue, 9 Mar 2021 21:10:14 +0000 (22:10 +0100)]
templates: Properly disable the os-prober by default
This patch does the following:
- really disables os-prober by default in the util/grub-mkconfig.in
by setting GRUB_DISABLE_OS_PROBER to true,
- fixes the logic in the util/grub.d/30_os-prober.in,
- updates the grub_warn() lines.
Reason for the code shuffling in the util/grub-mkconfig.in:
The default was GRUB_DISABLE_OS_PROBER=false if you don't set
GRUB_DISABLE_OS_PROBER at all. To prevent os-prober from starting we
have to set it by default to true and shuffle GRUB_DISABLE_OS_PROBER to
code section, which is executed by the script. However we still give an
option to the user to overwrite it with false, if he wants to execute
os-prober after all.
Fixes: e3464147 (templates: Disable the os-prober by default) Reported-by: Didier Spaier <didier@slint.fr> Reported-by: Lennart Sorensen <lsorense@csclub.uwaterloo.ca> Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by: Philip Müller <philm@manjaro.org> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Michael Chang [Fri, 5 Mar 2021 13:48:53 +0000 (21:48 +0800)]
kern/efi/sb: Add chainloaded image as shim's verifiable object
While attempting to dual boot Microsoft Windows with UEFI chainloader,
it failed with below error when UEFI Secure Boot was enabled:
error ../../grub-core/kern/verifiers.c:119:verification requested but
nobody cares: /EFI/Microsoft/Boot/bootmgfw.efi.
It is a regression, as previously it worked without any problem.
It turns out chainloading PE image has been locked down by commit 578c95298 (kern: Add lockdown support). However, we should consider it
as verifiable object by shim to allow booting in UEFI Secure Boot mode.
The chainloaded PE image could also have trusted signature created by
vendor with their pubkey cert in db. For that matters it's usage should
not be locked down under UEFI Secure Boot, and instead shim should be
allowed to validate a PE binary signature before running it.
Fixes: 578c95298 (kern: Add lockdown support) Signed-off-by: Michael Chang <mchang@suse.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn [Mon, 1 Mar 2021 19:36:28 +0000 (13:36 -0600)]
disk/pata: Suppress error message "no device connected"
This error message comes from the grub_print_error() in
grub_pata_device_initialize(), which does not pass on the error, and is
raised in check_device(). The function check_device() needs to return this
as an error because check_device() is also used in grub_pata_open(), which
does pass on this error to indicate that the device can not be used.
This is actually not an error when displayed by grub_pata_device_initialize()
because it just indicates that there are no pata devices seen. This may be
confusing to end users who do not have pata devices yet are loading the
pata module (perhaps implicitly via nativedisk). This also causes unnecessary
output which may need to be accounted for in functional testing.
Instead print to the debug log when check_device() raises this "error" and
pop the error from the error stack. If there is another error on the stack
then print the error stack as those should be real errors.
Signed-off-by: Glenn Washburn <development@efficientek.com> Acked-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Yi Zhao [Fri, 8 Jan 2021 00:39:47 +0000 (08:39 +0800)]
fs/ext2: Fix a file not found error when a symlink filesize is equal to 60
We encountered a file not found error when the symlink filesize is
equal to 60:
$ ls -l initrd
lrwxrwxrwx 1 root root 60 Jan 6 16:37 initrd -> secure-core-image-initramfs-5.10.2-yoctodev-standard.cpio.gz
When booting, we got the following error in the GRUB:
error: file `/initrd' not found
The root cause is that the size of diro->inode.symlink is equal to 60
and a symlink name has to be terminated with NUL there. So, if the
symlink filesize is exactly 60 then it is also stored in a separate
block rather than in the inode itself.
Signed-off-by: Yi Zhao <yi.zhao@windriver.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tianjia Zhang [Mon, 11 Jan 2021 03:04:36 +0000 (11:04 +0800)]
loader/i386/linux: Do not use grub_le_to_cpu32() for relocatable variable
The relocatable variable is defined as grub_uint8_t. Relevant
member in setup_header structure is also defined as one byte
in Linux boot protocol. By semantic definition it is a bool type.
It is not appropriate to treat it as a four bytes. This patch
fixes the issue.
Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tianjia Zhang [Mon, 11 Jan 2021 03:04:51 +0000 (11:04 +0800)]
loader/i386/linux: Remove redundant code from in grub_cmd_linux()
The preferred_address has been assigned to GRUB_LINUX_BZIMAGE_ADDR
during initialization in grub_cmd_linux(). The assignment here
is redundant and should be removed.
Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
efi: The device-tree must be in EfiACPIReclaimMemory
According to the Embedded Base Boot Requirements (EBBR) specification the
device-tree passed to Linux as a configuration table must reside in
EfiACPIReclaimMemory.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
commands/efi/lsefisystab: Add short text for EFI_RT_PROPERTIES_TABLE_GUID
UEFI specification 2.8 errata B introduced the EFI_RT_PROPERTIES_TABLE
describing the services available at runtime.
The lsefisystab command is used to display installed EFI configuration
tables. Currently it only shows the GUID but not a short text for the
new table.
Provide a short text for the EFI_RT_PROPERTIES_TABLE_GUID.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Petr Vorel [Tue, 2 Mar 2021 16:16:57 +0000 (17:16 +0100)]
docs/luks2: Mention key derivation function support
To give users hint why Argon2, the default in cryptsetup for LUKS2, does
not work.
Signed-off-by: Petr Vorel <pvorel@suse.cz> Acked-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by: Patrick Steinhardt <ps@pks.im> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Derek Foreman [Fri, 26 Feb 2021 18:05:07 +0000 (12:05 -0600)]
commands/file: Fix array/enum desync
The commit f1957dc8a (RISC-V: Add to build system) added two entries to
the options array, but only 1 entry to the enum. This resulted in
everything after the insertion point being off by one.
This broke at least the "file --is-hibernated-hiberfil" command.
Bring the two back in sync by splitting the IS_RISCV_EFI enum entry into
two, as is done for other architectures.
Signed-off-by: Derek Foreman <derek@endlessos.org> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Fix compilation error due to missing parameter to
grub_printf() when MM_DEBUG is defined.
Fixes: 64e26162e (calloc: Make sure we always have an overflow-checking calloc() available) Signed-off-by: Marco A Benatto <mbenatto@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Alex Burmashev [Tue, 16 Feb 2021 10:12:12 +0000 (11:12 +0100)]
templates: Disable the os-prober by default
The os-prober is enabled by default what may lead to potentially
dangerous use cases and borderline opening attack vectors. This
patch disables the os-prober, adds warning messages and updates
GRUB_DISABLE_OS_PROBER configuration option documentation. This
way we make it clear that the os-prober usage is not recommended.
Simplistic nature of this change allows downstream vendors, who
really want os-prober to be enabled out of the box in their
relevant products, easily revert to it's old behavior.
Reported-by: NyankoSec (<nyanko@10x.moe>, https://twitter.com/NyankoSec),
working with SSD Secure Disclosure Signed-off-by: Alex Burmashev <alexander.burmashev@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
gfxmenu/gui: Check printf() format in the gui_progress_bar and gui_label
The gui_progress_bar and gui_label components can display the timeout
value. The format string can be set through a theme file. This patch
adds a validation step to the format string.
If a user loads a theme file into the GRUB without this patch then
a GUI label with the following settings
+ label {
...
id = "__timeout__"
text = "%s"
}
will interpret the current timeout value as string pointer and print the
memory at that position on the screen. It is not desired behavior.
Signed-off-by: Thomas Frauendorfer | Miray Software <tf@miray.de> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
kern/misc: Add function to check printf() format against expected format
The grub_printf_fmt_check() function parses the arguments of an untrusted
printf() format and an expected printf() format and then compares the
arguments counts and arguments types. The arguments count in the untrusted
format string must be less or equal to the arguments count in the expected
format string and both arguments types must match.
To do this the parse_printf_arg_fmt() helper function is extended in the
following way:
1. Add a return value to report errors to the grub_printf_fmt_check().
2. Add the fmt_check argument to enable stricter format verification:
- the function expects that arguments definitions are always
terminated by a supported conversion specifier.
- positional parameters, "$", are not allowed, as they cannot be
validated correctly with the current implementation. For example
"%s%1$d" would assign the first args entry twice while leaving the
second one unchanged.
- Return an error if preallocated space in args is too small and
allocation fails for the needed size. The grub_printf_fmt_check()
should verify all arguments. So, if validation is not possible for
any reason it should return an error.
This also adds a case entry to handle "%%", which is the escape
sequence to print "%" character.
3. Add the max_args argument to check for the maximum allowed arguments
count in a printf() string. This should be set to the arguments count
of the expected format. Then the parse_printf_arg_fmt() function will
return an error if the arguments count is exceeded.
The two additional arguments allow us to use parse_printf_arg_fmt() in
printf() and grub_printf_fmt_check() calls.
When parse_printf_arg_fmt() is used by grub_printf_fmt_check() the
function parse user provided untrusted format string too. So, in
that case it is better to be too strict than too lenient.
Signed-off-by: Thomas Frauendorfer | Miray Software <tf@miray.de> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
kern/misc: Add STRING type for internal printf() format handling
Set printf() argument type for "%s" to new type STRING. This is in
preparation for a follow up patch to compare a printf() format string
against an expected printf() format string.
For "%s" the corresponding printf() argument is dereferenced as pointer
while all other argument types are defined as integer value. However,
when validating a printf() format it is necessary to differentiate "%s"
from "%p" and other integers. So, let's do that.
Signed-off-by: Thomas Frauendorfer | Miray Software <tf@miray.de> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
kern/misc: Split parse_printf_args() into format parsing and va_list handling
This patch is preparing for a follow up patch which will use
the format parsing part to compare the arguments in a printf()
format from an external source against a printf() format with
expected arguments.
Signed-off-by: Thomas Frauendorfer | Miray Software <tf@miray.de> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
shim_lock: Only skip loading shim_lock verifier with explicit consent
Commit 32ddc42c (efi: Only register shim_lock verifier if shim_lock
protocol is found and SB enabled) reintroduced CVE-2020-15705 which
previously only existed in the out-of-tree linuxefi patches and was
fixed as part of the BootHole patch series.
Under Secure Boot enforce loading shim_lock verifier. Allow skipping
shim_lock verifier if SecureBoot/MokSBState EFI variables indicate
skipping validations, or if GRUB image is built with --disable-shim-lock.
Fixes: 132ddc42c (efi: Only register shim_lock verifier if shim_lock
protocol is found and SB enabled) Fixes: CVE-2020-15705 Fixes: CVE-2021-3418 Reported-by: Dimitri John Ledkov <xnox@ubuntu.com> Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Peter Jones [Mon, 15 Feb 2021 16:07:00 +0000 (17:07 +0100)]
util/mkimage: Add an option to import SBAT metadata into a .sbat section
Add a --sbat option to the grub-mkimage tool which allows us to import
an SBAT metadata formatted as a CSV file into a .sbat section of the
EFI binary.
Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Peter Jones [Mon, 15 Feb 2021 13:58:06 +0000 (14:58 +0100)]
util/mkimage: Refactor section setup to use a helper
Add a init_pe_section() helper function to setup PE sections. This makes
the code simpler and easier to read.
Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Peter Jones [Thu, 11 Feb 2021 16:07:33 +0000 (17:07 +0100)]
util/mkimage: Improve data_size value calculation
According to "Microsoft Portable Executable and Common Object File Format
Specification", the Optional Header SizeOfInitializedData field contains:
Size of the initialized data section, or the sum of all such sections if
there are multiple data sections.
Make this explicit by adding the GRUB kernel data size to the sum of all
the modules sizes. The ALIGN_UP() is not required by the PE spec but do
it to avoid alignment issues.
Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Peter Jones [Mon, 15 Feb 2021 13:21:48 +0000 (14:21 +0100)]
util/mkimage: Reorder PE optional header fields set-up
This makes the PE32 and PE32+ header fields set-up easier to follow by
setting them closer to the initialization of their related sections.
Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Peter Jones [Mon, 15 Feb 2021 13:19:31 +0000 (14:19 +0100)]
util/mkimage: Unify more of the PE32 and PE32+ header set-up
There's quite a bit of code duplication in the code that sets the optional
header for PE32 and PE32+. The two are very similar with the exception of
a few fields that have type grub_uint64_t instead of grub_uint32_t.
Factor out the common code and add a PE_OHDR() macro that simplifies the
set-up and make the code more readable.
Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Peter Jones [Mon, 15 Feb 2021 13:14:24 +0000 (14:14 +0100)]
util/mkimage: Always use grub_host_to_target32() to initialize PE stack and heap stuff
This change does not impact final result of initialization itself.
However, it eases PE code unification in subsequent patches.
Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Peter Jones [Mon, 15 Feb 2021 12:59:21 +0000 (13:59 +0100)]
util/mkimage: Use grub_host_to_target32() instead of grub_cpu_to_le32()
The latter doesn't take into account the target image endianness. There is
a grub_cpu_to_le32_compile_time() but no compile time variant for function
grub_host_to_target32(). So, let's keep using the other one for this case.
Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
It works only on UEFI platforms but can be quite easily extended to
others architectures and platforms if needed.
Signed-off-by: Chris Coulson <chris.coulson@canonical.com> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> Reviewed-by: Marco A Benatto <mbenatto@redhat.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Chris Coulson [Thu, 7 Jan 2021 19:21:03 +0000 (19:21 +0000)]
kern/parser: Fix a stack buffer overflow
grub_parser_split_cmdline() expands variable names present in the supplied
command line in to their corresponding variable contents and uses a 1 kiB
stack buffer for temporary storage without sufficient bounds checking. If
the function is called with a command line that references a variable with
a sufficiently large payload, it is possible to overflow the stack
buffer via tab completion, corrupt the stack frame and potentially
control execution.
Fixes: CVE-2020-27749 Reported-by: Chris Coulson <chris.coulson@canonical.com> Signed-off-by: Chris Coulson <chris.coulson@canonical.com> Signed-off-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Introduce a common function epilogue used for cleaning up on all
return paths, which will simplify additional error handling to be
introduced in a subsequent commit.
Signed-off-by: Chris Coulson <chris.coulson@canonical.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Chris Coulson [Tue, 5 Jan 2021 22:17:28 +0000 (22:17 +0000)]
kern/parser: Introduce process_char() helper
grub_parser_split_cmdline() iterates over each command line character.
In order to add error checking and to simplify the subsequent error
handling, split the character processing in to a separate function.
Signed-off-by: Chris Coulson <chris.coulson@canonical.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Chris Coulson [Wed, 18 Nov 2020 00:59:24 +0000 (00:59 +0000)]
kern/parser: Fix a memory leak
The getline() function supplied to grub_parser_split_cmdline() returns
a newly allocated buffer and can be called multiple times, but the
returned buffer is never freed.
Signed-off-by: Chris Coulson <chris.coulson@canonical.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Fri, 22 Jan 2021 03:43:58 +0000 (14:43 +1100)]
disk/lvm: Sanitize rlocn->offset to prevent wild read
rlocn->offset is read directly from disk and added to the metadatabuf
pointer to create a pointer to a block of metadata. It's a 64-bit
quantity so as long as you don't overflow you can set subsequent
pointers to point anywhere in memory.
Require that rlocn->offset fits within the metadata buffer size.
Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Thu, 21 Jan 2021 07:35:22 +0000 (18:35 +1100)]
disk/lvm: Do not crash if an expected string is not found
Clean up a bunch of cases where we could have strstr() fail and lead to
us dereferencing NULL.
We'll still leak memory in some cases (loops don't clean up allocations
from earlier iterations if a later iteration fails) but at least we're
not crashing.
Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Thu, 21 Jan 2021 07:54:29 +0000 (18:54 +1100)]
disk/lvm: Bail on missing PV list
There's an if block for the presence of "physical_volumes {", but if
that block is absent, then p remains NULL and a NULL-deref will result
when looking for logical volumes.
It doesn't seem like LVM makes sense without physical volumes, so error
out rather than crashing.
Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Thu, 21 Jan 2021 07:19:51 +0000 (18:19 +1100)]
disk/lvm: Don't blast past the end of the circular metadata buffer
This catches at least some OOB reads, and it's possible I suppose that
if 2 * mda_size is less than GRUB_LVM_MDA_HEADER_SIZE it might catch some
OOB writes too (although that hasn't showed up as a crash in fuzzing yet).
It's a bit ugly and I'd appreciate better suggestions.
Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Daniel Axtens [Thu, 21 Jan 2021 06:59:14 +0000 (17:59 +1100)]
disk/lvm: Don't go beyond the end of the data we read from disk
We unconditionally trusted offset_xl from the LVM label header, even if
it told us that the PV header/disk locations were way off past the end
of the data we read from disk.
Require that the offset be sane, fixing an OOB read and crash.
Fixes: CID 314367, CID 314371 Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
projects / grub2.git / log