The upcoming support for LUKS2 disc encryption requires us to include a
parser for base64-encoded data, as it is used to represent salts and
digests. As gnulib already has code to decode such data, we can just
add it to the boostrapping configuration in order to make it available
in GRUB.
The gnulib module makes use of booleans via the <stdbool.h> header. As
GRUB does not provide any POSIX wrapper header for this, but instead
implements support for bool in <sys/types.h>, we need to patch
base64.h to not use <stdbool.h> anymore. We unfortunately cannot include
<sys/types.h> instead, as it would then use gnulib's internal header
while compiling the gnulib object but our own <sys/types.h> when
including it in a GRUB module. Because of this, the patch replaces the
include with a direct typedef.
A second fix is required to make available _GL_ATTRIBUTE_CONST, which
is provided by the configure script. As base64.h does not include
<config.h>, it is thus not available and results in a compile error.
This is fixed by adding an include of <config-util.h>.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
While the newly added jsmn library provides the parsing interface, it
does not provide any kind of interface to act on parsed tokens. Instead,
the caller is expected to handle pointer arithmetics inside of the token
array in order to extract required information. While simple, this
requires users to know some of the inner workings of the library and is
thus quite an unintuitive interface.
This commit adds a new interface on top of the jsmn parser that provides
convenience functions to retrieve values from the parsed json type, grub_json_t.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The upcoming support for LUKS2 encryption will require a JSON parser to
decode all parameters required for decryption of a drive. As there is
currently no other tool that requires JSON, and as gnulib does not
provide a parser, we need to introduce a new one into the code base. The
backend for the JSON implementation is going to be the jsmn library [1].
It has several benefits that make it a very good fit for inclusion in
GRUB:
- It is licensed under MIT.
- It is written in C89.
- It has no dependencies, not even libc.
- It is small with only about 500 lines of code.
- It doesn't do any dynamic memory allocation.
- It is testen on x86, amd64, ARM and AVR.
The library itself comes as a single header, only, that contains both
declarations and definitions. The exposed interface is kind of
simplistic, though, and does not provide any convenience features
whatsoever. Thus there will be a separate interface provided by GRUB
around this parser that is going to be implemented in the following
commit. This change only imports jsmn.h from tag v1.1.0 and adds it
unmodified to a new json module with the following command:
curl -L https://raw.githubusercontent.com/zserge/jsmn/v1.1.0/jsmn.h \
-o grub-core/lib/json/jsmn.h
Upstream jsmn commit hash: fdcef3ebf886fa210d14956d3c068a653e76a24e
Upstream jsmn commit name: Modernize (#149), 2019-04-20
[1]: https://github.com/zserge/jsmn
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In some cases GRUB2 allocates multiboot2 structure at 0 address, that is
a confusing behavior. Consumers of that structure can have internal NULL-checks
that will throw an error when get a pointer to data allocated at address 0.
To prevent that, define min address for mbi allocation on x86 and x86_64
platforms.
Signed-off-by: Lukasz Hawrylko <lukasz.hawrylko@linux.intel.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Recent work around x86 Linux kernel loader revealed an underflow in the
setup_header length calculation and another related issue. Both lead to
the memory overwrite and later machine crash.
Currently when the GRUB copies the setup_header into the linux_params
(struct boot_params, traditionally known as "zero page") it assumes the
setup_header size as sizeof(linux_i386_kernel_header/lh). This is
incorrect. It should use the value calculated accordingly to the Linux
kernel boot protocol. Otherwise in case of pretty old kernel, to be
exact Linux kernel boot protocol, the GRUB may write more into
linux_params than it was expected to. Fortunately this is not very big
issue. Though it has to be fixed. However, there is also an underflow
which is grave. It happens when
sizeof(linux_i386_kernel_header/lh) > "real size of the setup_header".
Then len value wraps around and grub_file_read() reads whole kernel into
the linux_params overwriting memory past it. This leads to the GRUB
memory allocator breakage and finally to its crash during boot.
The patch fixes both issues. Additionally, it moves the code not related to
grub_memset(linux_params)/grub_memcpy(linux_params)/grub_file_read(linux_params)
section outside of it to not confuse the reader.
Fixes: e683cfb0cf (loader/i386/linux: Calculate the setup_header length)
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Blocklist fallout cleanup after commit 5c6f9bc15 (generic/blocklist: Fix
implicit declaration of function grub_file_filter_disable_compression()).
Signed-off-by: David Michael <fedora.dm0@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=dabdfa1c6a80639197d05f683a445fa8615517fe
Last-Update: 2019-12-12
Patch-Name: verifiers-blocklist-fallout.patch
New 3- and 4-copy variants of RAID1 were merged into Linux kernel 5.5.
Add the two new profiles to the list of recognized ones. As this builds
on the same code as RAID1, only the redundancy level needs to be
adjusted, the rest is done by the existing code.
Signed-off-by: David Sterba <dsterba@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Some TFTP servers do not handle multiple consecutive slashes correctly.
This patch avoids sending TFTP requests with non-normalized paths.
Signed-off-by: Lenny Szubowicz <lszubowi@redhat.com>
Signed-off-by: Mark Salter <msalter@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The environment block is a preallocated 1024-byte file which serves as
persistent storage for environment variables. It has its own format
which is sensitive to corruption if an editor does not know how to
process it. Besides that the editor may inadvertently change grubenv
file size and/or make it sparse which can lead to unexpected results.
This patch adds a message to the grubenv file to warn a user against
editing it by tools other than grub-editenv.
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
We are often bothered by this sort of lvm warning while running grub-install
every now and then:
File descriptor 4 (/dev/vda1) leaked on vgs invocation. Parent PID 1991: /usr/sbin/grub2-install
The requirement related to the warning is dictated in the lvm man page:
"On invocation, lvm requires that only the standard file descriptors stdin,
stdout and stderr are available. If others are found, they get closed and
messages are issued warning about the leak. This warning can be suppressed by
setting the environment variable LVM_SUPPRESS_FD_WARNINGS."
While it could be disabled through settings, most Linux distributions seem to
enable it by default and the justification provided by the developer looks to
be valid to me: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466138#15
Rather than trying to close and reopen the file descriptor to the same file
multiple times, which is rather cumbersome, for the sake of no vgs invocation
could happen in between. This patch enables the close-on-exec flag (O_CLOEXEC)
for new file descriptor returned by the open() system call, making it closed
thus not inherited by the child process forked and executed by the exec()
family of functions.
Fixes Debian bug #466138.
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Although dpkg-architecture supports wildcards with up to four
components, Debian Policy only specifies "any", "<os>-any", and
"any-<cpu>", and Lintian checks that. Fix the libefiboot-dev and
libefivar-dev build-dependencies to match this.
GCC 9 has a new -Waddress-of-packed-member warning, enabled by default;
set_mode trips over this by taking the addresses of members of the
packed modeline structs. Use local variables to avoid this.
The "which" utility is not guaranteed to be installed either, and if it
is, its behavior is not portable either.
Conversely, the "command -v" shell builtin is required to exist in all
POSIX 2008 compliant shells, and is thus guaranteed to work everywhere.
Examples of open-source shells likely to be installed as /bin/sh on
Linux, which implement the 11-year-old standard: ash, bash, busybox,
dash, ksh, mksh and zsh.
A side benefit of using the POSIX portable option is that it requires
neither an external disk executable, nor (because unlike "which", the
exit code is reliable) a subshell fork. This therefore represents a mild
speedup.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The grub-mkconfig and 10_linux scripts by default attempt to use a UUID to
set the root kernel command line parameter and the $root GRUB environment
variable.
The former can be disabled by setting the GRUB_DISABLE_LINUX_UUID variable
to "true", but there is currently no way to disable the latter.
The generated grub config uses the search command with the --fs-uuid option
to find the device that has to be set as $root, i.e:
search --no-floppy --fs-uuid --set=root ...
This is usually more reliable but in some cases it may not be appropriate,
so this patch introduces a new GRUB_DISABLE_UUID variable that can be used
to disable searching for the $root device by filesystem UUID.
When disabled, the $root device will be set to the value specified in the
device.map as found by the grub-probe --target=compatibility_hint option.
When setting GRUB_DISABLE_UUID=true, the GRUB_DISABLE_LINUX_UUID and
GRUB_DISABLE_LINUX_PARTUUID variables will also be set to "true" unless
these have been explicitly set to "false".
That way, the GRUB_DISABLE_UUID variable can be used to force using the
device names for both GRUB and Linux.
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>
Reviewed-by: Nicholas Vinson <nvinson234@gmail.com>
This patch fixes an issue that prevented the at_keyboard module to work
(for me). The cause was a bad/wrong return value in the
grub_at_keyboard_getkey() function in grub-core/term/at_keyboard.c file
at line 237. My symptoms were to have an unresponsive keyboard. Keys
needed to be pressed 10x and more to effectively be printed sometimes
generating multiple key presses (after 1 or 2 sec of no printing). It
was very problematic when typing passphrase in early stage (with
GRUB_ENABLE_CRYPTODISK). When switched to "console" terminal input
keyboard worked perfectly. It also worked great with the GRUB 2.02
packaged by Debian (2.02+dfsg1-20). It was not an output issue but an
input one.
I've managed to analyze the issue and found that it came from the commit
216950a4e (at_keyboard: Split protocol from controller code.). Three
lines where moved from the fetch_key() function in
grub-core/term/at_keyboard.c file to the beginning of
grub_at_keyboard_getkey() function (same file). However, returning -1
made sense when it happened in fetch_key() function but not anymore in
grub_at_keyboard_getkey() function which should return GRUB_TERM_NO_KEY.
I think it was just an incomplete cut-paste missing a small manual
correction. Let's fix it.
Note: Commit message updated by Daniel Kiper.
Signed-off-by: Michael Bideau <mica.devel@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The GRUB_DISABLE_SUBMENU option is different than the others in the sense
that it has to be set to "y" instead of "true" to be enabled.
That causes a lot of confusion to users, some may wrongly set it to "true"
expecting that will work the same than with most options, and some may set
it to "yes" since for other options the value to set is a word and not a
single character.
This patch changes all the grub.d scripts using the GRUB_DISABLE_SUBMENU
option, so they check if it was set to "true" instead of "y", making it
consistent with all the other options.
But to keep backward compatibility for users that set the option to "y" in
/etc/default/grub file, keep testing for this value. And also do it for
"yes", since it is a common mistake made by users caused by this option
being inconsistent with the others.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Extend partition UUID probing support in GRUB core to display pseudo
partition UUIDs for MBR (MSDOS) partitions.
Signed-off-by: Nicholas Vinson <nvinson234@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The short form of "--version" that grub-mkconfig accepts is "-V", not "-v".
Fixes Debian bug #935504.
Signed-off-by: Colin Watson <cjwatson@ubuntu.com>
Reviewed-by: Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This is needed for the zstd module build for riscv64-emu.
Signed-off-by: Andreas Schwab <schwab@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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>
Honor a symlink when generating configuration by grub-mkconfig, so that
the -o option follows it rather than overwriting it with a regular file.
Signed-off-by: Marcel Kolaja <mkolaja@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Don't free file->data on receiving FIN flag since it is used all over
without checking. http_close() will be called later to free that memory.
Fixes bug: https://bugzilla.redhat.com/show_bug.cgi?id=860834
Signed-off-by: Gustavo Luiz Duarte <gustavold@linux.vnet.ibm.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Commit 5bc41db756 ("net/dhcp: Add explicit net_dhcp command")
introduced the new command "net_dhcp", which (for now) is an alias for
the existing "net_bootp". Unfortunately the TEXI documentation was not
adjusted accordingly.
Rename the existing paragraph about net_bootp to read net_dhcp instead,
and make the net_bootp stanza point to this new command.
On the way add the newly parsed TFTP_SERVER_NAME and BOOTFILE_NAME
packets to the list of supported DHCP options.
Fixes bug: https://savannah.gnu.org/bugs/?56725
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The win32-loader package relies on the hosted netboot debian-installer
files.
The grubx64.efi file is located at
https://deb.deb.debian.org/debian/dists/stable/main/installer-amd64/current/images/netboot/gtk/debian-installer/amd64/grubx64.efi
and originates from the grub2 source package.
This grubx64.efi file includes the preconfigured prefix:
($root)debian-installer/amd64/grub.
This prefix lacks the leading / in front of debian-installer. Therefore
no grub.cfg file located on a local storage device can be accessed via
this preconfigured prefix.
The normal network boot image uses ($root)/grub as its prefix. As a
stopgap the win32-loader package (experimental) transforms the above
mentioned grubx64.efi file into a normal network boot image (also known
as grubnetx64.efi.signed of the grub-efi-amd64-signed_1+2.02+dfsg1+20
package). As a consequence the grub.cfg file could be accessed at the
($root)/grub prefix.
Currently, gpt_offset is uninitialised when using a BIOS Boot Partition
but is used unconditionally inside save_blocklists. Instead, ensure it
is always initialised to 0 (note that there is already separate code to
do the equivalent adjustment after we call save_blocklists on this code
path).
This patch has been tested on a T5-2 LDOM.
Signed-off-by: James Clarke <jrtc27@jrtc27.com>
Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Eric Snowberg <eric.snowberg@oracle.com>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=4e75b2ae313b13b5bfb54cc5e5c53368d6eb2a08
Bug-Debian: https://bugs.debian.org/931969
Last-Update: 2019-08-06
Patch-Name: sparc64-fix-bios-boot-partition-support.patch
In this case, we need both the signed shim as /EFI/BOOT/BOOTXXX.EFI
and signed Grub as /EFI/BOOT/grubXXX.efi.
Also install the BOOTXXX.CSV into /EFI/debian, and FBXXX.EFI into
/EFI/BOOT/ so that it can work when needed (*iff* we're updating the
NVRAM).
[cjwatson: Refactored also_install_removable somewhat for brevity and so
that we're using consistent case-insensitive logic.]
Bug-Debian: https://bugs.debian.org/930531
Last-Update: 2019-06-14
Patch-Name: grub-install-removable-shim.patch
Some UEFI firmware is easily provoked into running out of space in its
variable storage. This is usually due to certain kernel drivers (e.g.
pstore), but regardless of the cause it can cause grub-install to fail
because it currently asks efibootmgr to delete and re-add entries, and
the deletion often doesn't result in an immediate garbage collection.
Writing variables frequently also increases wear on the NVRAM which may
have limited write cycles. For these reasons, it's desirable to find a
way to minimise writes while still allowing grub-install to ensure that
a suitable boot entry exists.
Unfortunately, efibootmgr doesn't offer an interface that would let
grub-install do this. It doesn't in general make very much effort to
minimise writes; it doesn't allow modifying an existing Boot* variable
entry, except in certain limited ways; and current versions don't have a
way to export the expected variable data so that grub-install can
compare it to the current data. While it would be possible (and perhaps
desirable?) to add at least some of this to efibootmgr, that would still
leave the problem that there isn't a good upstreamable way for
grub-install to guarantee that it has a new enough version of
efibootmgr. In any case, it's cumbersome and slow for grub-install to
have to fork efibootmgr to get things done.
Fortunately, a few years ago Peter Jones helpfully factored out a
substantial part of efibootmgr to the efivar and efiboot libraries, and
so it's now possible to have grub-install use those directly. We still
have to use some code from efibootmgr, but much less than would
previously have been necessary.
grub-install now reuses existing boot entries where possible, and avoids
writing to variables when the new contents are the same as the old
contents. In the common upgrade case where nothing needs to change, it
no longer writes to NVRAM at all. It's also now slightly faster, since
using libefivar is faster than forking efibootmgr.
Fixes Debian bug #891434.
Signed-off-by: Colin Watson <cjwatson@ubuntu.com>
Bug-Debian: https://bugs.debian.org/891434
Forwarded: https://lists.gnu.org/archive/html/grub-devel/2019-03/msg00119.html
Last-Update: 2019-03-23
Patch-Name: efi-variable-storage-minimise-writes.patch
On full-encrypted systems, including /boot, the current code omits
cryptodisk commands needed to open the drives if Secure Boot is enabled.
This prevents grub2 from reading any further configuration residing on
the encrypted disk.
This patch fixes this issue by adding the needed "cryptomount" commands in
the load.cfg file that is then copied in the EFI partition.
Bug-Debian: https://bugs.debian.org/917117
Last-Update: 2019-02-10
Patch-Name: uefi-secure-boot-cryptomount.patch
The change in 0c62a5b2 caused at_keyboard to fail on some
machines. Immediately initializing the keyboard in the module init if
the keyboard is ready makes the problem go away.
Bug-Debian: https://bugs.debian.org/741464
Last-Update: 2019-02-09
Patch-Name: at_keyboard-module-init.patch
These don't work with and aren't needed by dynamically-loaded
completions.
Bug-Debian: https://bugs.debian.org/912852
Forwarded: no
Last-Update: 2018-11-16
Patch-Name: bash-completion-drop-have-checks.patch
grub currently copies the entire boot_params, which includes setting
sentinel byte to 0xff, which triggers sanitize_boot_params in the kernel
which in turn clears various boot_params variables, including the
indication that the bootloader chain is verified and thus the kernel
disables lockdown mode. According to the information on the Fedora bug
tracker, only the information from byte 0x1f1 is necessary, so start
copying from there instead.
Author: Luca Boccassi <bluca@debian.org>
Bug-Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1418360
Forwarded: no
Patch-Name: fix-lockdown.patch
