Merge ~mfo/grub:lp1965983 into ~ubuntu-core-dev/grub/+git/ubuntu:master

[Mauricio Faria de Oliveira]

Hi Julian,

This MR is just MR [1] modified to edit the original patch instead of adding a fixup patch
(per our IRC chat last Thursday).

[1] https://code.launchpad.net/~arbell/grub/+git/grub/+merge/417575

[Mauricio Faria de Oliveira (mfo)]

The backports for stable releases Jammy and Focal for this MR
(LP#1965983) are batched in branches of the Xen MR (LP#1987567).

https://code.launchpad.net/~mfo/grub/+git/grub/+ref/lp1987567-jammy
https://code.launchpad.net/~mfo/grub/+git/grub/+ref/lp1987567-focal

Unmerged commits

57c233f... by Mauricio Faria de Oliveira on 2022-08-27

Fix for ZFS snapshots without etc directory

In the situation where ZFS snapshots do not contain a .../etc directory,
the generation of /b/g/grub.cfg silently fails, providing no "linux"
kernel lines in the /b/g/grub.cfg file.

This patch prevents this type of failure from occurring.

This issue is especially apparent on systems running in FIPS mode
with ZFS boot+root pools.

Source: https://code.launchpad.net/~arbell/grub/+git/grub/+merge/417575

LP: #1965983
Thanks: Adam R Bell <email address hidden>

Signed-off-by: Mauricio Faria de Oliveira <email address hidden>

47a3d1d... by Mauricio Faria de Oliveira on 2022-08-24

linux_xen: Properly handle multiple initrd files (LP: #1987567)

- d/p/linux_xen-Properly-load-multiple-initrd-files.patch
- d/p/linux_xen-Properly-order-multiple-initrd-files.patch

Gbp-Dch: Full

c10b7a6... by Chris Coulson on 2022-06-28

Build grub2-unsigned packages with xz compression

1f2dc0b... by Chris Coulson on 2022-06-08

releasing package grub2 version 2.06-2ubuntu9

b40b1eb... by Chris Coulson on 2022-06-08

Forward port the fix for LP: #1930742 and make it conditional (xenial/bionic only)

6fb4229... by Chris Coulson on 2022-06-08

Make the grub2/no_efi_extra_removable setting work correctly

7135177... by Chris Coulson on 2022-06-08

forward port fix for LP: #1926748

1d5cd8e... by Chris Coulson on 2022-05-18

Fix various security issues

aa271d1... by dann frazier on 2022-04-15

releasing package grub2 version 2.06-2ubuntu7

c411c65... by Heinrich Schuchardt on 2022-04-13

Disable LOAD FILE2 protocol for initrd on ARM

RISC-V cannot load the initrd without the LOAD FILE2 protocol.

Currently the LOAD FILE2 protocol does not work with PXE due to a preboot
hook invoking grub_net_fini_hw().

So let's disable this for ARM until a solution has been agreed on with
upstream.

Signed-off-by: Heinrich Schuchardt <email address hidden>

diff --git a/ChangeLog b/ChangeLog
index ba90478..434754f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,5281 @@
[phone]  Daniel Kiper  <[e-mail]>
+
+	Release 2.06
+
[phone]  Daniel Kiper  <[e-mail]>
+
+	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
+
[phone]  Daniel Kiper  <[e-mail]>
+
+	MAINTAINERS: Add MAINTAINERS file
+	The MAINTAINERS file provides basic information about the GRUB project
+	and its maintainers.
+
[phone]  Dimitri John Ledkov  <[e-mail]>
+
+	grub-install: Add backup and restore
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Dimitri John Ledkov  <[e-mail]>
+
+	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)
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Jan (janneke) Nieuwenhuizen  <[e-mail]>
+
+	lib/i386/relocator64: Build fixes for i386
+	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
+
+	   ./pre-inst-env guix build --system=i686-linux --target=i586-pc-gnu grub
+
+	or install an x86 cross-build environment on x86-linux (32-bit!) and
+	configure to cross build and make, e.g., do something like
+
+	    ./configure \
+	       CC_FOR_BUILD=gcc \
+	       --build=i686-unknown-linux-gnu \
+	       --host=i586-pc-gnu
+	    make
+
+	Additionally, remove a line with redundant spaces.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	fs/xfs: Add needsrepair incompat feature support
+	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 <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Carlos Maiolino  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Carlos Maiolino  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	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 <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Tianjia Zhang  <[e-mail]>
+
+	kern/efi/sb: Remove duplicate efi_shim_lock_guid variable
+	The efi_shim_lock_guid local variable and shim_lock_guid global variable
+	have the same GUID value. Only the latter is retained.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	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 <[e-mail]>
+	Tested-by: John Paul Adrian Glaubitz <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Kiper  <[e-mail]>
+
+	term/terminfo: Fix the terminfo command help and documentation
+	Additionally, fix the terminfo spelling mistake in
+	the GRUB development documentation.
+
+	Reviewed-by: Javier Martinez Canillas <[e-mail]>
+
[phone]  Daniel Kiper  <[e-mail]>
+
+	i18n: Align N_() formatting with the rest of GRUB code
+	Reviewed-by: Javier Martinez Canillas <[e-mail]>
+
[phone]  Daniel Kiper  <[e-mail]>
+
+	i18n: Format large integers before the translation message - take 2
+	This is an additional fix which has been missing from the commit 837fe48de
+	(i18n: Format large integers before the translation message).
+
+	Reviewed-by: Javier Martinez Canillas <[e-mail]>
+
[phone]  Miguel Ángel Arruga Vivas  <[e-mail]>
+
+	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.
+
+	[1] https://www.gnu.org/software/gettext/manual/html_node/Preparing-Strings.html#No-string-concatenation
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	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
+
+	  grub_mul(dst->mode_info->bytes_per_pixel, width, &rowskip)
+
+	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)
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	docs: Conform badmem and cutmem description indentations with other commands
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
+	docs: Add note to cryptomount that UUIDs should be specified without dashes
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Aru Sahni  <[e-mail]>
+
+	templates: Fix user-facing typo with an incorrect use of "it's"
+	Since the possessive form of "it" is being used, the apostrophe must be omitted.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Colin Watson  <[e-mail]>
+
+	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.
+
+	  DOWN: obj/i386-pc/grub-core/kernel.img (31740 > 31708) - change: -32
+	  DOWN: i386-pc core image (biosdisk ext2 part_msdos) (27453 > 27452) - change: -1
+	  DOWN: i386-pc core image (biosdisk ext2 part_msdos diskfilter mdraid09) (32367 > 32359) - change: -8
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	usb/usbhub: Use GRUB_USB_MAX_CONF macro instead of literal in hub for maximum configs
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Drake  <[e-mail]>
+
+	fs/minix: Avoid mistakenly probing ext2 filesystems
+	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:
+
+	  https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/518582
+
+	This was fixed in util-linux by having the MINIX code check for the
+	ext2 magic. Do the same here.
+
+	Reviewed-by: Derek Foreman <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Kiper  <[e-mail]>
+
+	Release 2.06~rc1
+
[phone]  Ard Biesheuvel  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	style: Format string macro should have a space between quotes
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	grub/err: Do compile-time format string checking on grub_error()
+	This should help prevent format string errors and thus improve the quality
+	of error reporting.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	fs/hfsplus: Use format code PRIuGRUB_UINT64_T for 64-bit typed fileblock in grub_error()
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	disk/ata: Use format code PRIxGRUB_UINT64_T for 64-bit uint argument in grub_error()
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	loader/i386/pc/linux: Use PRI* macros to get correct format string code across architectures
+	Also remove casting of format string args so that the architecture dependent
+	type is preserved.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	grub_error: Use format code PRIuGRUB_SIZE for variables of type grub_size_t
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	video/bochs: grub_error() format string add missing format code
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	parttool/msdospart: grub_error() missing format string argument
+	Its obvious from the error message that the variable named "type" was
+	accidentally omitted.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	misc: Format string for grub_error() should be a literal
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Philip Müller  <[e-mail]>
+
+	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 <[e-mail]>
+	Reported-by: Lennart Sorensen <[e-mail]>
+	Reported-by: John Paul Adrian Glaubitz <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Michael Chang  <[e-mail]>
+
+	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)
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	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.
+
+	Acked-by: Paul Menzel <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Yi Zhao  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Tianjia Zhang  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Tianjia Zhang  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Heinrich Schuchardt  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Heinrich Schuchardt  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Petr Vorel  <[e-mail]>
+
+	docs/luks2: Mention key derivation function support
+	To give users hint why Argon2, the default in cryptsetup for LUKS2, does
+	not work.
+
+	Acked-by: Paul Menzel <[e-mail]>
+	Reviewed-by: Patrick Steinhardt <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Derek Foreman  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Marco A Benatto  <[e-mail]>
+
+	kern/mm: Fix grub_debug_calloc() compilation error
+	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)
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Alex Burmashev  <[e-mail]>
+
+	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 (<[e-mail]>, https://twitter.com/NyankoSec),
+	             working with SSD Secure Disclosure
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Thomas Frauendorfer | Miray Software  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Thomas Frauendorfer | Miray Software  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Thomas Frauendorfer | Miray Software  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Thomas Frauendorfer | Miray Software  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Dimitri John Ledkov  <[e-mail]>
+
+	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 <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Dimitri John Ledkov  <[e-mail]>
+
+	grub-install-common: Add --sbat option
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	util/mkimage: Remove unused code to add BSS section
+	The code is compiled out so there is no reason to keep it.
+
+	Additionally, don't set bss_size field since we do not add a BSS section.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Chris Coulson  <[e-mail]>
+
+	kern/efi: Add initial stack protector implementation
+	It works only on UEFI platforms but can be quite easily extended to
+	others architectures and platforms if needed.
+
+	Reviewed-by: Marco A Benatto <[e-mail]>
+	Reviewed-by: Javier Martinez Canillas <[e-mail]>
+
[phone]  Chris Coulson  <[e-mail]>
+
+	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 <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Chris Coulson  <[e-mail]>
+
+	kern/buffer: Add variable sized heap buffer
+	Add a new variable sized heap buffer type (grub_buffer_t) with simple
+	operations for appending data, accessing the data and maintaining
+	a read cursor.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Chris Coulson  <[e-mail]>
+
+	kern/parser: Refactor grub_parser_split_cmdline() cleanup
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Chris Coulson  <[e-mail]>
+
+	kern/parser: Introduce terminate_arg() helper
+	process_char() and grub_parser_split_cmdline() use similar code for
+	terminating the most recent argument. Add a helper function for this.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Chris Coulson  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Chris Coulson  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	fs/btrfs: Squash some uninitialized reads
+	We need to check errors before calling into a function that uses the result.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	fs/btrfs: Validate the number of stripes/parities in RAID5/6
+	This prevents a divide by zero if nstripes == nparities, and
+	also prevents propagation of invalid values if nstripes ends up
+	less than nparities.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	disk/lvm: Do not allow a LV to be it's own segment's node's LV
+	This prevents infinite recursion in the diskfilter verification code.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	disk/lvm: Do not overread metadata
+	We could reach the end of valid metadata and not realize, leading to
+	some buffer overreads. Check if we have reached the end and bail.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	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
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	io/gzio: Zero gzio->tl/td in init_dynamic_block() if huft_build() fails
+	If huft_build() fails, gzio->tl or gzio->td could contain pointers that
+	are no longer valid. Zero them out.
+
+	This prevents a double free when grub_gzio_close() comes through and
+	attempts to free them again.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	io/gzio: Catch missing values in huft_build() and bail
+	In huft_build(), "v" is a table of values in order of bit length.
+	The code later (when setting up table entries in "r") assumes that all
+	elements of this array corresponding to a code are initialized and less
+	than N_MAX. However, it doesn't enforce this.
+
+	With sufficiently manipulated inputs (e.g. from fuzzing), there can be
+	elements of "v" that are not filled. Therefore a lookup into "e" or "d"
+	will use an uninitialized value. This can lead to an invalid/OOB read on
+	those values, often leading to a crash.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	io/gzio: Add init_dynamic_block() clean up if unpacking codes fails
+	init_dynamic_block() didn't clean up gzio->tl and td in some error
+	paths. This left td pointing to part of tl. Then in grub_gzio_close(),
+	when tl was freed the storage for td would also be freed. The code then
+	attempts to free td explicitly, performing a UAF and then a double free.
+
+	Explicitly clean up tl and td in the error paths.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	io/gzio: Bail if gzio->tl/td is NULL
+	This is an ugly fix that doesn't address why gzio->tl comes to be NULL.
+	However, it seems to be sufficient to patch up a bunch of NULL derefs.
+
+	It would be good to revisit this in future and see if we can have
+	a cleaner solution that addresses some of the causes of the unexpected
+	NULL pointers.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	fs/nilfs2: Properly bail on errors in grub_nilfs2_btree_node_lookup()
+	We just introduced an error return in grub_nilfs2_btree_node_lookup().
+	Make sure the callers catch it.
+
+	At the same time, make sure that grub_nilfs2_btree_node_lookup() always
+	inits the index pointer passed to it.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	fs/nilfs2: Don't search children if provided number is too large
+	NILFS2 reads the number of children a node has from the node. Unfortunately,
+	that's not trustworthy. Check if it's beyond what the filesystem permits and
+	reject it if so.
+
+	This blocks some OOB reads. I'm not sure how controllable the read is and what
+	could be done with invalidly read data later on.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	fs/nilfs2: Reject too-large keys
+	NILFS2 has up to 7 keys, per the data structure. Do not permit array
+	indices in excess of that.
+
+	This catches some OOB reads. I don't know how controllable the invalidly
+	read data is or if that could be used later in the program.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	fs/jfs: Catch infinite recursion
+	It's possible with a fuzzed filesystem for JFS to keep getblk()-ing
+	the same data over and over again, leading to stack exhaustion.
+
+	Check if we'd be calling the function with exactly the same data as
+	was passed in, and if so abort.
+
+	I'm not sure what the performance impact of this is and am open to
+	better ideas.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	fs/jfs: Limit the extents that getblk() can consider
+	getblk() implicitly trusts that treehead->count is an accurate count of
+	the number of extents. However, that value is read from disk and is not
+	trustworthy, leading to OOB reads and crashes. I am not sure to what
+	extent the data read from OOB can influence subsequent program execution.
+
+	Require callers to pass in the maximum number of extents for which
+	they have storage.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	fs/jfs: Do not move to leaf level if name length is negative
+	Fuzzing JFS revealed crashes where a negative number would be passed
+	to le_to_cpu16_copy(). There it would be cast to a large positive number
+	and the copy would read and write off the end of the respective buffers.
+
+	Catch this at the top as well as the bottom of the loop.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	fs/sfs: Fix over-read of root object name
+	There's a read of the name of the root object that assumes that the name
+	is nul-terminated within the root block. This isn't guaranteed - it seems
+	SFS would require you to read multiple blocks to get a full name in general,
+	but maybe that doesn't apply to the root object.
+
+	Either way, figure out how much space is left in the root block and don't
+	over-read it. This fixes some OOB reads.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	fs/hfs: Disable under lockdown
+	HFS has issues such as infinite mutual recursion that are simply too
+	complex to fix for such a legacy format. So simply do not permit
+	it to be loaded under lockdown.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	fs/hfsplus: Don't use uninitialized data on corrupt filesystems
+	Valgrind identified the following use of uninitialized data:
+
+	  ==2782220== Conditional jump or move depends on uninitialised value(s)
+	  ==2782220==    at 0x42B364: grub_hfsplus_btree_search (hfsplus.c:566)
+	  ==2782220==    by 0x42B21D: grub_hfsplus_read_block (hfsplus.c:185)
+	  ==2782220==    by 0x42A693: grub_fshelp_read_file (fshelp.c:386)
+	  ==2782220==    by 0x42C598: grub_hfsplus_read_file (hfsplus.c:219)
+	  ==2782220==    by 0x42C598: grub_hfsplus_mount (hfsplus.c:330)
+	  ==2782220==    by 0x42B8C5: grub_hfsplus_dir (hfsplus.c:958)
+	  ==2782220==    by 0x4C1AE6: grub_fs_probe (fs.c:73)
+	  ==2782220==    by 0x407C94: grub_ls_list_files (ls.c:186)
+	  ==2782220==    by 0x407C94: grub_cmd_ls (ls.c:284)
+	  ==2782220==    by 0x4D7130: grub_extcmd_dispatcher (extcmd.c:55)
+	  ==2782220==    by 0x4045A6: execute_command (grub-fstest.c:59)
+	  ==2782220==    by 0x4045A6: fstest (grub-fstest.c:433)
+	  ==2782220==    by 0x4045A6: main (grub-fstest.c:772)
+	  ==2782220==  Uninitialised value was created by a heap allocation
+	  ==2782220==    at 0x483C7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
+	  ==2782220==    by 0x4C0305: grub_malloc (mm.c:42)
+	  ==2782220==    by 0x42C21D: grub_hfsplus_mount (hfsplus.c:239)
+	  ==2782220==    by 0x42B8C5: grub_hfsplus_dir (hfsplus.c:958)
+	  ==2782220==    by 0x4C1AE6: grub_fs_probe (fs.c:73)
+	  ==2782220==    by 0x407C94: grub_ls_list_files (ls.c:186)
+	  ==2782220==    by 0x407C94: grub_cmd_ls (ls.c:284)
+	  ==2782220==    by 0x4D7130: grub_extcmd_dispatcher (extcmd.c:55)
+	  ==2782220==    by 0x4045A6: execute_command (grub-fstest.c:59)
+	  ==2782220==    by 0x4045A6: fstest (grub-fstest.c:433)
+	  ==2782220==    by 0x4045A6: main (grub-fstest.c:772)
+
+	This happens when the process of reading the catalog file goes sufficiently
+	wrong that there's an attempt to read the extent overflow file, which has
+	not yet been loaded. Keep track of when the extent overflow file is
+	fully loaded and refuse to use it before then.
+
+	The load valgrind doesn't like is btree->nodesize, and that's then used
+	to allocate a data structure. It looks like there are subsequently a lot
+	of reads based on that pointer so OOB reads are likely, and indeed crashes
+	(albeit difficult-to-replicate ones) have been observed in fuzzing.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	fs/hfsplus: Don't fetch a key beyond the end of the node
+	Otherwise you get a wild pointer, leading to a bunch of invalid reads.
+	Check it falls inside the given node.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	fs/fshelp: Catch impermissibly large block sizes in read helper
+	A fuzzed HFS+ filesystem had log2blocksize = 22. This gave
+	log2blocksize + GRUB_DISK_SECTOR_BITS = 31. 1 << 31 = 0x80000000,
+	which is -1 as an int. This caused some wacky behavior later on in
+	the function, leading to out-of-bounds writes on the destination buffer.
+
+	Catch log2blocksize + GRUB_DISK_SECTOR_BITS >= 31. We could be stricter,
+	but this is the minimum that will prevent integer size weirdness.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	term/gfxterm: Don't set up a font with glyphs that are too big
+	Catch the case where we have a font so big that it causes the number of
+	rows or columns to be 0. Currently we continue and allocate a
+	virtual_screen.text_buffer of size 0. We then try to use that for glpyhs
+	and things go badly.
+
+	On the emu platform, malloc() may give us a valid pointer, in which case
+	we'll access heap memory which we shouldn't. Alternatively, it may give us
+	NULL, in which case we'll crash. For other platforms, if I understand
+	grub_memalign() correctly, we will receive a valid but small allocation
+	that we will very likely later overrun.
+
+	Prevent the creation of a virtual screen that isn't at least 40 cols
+	by 12 rows. This is arbitrary, but it seems that if your width or height
+	is half a standard 80x24 terminal, you're probably going to struggle to
+	read anything anyway.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	video/readers/jpeg: Don't decode data before start of stream
+	When a start of stream marker is encountered, we call grub_jpeg_decode_sos()
+	which allocates space for a bitmap.
+
+	When a restart marker is encountered, we call grub_jpeg_decode_data() which
+	then fills in that bitmap.
+
+	If we get a restart marker before the start of stream marker, we will
+	attempt to write to a bitmap_ptr that hasn't been allocated. Catch this
+	and bail out. This fixes an attempt to write to NULL.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	video/readers/jpeg: Catch OOB reads/writes in grub_jpeg_decode_du()
+	The key line is:
+
+	  du[jpeg_zigzag_order[pos]] = val * (int) data->quan_table[qt][pos];
+
+	jpeg_zigzag_order is grub_uint8_t[64].
+
+	I don't understand JPEG decoders quite well enough to explain what's
+	going on here. However, I observe sometimes pos=64, which leads to an
+	OOB read of the jpeg_zigzag_order global then an OOB write to du.
+	That leads to various unpleasant memory corruption conditions.
+
+	Catch where pos >= ARRAY_SIZE(jpeg_zigzag_order) and bail.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	video/readers/jpeg: Catch files with unsupported quantization or Huffman tables
+	Our decoder only supports 2 quantization tables. If a file asks for
+	a quantization table with index > 1, reject it.
+
+	Similarly, our decoder only supports 4 Huffman tables. If a file asks
+	for a Huffman table with index > 3, reject it.
+
+	This fixes some out of bounds reads. It's not clear what degree of control
+	over subsequent execution could be gained by someone who can carefully
+	set up the contents of memory before loading an invalid JPEG file.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	kern/misc: Always set *end in grub_strtoull()
+	Currently, if there is an error in grub_strtoull(), *end is not set.
+	This differs from the usual behavior of strtoull(), and also means that
+	some callers may use an uninitialized value for *end.
+
+	Set *end unconditionally.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	commands/menuentry: Fix quoting in setparams_prefix()
+	Commit 9acdcbf32542 (use single quotes in menuentry setparams command)
+	says that expressing a quoted single quote will require 3 characters. It
+	actually requires (and always did require!) 4 characters:
+
+	  str: a'b => a'\''b
+	  len:  3  => 6 (2 for the letters + 4 for the quote)
+
+	This leads to not allocating enough memory and thus out of bounds writes
+	that have been observed to cause heap corruption.
+
+	Allocate 4 bytes for each single quote.
+
+	Commit 22e7dbb2bb81 (Fix quoting in legacy parser.) does the same
+	quoting, but it adds 3 as extra overhead on top of the single byte that
+	the quote already needs. So it's correct.
+
+	Fixes: 9acdcbf32542 (use single quotes in menuentry setparams command)
+	Fixes: CVE-2021-20233
+
+	Reported-by: Daniel Axtens <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	script/execute: Don't crash on a "for" loop with no items
+	The following crashes the parser:
+
+	  for x in; do
+	  0
+	  done
+
+	This is because grub_script_arglist_to_argv() doesn't consider the
+	possibility that arglist is NULL. Catch that explicitly.
+
+	This avoids a NULL pointer dereference.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	lib/arg: Block repeated short options that require an argument
+	Fuzzing found the following crash:
+
+	  search -hhhhhhhhhhhhhf
+
+	We didn't allocate enough option space for 13 hints because the
+	allocation code counts the number of discrete arguments (i.e. argc).
+	However, the shortopt parsing code will happily keep processing
+	a combination of short options without checking if those short
+	options require an argument. This means you can easily end writing
+	past the allocated option space.
+
+	This fixes a OOB write which can cause heap corruption.
+
+	Fixes: CVE-2021-20225
+
+	Reported-by: Daniel Axtens <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	script/execute: Avoid crash when using "$#" outside a function scope
+	"$#" represents the number of arguments to a function. It is only
+	defined in a function scope, where "scope" is non-NULL. Currently,
+	if we attempt to evaluate "$#" outside a function scope, "scope" will
+	be NULL and we will crash with a NULL pointer dereference.
+
+	Do not attempt to count arguments for "$#" if "scope" is NULL. This
+	will result in "$#" being interpreted as an empty string if evaluated
+	outside a function scope.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	commands/ls: Require device_name is not NULL before printing
+	This can be triggered with:
+	  ls -l (0 0*)
+	and causes a NULL deref in grub_normal_print_device_info().
+
+	I'm not sure if there's any implication with the IEEE 1275 platform.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	script/execute: Fix NULL dereference in grub_script_execute_cmdline()
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	util/glue-efi: Fix incorrect use of a possibly negative value
+	It is possible for the ftell() function to return a negative value,
+	although it is fairly unlikely here, we should be checking for
+	a negative value before we assign it to an unsigned value.
+
+	Fixes: CID 73744
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	util/grub-editenv: Fix incorrect casting of a signed value
+	The return value of ftell() may be negative (-1) on error. While it is
+	probably unlikely to occur, we should not blindly cast to an unsigned
+	value without first testing that it is not negative.
+
+	Fixes: CID 73856
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Kiper  <[e-mail]>
+
+	util/grub-install: Fix NULL pointer dereferences
+	Two grub_device_open() calls does not have associated NULL checks
+	for returned values. Fix that and appease the Coverity.
+
+	Fixes: CID 314583
+
+	Reviewed-by: Javier Martinez Canillas <[e-mail]>
+
[phone]  Paulo Flabiano Smorigo  <[e-mail]>
+
+	loader/xnu: Check if pointer is NULL before using it
+	Fixes: CID 73654
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Marco A Benatto  <[e-mail]>
+
+	loader/xnu: Free driverkey data when an error is detected in grub_xnu_writetree_toheap()
+	... to avoid memory leaks.
+
+	Fixes: CID 96640
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	loader/xnu: Fix memory leak
+	The code here is finished with the memory stored in name, but it only
+	frees it if there curvalue is valid, while it could actually free it
+	regardless.
+
+	The fix is a simple relocation of the grub_free() to before the test
+	of curvalue.
+
+	Fixes: CID 96646
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	loader/bsd: Check for NULL arg up-front
+	The code in the next block suggests that it is possible for .set to be
+	true but .arg may still be NULL.
+
+	This code assumes that it is never NULL, yet later is testing if it is
+	NULL - that is inconsistent.
+
+	So we should check first if .arg is not NULL, and remove this check that
+	is being flagged by Coverity since it is no longer required.
+
+	Fixes: CID 292471
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	gfxmenu/gui_list: Remove code that coverity is flagging as dead
+	The test of value for NULL before calling grub_strdup() is not required,
+	since the if condition prior to this has already tested for value being
+	NULL and cannot reach this code if it is.
+
+	Fixes: CID 73659
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	video/readers/jpeg: Test for an invalid next marker reference from a jpeg file
+	While it may never happen, and potentially could be caught at the end of
+	the function, it is worth checking up front for a bad reference to the
+	next marker just in case of a maliciously crafted file being provided.
+
+	Fixes: CID 73694
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	video/fb/video_fb: Fix possible integer overflow
+	It is minimal possibility that the values being used here will overflow.
+	So, change the code to use the safemath function grub_mul() to ensure
+	that doesn't happen.
+
+	Fixes: CID 73761
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	video/fb/video_fb: Fix multiple integer overflows
+	The calculation of the unsigned 64-bit value is being generated by
+	multiplying 2, signed or unsigned, 32-bit integers which may overflow
+	before promotion to unsigned 64-bit. Fix all of them.
+
+	Fixes: CID 73703, CID 73767, CID 73833
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	video/fb/fbfill: Fix potential integer overflow
+	The multiplication of 2 unsigned 32-bit integers may overflow before
+	promotion to unsigned 64-bit. We should ensure that the multiplication
+	is done with overflow detection. Additionally, use grub_sub() for
+	subtraction.
+
+	Fixes: CID 73640, CID 73697, CID 73702, CID 73823
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	video/efi_gop: Remove unnecessary return value of grub_video_gop_fill_mode_info()
+	The return value of grub_video_gop_fill_mode_info() is never able to be
+	anything other than GRUB_ERR_NONE. So, rather than continue to return
+	a value and checking it each time, it is more correct to redefine the
+	function to not return anything and remove checks of its return value
+	altogether.
+
+	Fixes: CID 96701
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	commands/probe: Fix a resource leak when probing disks
+	Every other return statement in this code is calling grub_device_close()
+	to clean up dev before returning. This one should do that too.
+
+	Fixes: CID 292443
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Chris Coulson  <[e-mail]>
+
+	commands/hashsum: Fix a memory leak
+	check_list() uses grub_file_getline(), which allocates a buffer.
+	If the hash list file contains invalid lines, the function leaks
+	this buffer when it returns an error.
+
+	Fixes: CID 176635
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	normal/completion: Fix leaking of memory when processing a completion
+	It is possible for the code to reach the end of the function without
+	freeing the memory allocated to argv and argc still to be 0.
+
+	We should always call grub_free(argv). The grub_free() will handle
+	a NULL argument correctly if it reaches that code without the memory
+	being allocated.
+
+	Fixes: CID 96672
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	syslinux: Fix memory leak while parsing
+	In syslinux_parse_real() the 2 points where return is being called
+	didn't release the memory stored in buf which is no longer required.
+
+	Fixes: CID 176634
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	libgcrypt/mpi: Fix possible NULL dereference
+	The code in gcry_mpi_scan() assumes that buffer is not NULL, but there
+	is no explicit check for that, so we add one.
+
+	Fixes: CID 73757
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	libgcrypt/mpi: Fix possible unintended sign extension
+	The array of unsigned char gets promoted to a signed 32-bit int before
+	it is finally promoted to a size_t. There is the possibility that this
+	may result in the signed-bit being set for the intermediate signed
+	32-bit int. We should ensure that the promotion is to the correct type
+	before we bitwise-OR the values.
+
+	Fixes: CID 96697
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	affs: Fix memory leaks
+	The node structure reference is being allocated but not freed if it
+	reaches the end of the function. If any of the hooks had returned
+	a non-zero value, then node would have been copied in to the context
+	reference, but otherwise node is not stored and should be freed.
+
+	Similarly, the call to grub_affs_create_node() replaces the allocated
+	memory in node with a newly allocated structure, leaking the existing
+	memory pointed by node.
+
+	Finally, when dir->parent is set, then we again replace node with newly
+	allocated memory, which seems unnecessary when we copy in the values
+	from dir->parent immediately after.
+
+	Fixes: CID 73759
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	zfsinfo: Correct a check for error allocating memory
+	While arguably the check for grub_errno is correct, we should really be
+	checking the return value from the function since it is always possible
+	that grub_errno was set elsewhere, making this code behave incorrectly.
+
+	Fixes: CID 73668
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	zfs: Fix possible integer overflows
+	In all cases the problem is that the value being acted upon by
+	a left-shift is a 32-bit number which is then being used in the
+	context of a 64-bit number.
+
+	To avoid overflow we ensure that the number being shifted is 64-bit
+	before the shift is done.
+
+	Fixes: CID 73684, CID 73695, CID 73764
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Paulo Flabiano Smorigo  <[e-mail]>
+
+	zfs: Fix resource leaks while constructing path
+	There are several exit points in dnode_get_path() that are causing possible
+	memory leaks.
+
+	In the while(1) the correct exit mechanism should not be to do a direct return,
+	but to instead break out of the loop, setting err first if it is not already set.
+
+	The reason behind this is that the dnode_path is a linked list, and while doing
+	through this loop, it is being allocated and built up - the only way to
+	correctly unravel it is to traverse it, which is what is being done at the end
+	of the function outside of the loop.
+
+	Several of the existing exit points correctly did a break, but not all so this
+	change makes that more consistent and should resolve the leaking of memory as
+	found by Coverity.
+
+	Fixes: CID 73741
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	zfs: Fix possible negative shift operation
+	While it is possible for the return value from zfs_log2() to be zero
+	(0), it is quite unlikely, given that the previous assignment to blksz
+	is shifted up by SPA_MINBLOCKSHIFT (9) before 9 is subtracted at the
+	assignment to epbs.
+
+	But, while unlikely during a normal operation, it may be that a carefully
+	crafted ZFS filesystem could result in a zero (0) value to the
+	dn_datalbkszsec field, which means that the shift left does nothing
+	and assigns zero (0) to blksz, resulting in a negative epbs value.
+
+	Fixes: CID 73608
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	hfsplus: Check that the volume name length is valid
+	HFS+ documentation suggests that the maximum filename and volume name is
+	255 Unicode characters in length.
+
+	So, when converting from big-endian to little-endian, we should ensure
+	that the name of the volume has a length that is between 0 and 255,
+	inclusive.
+
+	Fixes: CID 73641
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	disk/cryptodisk: Fix potential integer overflow
+	The encrypt and decrypt functions expect a grub_size_t. So, we need to
+	ensure that the constant bit shift is using grub_size_t rather than
+	unsigned int when it is performing the shift.
+
+	Fixes: CID 307788
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	disk/ldm: Fix memory leak on uninserted lv references
+	The problem here is that the memory allocated to the variable lv is not
+	yet inserted into the list that is being processed at the label fail2.
+
+	As we can already see at line 342, which correctly frees lv before going
+	to fail2, we should also be doing that at these earlier jumps to fail2.
+
+	Fixes: CID 73824
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Paulo Flabiano Smorigo  <[e-mail]>
+
+	disk/ldm: If failed then free vg variable too
+	Fixes: CID 73809
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Marco A Benatto  <[e-mail]>
+
+	disk/ldm: Make sure comp data is freed before exiting from make_vg()
+	Several error handling paths in make_vg() do not free comp data before
+	jumping to fail2 label and returning from the function. This will leak
+	memory. So, let's fix all issues of that kind.
+
+	Fixes: CID 73804
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	kern/partition: Check for NULL before dereferencing input string
+	There is the possibility that the value of str comes from an external
+	source and continuing to use it before ever checking its validity is
+	wrong. So, needs fixing.
+
+	Additionally, drop unneeded part initialization.
+
+	Fixes: CID 292444
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	zstd: Initialize seq_t structure fully
+	While many compilers will initialize this to zero, not all will, so it
+	is better to be sure that fields not being explicitly set are at known
+	values, and there is code that checks this fields value elsewhere in the
+	code.
+
+	Fixes: CID 292440
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	io/lzopio: Resolve unnecessary self-assignment errors
+	These 2 assignments are unnecessary since they are just assigning
+	to themselves.
+
+	Fixes: CID 73643
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	gnulib/regcomp: Fix uninitialized re_token
+	This issue has been fixed in the latest version of gnulib, so to
+	maintain consistency, I've backported that change rather than doing
+	something different.
+
+	Fixes: CID 73828
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	gnulib/regexec: Fix possible null-dereference
+	It appears to be possible that the mctx->state_log field may be NULL,
+	and the name of this function, clean_state_log_if_needed(), suggests
+	that it should be checking that it is valid to be cleaned before
+	assuming that it does.
+
+	Fixes: CID 86720
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	gnulib/argp-help: Fix dereference of a possibly NULL state
+	All other instances of call to __argp_failure() where there is
+	a dgettext() call is first checking whether state is NULL before
+	attempting to dereference it to get the root_argp->argp_domain.
+
+	Fixes: CID 292436
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	gnulib/regcomp: Fix uninitialized token structure
+	The code is assuming that the value of br_token.constraint was
+	initialized to zero when it wasn't.
+
+	While some compilers will ensure that, not all do, so it is better to
+	fix this explicitly than leave it to chance.
+
+	Fixes: CID 73749
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	gnulib/regexec: Resolve unused variable
+	This is a really minor issue where a variable is being assigned to but
+	not checked before it is overwritten again.
+
+	The reason for this issue is that we are not building with DEBUG set and
+	this in turn means that the assert() that reads the value of the
+	variable match_last is being processed out.
+
+	The solution, move the assignment to match_last in to an ifdef DEBUG too.
+
+	Fixes: CID 292459
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	kern/efi/mm: Fix possible NULL pointer dereference
+	The model of grub_efi_get_memory_map() is that if memory_map is NULL,
+	then the purpose is to discover how much memory should be allocated to
+	it for the subsequent call.
+
+	The problem here is that with grub_efi_is_finished set to 1, there is no
+	check at all that the function is being called with a non-NULL memory_map.
+
+	While this MAY be true, we shouldn't assume it.
+
+	The solution to this is to behave as expected, and if memory_map is NULL,
+	then don't try to use it and allow memory_map_size to be filled in, and
+	return 0 as is done later in the code if the buffer is too small (or NULL).
+
+	Additionally, drop unneeded ret = 1.
+
+	Fixes: CID 96632
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	kern/efi: Fix memory leak on failure
+	Free the memory allocated to name before returning on failure.
+
+	Fixes: CID 296222
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	kern/parser: Fix resource leak if argc == 0
+	After processing the command-line yet arriving at the point where we are
+	setting argv, we are allocating memory, even if argc == 0, which makes
+	no sense since we never put anything into the allocated argv.
+
+	The solution is to simply return that we've successfully processed the
+	arguments but that argc == 0, and also ensure that argv is NULL when
+	we're not allocating anything in it.
+
+	There are only 2 callers of this function, and both are handling a zero
+	value in argc assuming nothing is allocated in argv.
+
+	Fixes: CID 96680
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	net/tftp: Fix dangling memory pointer
+	The static code analysis tool, Parfait, reported that the valid of
+	file->data was left referencing memory that was freed by the call to
+	grub_free(data) where data was initialized from file->data.
+
+	To ensure that there is no unintentional access to this memory
+	referenced by file->data we should set the pointer to NULL.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	net/net: Fix possible dereference to of a NULL pointer
+	It is always possible that grub_zalloc() could fail, so we should check for
+	a NULL return. Otherwise we run the risk of dereferencing a NULL pointer.
+
+	Fixes: CID 296221
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Darren Kenny  <[e-mail]>
+
+	mmap: Fix memory leak when iterating over mapped memory
+	When returning from grub_mmap_iterate() the memory allocated to present
+	is not being released causing it to leak.
+
+	Fixes: CID 96655
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	usb: Avoid possible out-of-bound accesses caused by malicious devices
+	The maximum number of configurations and interfaces are fixed but there is
+	no out-of-bound checking to prevent a malicious USB device to report large
+	values for these and cause accesses outside the arrays' memory.
+
+	Fixes: CVE-2020-25647
+
+	Reported-by: Joseph Tartaro <[e-mail]>
+	Reported-by: Ilja Van Sprundel <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	dl: Only allow unloading modules that are not dependencies
+	When a module is attempted to be removed its reference counter is always
+	decremented. This means that repeated rmmod invocations will cause the
+	module to be unloaded even if another module depends on it.
+
+	This may lead to a use-after-free scenario allowing an attacker to execute
+	arbitrary code and by-pass the UEFI Secure Boot protection.
+
+	While being there, add the extern keyword to some function declarations in
+	that header file.
+
+	Fixes: CVE-2020-25632
+
+	Reported-by: Chris Coulson <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	docs: Document the cutmem command
+	The command is not present in the docs/grub.texi user documentation.
+
+	Reported-by: Daniel Kiper <[e-mail]>
+	Reviewed-by: Javier Martinez Canillas <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	loader/xnu: Don't allow loading extension and packages when locked down
+	The shim_lock verifier validates the XNU kernels but no its extensions
+	and packages. Prevent these to be loaded when the GRUB is locked down.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	gdb: Restrict GDB access when locked down
+	The gdbstub* commands allow to start and control a GDB stub running on
+	local host that can be used to connect from a remote debugger. Restrict
+	this functionality when the GRUB is locked down.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	commands/hdparm: Restrict hdparm command when locked down
+	The command can be used to get/set ATA disk parameters. Some of these can
+	be dangerous since change the disk behavior. Restrict it when locked down.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	commands/setpci: Restrict setpci command when locked down
+	This command can set PCI devices register values, which makes it dangerous
+	in a locked down configuration. Restrict it so can't be used on this setup.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	commands: Restrict commands that can load BIOS or DT blobs when locked down
+	There are some more commands that should be restricted when the GRUB is
+	locked down. Following is the list of commands and reasons to restrict:
+
+	  * fakebios:   creates BIOS-like structures for backward compatibility with
+	                existing OSes. This should not be allowed when locked down.
+
+	  * loadbios:   reads a BIOS dump from storage and loads it. This action
+	                should not be allowed when locked down.
+
+	  * devicetree: loads a Device Tree blob and passes it to the OS. It replaces
+	                any Device Tree provided by the firmware. This also should
+	                not be allowed when locked down.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	mmap: Don't register cutmem and badram commands when lockdown is enforced
+	The cutmem and badram commands can be used to remove EFI memory regions
+	and potentially disable the UEFI Secure Boot. Prevent the commands to be
+	registered if the GRUB is locked down.
+
+	Fixes: CVE-2020-27779
+
+	Reported-by: Teddy Reed <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	acpi: Don't register the acpi command when locked down
+	The command is not allowed when lockdown is enforced. Otherwise an
+	attacker can instruct the GRUB to load an SSDT table to overwrite
+	the kernel lockdown configuration and later load and execute
+	unsigned code.
+
+	Fixes: CVE-2020-14372
+
+	Reported-by: Máté Kukri <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	efi: Use grub_is_lockdown() instead of hardcoding a disabled modules list
+	Now the GRUB can check if it has been locked down and this can be used to
+	prevent executing commands that can be utilized to circumvent the UEFI
+	Secure Boot mechanisms. So, instead of hardcoding a list of modules that
+	have to be disabled, prevent the usage of commands that can be dangerous.
+
+	This not only allows the commands to be disabled on other platforms, but
+	also properly separate the concerns. Since the shim_lock verifier logic
+	should be only about preventing to run untrusted binaries and not about
+	defining these kind of policies.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	efi: Lockdown the GRUB when the UEFI Secure Boot is enabled
+	If the UEFI Secure Boot is enabled then the GRUB must be locked down
+	to prevent executing code that can potentially be used to subvert its
+	verification mechanisms.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	kern/lockdown: Set a variable if the GRUB is locked down
+	It may be useful for scripts to determine whether the GRUB is locked
+	down or not. Add the lockdown variable which is set to "y" when the GRUB
+	is locked down.
+
+	Suggested-by: Dimitri John Ledkov <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	kern: Add lockdown support
+	When the GRUB starts on a secure boot platform, some commands can be
+	used to subvert the protections provided by the verification mechanism and
+	could lead to booting untrusted system.
+
+	To prevent that situation, allow GRUB to be locked down. That way the code
+	may check if GRUB has been locked down and further restrict the commands
+	that are registered or what subset of their functionality could be used.
+
+	The lockdown support adds the following components:
+
+	* The grub_lockdown() function which can be used to lockdown GRUB if,
+	  e.g., UEFI Secure Boot is enabled.
+
+	* The grub_is_lockdown() function which can be used to check if the GRUB
+	  was locked down.
+
+	* A verifier that flags OS kernels, the GRUB modules, Device Trees and ACPI
+	  tables as GRUB_VERIFY_FLAGS_DEFER_AUTH to defer verification to other
+	  verifiers. These files are only successfully verified if another registered
+	  verifier returns success. Otherwise, the whole verification process fails.
+
+	  For example, PE/COFF binaries verification can be done by the shim_lock
+	  verifier which validates the signatures using the shim_lock protocol.
+	  However, the verification is not deferred directly to the shim_lock verifier.
+	  The shim_lock verifier is hooked into the verification process instead.
+
+	* A set of grub_{command,extcmd}_lockdown functions that can be used by
+	  code registering command handlers, to only register unsafe commands if
+	  the GRUB has not been locked down.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Marco A Benatto  <[e-mail]>
+
+	efi: Move the shim_lock verifier to the GRUB core
+	Move the shim_lock verifier from its own module into the core image. The
+	Secure Boot lockdown mechanism has the intent to prevent the load of any
+	unsigned code or binary when Secure Boot is enabled.
+
+	The reason is that GRUB must be able to prevent executing untrusted code
+	if UEFI Secure Boot is enabled, without depending on external modules.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Marco A Benatto  <[e-mail]>
+
+	verifiers: Move verifiers API to kernel image
+	Move verifiers API from a module to the kernel image, so it can be
+	used there as well. There are no functional changes in this patch.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	docs: Add documentation of disk size limitations
+	Document the artificially imposed 1 EiB disk size limit and size limitations
+	with LUKS volumes.
+
+	Fix a few punctuation issues.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	luks2: Use grub_log2ull() to calculate log_sector_size and improve readability
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
+	misc: Add grub_log2ull() macro for calculating log base 2 of 64-bit integers
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	mips: Enable __clzdi2()
+	This patch is similar to commit 9dab2f51e (sparc: Enable __clzsi2() and
+	__clzdi2()) but for MIPS target and __clzdi2() only, __clzsi2() was
+	already enabled.
+
+	Suggested-by: Daniel Kiper <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	luks2: Better error handling when setting up the cryptodisk
+	Do some sanity checking on data coming from the LUKS2 header. If segment.size
+	is "dynamic", verify that the offset is not past the end of disk. Otherwise,
+	check for errors from grub_strtoull() when converting segment size from
+	string. If a GRUB_ERR_BAD_NUMBER error was returned, then the string was
+	not a valid parsable number, so skip the key. If GRUB_ERR_OUT_OF_RANGE was
+	returned, then there was an overflow in converting to a 64-bit unsigned
+	integer. So this could be a very large disk (perhaps large RAID array).
+	In this case skip the key too. Additionally, enforce some other limits
+	and fail if needed.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	luks2: Do not handle disks of size GRUB_DISK_SIZE_UNKNOWN for now
+	Check to make sure that source disk has a known size. If not, print
+	a message and return error. There are 4 cases where GRUB_DISK_SIZE_UNKNOWN
+	is set (biosdisk, obdisk, ofdisk, and uboot), and in all those cases
+	processing continues. So this is probably a bit conservative. However,
+	3 of the cases seem pathological, and the other, biosdisk, happens when
+	booting from a CD-ROM. Since I doubt booting from a LUKS2 volume on
+	a CD-ROM is a big use case, we'll error until someone complains.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	luks2: Convert to crypt sectors from GRUB native sectors
+	The function grub_disk_native_sectors(source) returns the number of sectors
+	of source in GRUB native (512-byte) sectors, not source sized sectors. So
+	the conversion needs to use GRUB_DISK_SECTOR_BITS, the GRUB native sector
+	size.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	luks2: Error check segment.sector_size
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	cryptodisk: Properly handle non-512 byte sized sectors
+	By default, dm-crypt internally uses an IV that corresponds to 512-byte
+	sectors, even when a larger sector size is specified. What this means is
+	that when using a larger sector size, the IV is incremented every sector.
+	However, the amount the IV is incremented is the number of 512 byte blocks
+	in a sector (i.e. 8 for 4K sectors). Confusingly the IV does not correspond
+	to the number of, for example, 4K sectors. So each 512 byte cipher block in
+	a sector will be encrypted with the same IV and the IV will be incremented
+	afterwards by the number of 512 byte cipher blocks in the sector.
+
+	There are some encryption utilities which do it the intuitive way and have
+	the IV equal to the sector number regardless of sector size (ie. the fifth
+	sector would have an IV of 4 for each cipher block). And this is supported
+	by dm-crypt with the iv_large_sectors option and also cryptsetup as of 2.3.3
+	with the --iv-large-sectors, though not with LUKS headers (only with --type
+	plain). However, support for this has not been included as grub does not
+	support plain devices right now.
+
+	One gotcha here is that the encrypted split keys are encrypted with a hard-
+	coded 512-byte sector size. So even if your data is encrypted with 4K sector
+	sizes, the split key encrypted area must be decrypted with a block size of
+	512 (ie the IV increments every 512 bytes). This made these changes less
+	aesthetically pleasing than desired.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	luks2: grub_cryptodisk_t->total_sectors is the max number of device native sectors
+	We need to convert the sectors from the size of the underlying device to the
+	cryptodisk sector size; segment.size is in bytes which need to be converted
+	to cryptodisk sectors as well.
+
+	Also, removed an empty statement.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	cryptodisk: Add macros GRUB_TYPE_U_MAX/MIN(type) to replace literals
+	Add GRUB_TYPE_U_MAX/MIN(type) macros to get the max/min values for an
+	unsigned number with size of type.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	cryptodisk: Add macro GRUB_TYPE_BITS() to replace some literals
+	The new macro GRUB_TYPE_BITS(type) returns the number of bits
+	allocated for type.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	luks2: Add string "index" to user strings using a json index
+	This allows error messages to be more easily distinguishable between indexes
+	and slot keys. The former include the string "index" in the error/debug
+	string, and the later are surrounded in quotes.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	luks2: Rename json index variables to names that they are obviously json indexes
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	luks2: Use more intuitive object name instead of json index in user messages
+	Use the object name in the json array rather than the 0 based index in the
+	json array for keyslots, segments, and digests. This is less confusing for
+	the end user. For example, say you have a LUKS2 device with a key in slot 1
+	and slot 4. When using the password for slot 4 to unlock the device, the
+	messages using the index of the keyslot will mention keyslot 1 (its a
+	zero-based index). Furthermore, with this change the keyslot number will
+	align with the number used to reference the keyslot when using the
+	--key-slot argument to cryptsetup.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	luks2: Add idx member to struct grub_luks2_keyslot/segment/digest
+	This allows code using these structs to know the named key associated with
+	these json data structures. In the future we can use these to provide better
+	error messages to the user.
+
+	Get rid of idx local variable in luks2_get_keyslot() which was overloaded to
+	be used for both keyslot and segment slot keys.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	luks2: Make sure all fields of output argument in luks2_parse_digest() are written to
+	We should assume that the output argument "out" is uninitialized and could
+	have random data. So, make sure to initialize the segments and keyslots bit
+	fields because potentially not all bits of those fields are written to.
+	Otherwise, the digest could say it belongs to keyslots and segments that it
+	does not.
+
+	Reviewed-by: Patrick Steinhardt <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	luks2: Remove unused argument in grub_error() call
+	Reviewed-by: Patrick Steinhardt <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
+	luks2: Convert 8 spaces to tabs
+	Reviewed-by: Patrick Steinhardt <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	misc: Add parentheses around ALIGN_UP() and ALIGN_DOWN() arguments
+	This ensures that expected order of operations is preserved when arguments
+	are expressions.
+
+	Reviewed-by: Patrick Steinhardt <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	disk: Rename grub_disk_get_size() to grub_disk_native_sectors()
+	The function grub_disk_get_size() is confusingly named because it actually
+	returns a sector count where the sectors are sized in the GRUB native sector
+	size. Rename to something more appropriate.
+
+	Suggested-by: Daniel Kiper <[e-mail]>
+	Reviewed-by: Patrick Steinhardt <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	loopback: Do not automaticaly replace existing loopback dev, error instead
+	If there is a loopback device with the same name as the one to be created,
+	instead of closing the old one and replacing it with the new one, return an
+	error instead. If the loopback device was created, its probably being used
+	by something and just replacing it may cause GRUB to crash unexpectedly.
+	This fixes obvious problems like "loopback d (d)/somefile". Its not too
+	onerous to force the user to delete the loopback first with the "-d" switch.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	disk: Move hardcoded max disk size literal to a GRUB_DISK_MAX_SECTORS in disk.h
+	There is a hardcoded maximum disk size that can be read or written from,
+	currently set at 1 EiB in grub_disk_adjust_range(). Move the literal into a
+	macro in disk.h, so our assumptions are more visible. This hard coded limit
+	does not prevent using larger disks, just GRUB won't read/write past the
+	limit. The comment accompanying this restriction didn't quite make sense to
+	me, so its been modified too.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	fs: Fix block lists not being able to address to end of disk sometimes
+	When checking if a block list goes past the end of the disk, make sure
+	the total size of the disk is in GRUB native sector sizes, otherwise there
+	will be blocks at the end of the disk inaccessible by block lists.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Vladimir Serbinenko  <[e-mail]>
+
+	mbr: Document new limitations on MBR gap support
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Vladimir Serbinenko  <[e-mail]>
+
+	mbr: Warn if MBR gap is small and user uses advanced modules
+	We don't want to support small MBR gap in pair with anything but the
+	simplest config of biosdisk + part_msdos + simple filesystem. In this
+	path "simple filesystems" are all current filesystems except ZFS and
+	Btrfs.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Tianjia Zhang  <[e-mail]>
+
+	efi/tpm: Extract duplicate code into independent functions
+	Part of the code logic for processing the return value of efi
+	log_extend_event is repetitive and complicated. Extract the
+	repetitive code into an independent function.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Tianjia Zhang  <[e-mail]>
+
+	efi/tpm: Add debug information for device protocol and eventlog
+	Add a number of debug logs to the tpm module. The condition tag
+	for opening debugging is "tpm". On TPM machines, this will bring
+	great convenience to diagnosis and debugging.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Kiper  <[e-mail]>
+
+	loader/linux: Report the UEFI Secure Boot status to the Linux kernel
+	Now that the GRUB has a grub_efi_get_secureboot() function to check the
+	UEFI Secure Boot status, use it to report that to the Linux kernel.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	efi: Only register shim_lock verifier if shim_lock protocol is found and SB enabled
+	The shim_lock module registers a verifier to call shim's verify, but the
+	handler is registered even when the shim_lock protocol was not installed.
+
+	This doesn't cause a NULL pointer dereference in shim_lock_write() because
+	the shim_lock_init() function just returns GRUB_ERR_NONE if sl isn't set.
+
+	But in that case there's no point to even register the shim_lock verifier
+	since won't do anything. Additionally, it is only useful when Secure Boot
+	is enabled.
+
+	Finally, don't assume that the shim_lock protocol will always be present
+	when the shim_lock_write() function is called, and check for it on every
+	call to this function.
+
+	Reported-by: Michael Chang <[e-mail]>
+	Reported-by: Peter Jones <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Kiper  <[e-mail]>
+
+	efi: Add secure boot detection
+	Introduce grub_efi_get_secureboot() function which returns whether
+	UEFI Secure Boot is enabled or not on UEFI systems.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Kiper  <[e-mail]>
+
+	efi: Add a function to read EFI variables with attributes
+	It will be used to properly detect and report UEFI Secure Boot status to
+	the x86 Linux kernel. The functionality will be added by subsequent patches.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Kiper  <[e-mail]>
+
+	efi: Return grub_efi_status_t from grub_efi_get_variable()
+	This is needed to properly detect and report UEFI Secure Boot status
+	to the x86 Linux kernel. The functionality will be added by subsequent
+	patches.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Kiper  <[e-mail]>
+
+	efi: Make shim_lock GUID and protocol type public
+	The GUID will be used to properly detect and report UEFI Secure Boot
+	status to the x86 Linux kernel. The functionality will be added by
+	subsequent patches. The shim_lock protocol type is made public for
+	completeness.
+
+	Additionally, fix formatting of four preceding GUIDs.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	arm/term: Fix linking error due multiple ps2_state definitions
+	When building with --target=arm-linux-gnu --with-platform=coreboot
+	a linking error occurs caused by multiple definitions of the
+	ps2_state variable.
+
+	Mark them as static since they aren't used outside their compilation unit.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	include/grub/i386/linux.h: Include missing <grub/types.h> header
+	This header uses types defined in <grub/types.h> but does not include it,
+	which leads to compile errors like the following:
+
+	In file included from ../include/grub/cpu/linux.h:19,
+	                 from kern/efi/sb.c:21:
+	../include/grub/i386/linux.h:80:3: error: unknown type name ‘grub_uint64_t’
+	   80 |   grub_uint64_t addr;
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	i386: Don't include <grub/cpu/linux.h> in coreboot and ieee1275 startup.S
+	Nothing defined in the header file is used in the assembly code but it
+	may lead to build errors if some headers are included through this and
+	contains definitions that are not recognized by the assembler, e.g.:
+
+	../include/grub/types.h: Assembler messages:
+	../include/grub/types.h:76: Error: no such instruction: `typedef signed char grub_int8_t'
+	../include/grub/types.h:77: Error: no such instruction: `typedef short grub_int16_t'
+	../include/grub/types.h:78: Error: no such instruction: `typedef int grub_int32_t'
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	luks2: Rename index variable "j" to "i" in luks2_get_keyslot()
+	Looping variable "j" was named such because the variable name "i" was taken.
+	Since "i" has been renamed in the previous patch, we can rename "j" to "i".
+
+	Reviewed-by: Patrick Steinhardt <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	luks2: Rename variable "i" to "keyslot_idx" in luks2_get_keyslot()
+	Variables named "i" are usually looping variables. So, rename it to
+	"keyslot_idx" to ease luks2_get_keyslot() reading.
+
+	Reviewed-by: Patrick Steinhardt <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	luks2: Use correct index variable when looping in luks2_get_keyslot()
+	The loop variable "j" should be used to index the digests and segments json
+	array, instead of the variable "i", which is the keyslot index.
+
+	Reviewed-by: Patrick Steinhardt <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	luks2: Rename source disk variable named "disk" to "source" as in luks.c
+	This makes it more obvious to the reader that the disk referred to is the
+	source disk, as opposed to say the disk holding the cryptodisk.
+
+	Reviewed-by: Patrick Steinhardt <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	cryptodisk: Rename "offset" in grub_cryptodisk_t to "offset_sectors"
+	This makes it clear that the offset represents sectors, not bytes, in
+	order to improve readability.
+
+	Reviewed-by: Patrick Steinhardt <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	cryptodisk: Rename "total_length" field in grub_cryptodisk_t to "total_sectors"
+	This creates an alignment with grub_disk_t naming of the same field and is
+	more intuitive as to how it should be used.
+
+	Reviewed-by: Patrick Steinhardt <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	types: Define GRUB_CHAR_BIT based on compiler macro instead of using literal
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	include/grub/arm64/linux.h: Include missing <grub/types.h> header
+	This header uses types defined in <grub/types.h> but does not include it,
+	which leads to compile errors like the following:
+
+	../include/grub/cpu/linux.h:27:3: error: unknown type name ‘grub_uint32_t’
+	   27 |   grub_uint32_t code0;  /* Executable code */
+	      |   ^~~~~~~~~~~~~
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	include/grub/arm/system.h: Include missing <grub/symbol.h> header
+	The header uses the EXPORT_FUNC() macro defined in <grub/types.h> but
+	doesn't include it, which leads to the following compile error on arm:
+
+	../include/grub/cpu/system.h:12:13: error: ‘EXPORT_FUNC’ declared as function returning a function
+	   12 | extern void EXPORT_FUNC(grub_arm_disable_caches_mmu) (void);
+	      |             ^~~~~~~~~~~
+	../include/grub/cpu/system.h:12:1: warning: parameter names (without types) in function declaration
+	   12 | extern void EXPORT_FUNC(grub_arm_disable_caches_mmu) (void);
+	      | ^~~~~~
+	make[3]: *** [Makefile:36581: kern/efi/kernel_exec-sb.o] Error 1
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	docs: grub-install --pubkey has been supported for some time
+	grub-install --pubkey is supported, so we can now document it.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	docs: grub-install is no longer a shell script
+	Since commit cd46aa6cefab in 2013, grub-install hasn't been a shell
+	script. The para doesn't really add that much, especially since it's
+	the user manual, so just drop it.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Jacob Kroon  <[e-mail]>
+
+	Makefile: Remove unused GRUB_PKGLIBDIR definition
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	lzma: Fix compilation error under clang 10
+	Compiling under clang 10 gives:
+
+	grub-core/lib/LzmaEnc.c:1362:9: error: misleading indentation; statement is not part of the previous 'if' [-Werror,-Wmisleading-indentation]
+	        {
+	        ^
+	grub-core/lib/LzmaEnc.c:1358:7: note: previous statement is here
+	      if (repIndex == 0)
+	      ^
+	1 error generated.
+
+	It's not really that unclear in context: there's a commented-out
+	if-statement. But tweak the alignment anyway so that clang is happy.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Cao jin  <[e-mail]>
+
+	kern/i386/realmode: Update comment
+	Commit b81d609e4c did not update it.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	cryptodisk: Fix cipher IV mode "plain64" always being set as "plain"
+	When setting cipher IV mode, detection is done by prefix matching the
+	cipher IV mode part of the cipher mode string. Since "plain" matches
+	"plain64", we must check for "plain64" first. Otherwise, "plain64" will
+	be detected as "plain".
+
+	Reviewed-by: Patrick Steinhardt <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	crypto: Remove GPG_ERROR_CFLAGS from gpg_err_code_t enum
+	This was probably added by accident when originally creating the file.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	script: Do not allow a delimiter between function name and block start
+	Currently the following is valid syntax but should be a syntax error:
+
+	  grub> function f; { echo HERE; }
+	  grub> f
+	  HERE
+
+	This fix is not backward compatible, but current syntax is not documented
+	either and has no functional value. So any scripts with this unintended
+	syntax are technically syntactically incorrect and should not be relying
+	on this behavior.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	docs: Support for loading and concatenating multiple initrds
+	This has been available since January of 2012 but has not been documented.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	lexer: char const * should be const char *
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
+	cryptodisk: Use cipher name instead of object in error message
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	tests: F2FS test should use MOUNTDEVICE like other tests
+	LODEVICES is not an array variable and should not be accessed as such.
+	This allows the f2fs test to pass as it was failing because a device
+	name had a space prepended to the path.
+
+	Acked-by: Jaegeuk Kim <[e-mail]>
+	Tested-by: Paul Menzel <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Florian La Roche  <[e-mail]>
+
+	grub-mkconfig: If $hints is not set reduce the output into grub.cfg to just 1 line
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Petr Vorel  <[e-mail]>
+
+	travis: Run bootstrap to fix build
+	autogen.sh isn't enough:
+
+	  $ ./autogen.sh
+	  Gnulib not yet bootstrapped; run ./bootstrap instead.
+	  The command "./autogen.sh" exited with 1.
+
+	Additionally, using bootstrap requires to install autopoint package.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Patrick Steinhardt  <[e-mail]>
+
+	luks2: Strip dashes off of the UUID
+	The UUID header for LUKS2 uses a format with dashes, same as for
+	LUKS(1). But while we strip these dashes for the latter, we don't for
+	the former. This isn't wrong per se, but it's definitely inconsistent
+	for users as they need to use the dashed format for LUKS2 and the
+	non-dashed format for LUKS when e.g. calling "cryptomount -u $UUID".
+
+	Fix this inconsistency by stripping dashes off of the LUKS2 UUID.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Tianjia Zhang  <[e-mail]>
+
+	efi/tpm: Remove unused functions and structures
+	Although the tpm_execute() series of functions are defined they are not
+	used anywhere. Several structures in the include/grub/efi/tpm.h header
+	file are not used too. There is even nonexistent grub_tpm_init()
+	declaration in this header. Delete all that unneeded stuff.
+
+	If somebody needs the functionality implemented in the dropped code then
+	he/she can re-add it later. Now it needlessly increases the GRUB
+	code/image size.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Tianjia Zhang  <[e-mail]>
+
+	shim_lock: Enable module for all EFI architectures
+	Like the tpm the shim_lock module is only enabled for x86_64 target.
+	However, there's nothing specific to x86_64 in the implementation and
+	it can be enabled for all EFI architectures.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Kiper  <[e-mail]>
+
+	efi/tpm: Fix typo in grub_efi_tpm2_protocol struct
+	Rename get_active_pcr_blanks() to get_active_pcr_banks().
+
+	Reviewed-by: Javier Martinez Canillas <[e-mail]>
+
[phone]  Daniel Kiper  <[e-mail]>
+
+	i386/efi/init: Drop bogus include
+	Reviewed-by: Javier Martinez Canillas <[e-mail]>
+
[phone]  Daniel Kiper  <[e-mail]>
+
+	docs: Fix devicetree command description
+	Specifically fix the subsection and drop bogus reference to the GNU/Linux.
+
+	Reported-by: Patrick Higgins <[e-mail]>
+	Reviewed-by: Javier Martinez Canillas <[e-mail]>
+
[phone]  Martin Whitaker  <[e-mail]>
+
+	grub-install: Fix inverted test for NLS enabled when copying locales
+	Commit 3d8439da8 (grub-install: Locale depends on nls) attempted to avoid
+	copying locale files to the target directory when NLS was disabled.
+	However the test is inverted, and it does the opposite.
+
+	Reviewed-by: Javier Martinez Canillas <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	tftp: Roll-over block counter to prevent data packets timeouts
+	Commit 781b3e5efc3 (tftp: Do not use priority queue) caused a regression
+	when fetching files over TFTP whose size is bigger than 65535 * block size.
+
+	  grub> linux /images/pxeboot/vmlinuz
+	  grub> echo $?
+	  0
+	  grub> initrd /images/pxeboot/initrd.img
+	  error: timeout reading '/images/pxeboot/initrd.img'.
+	  grub> echo $?
+	  28
+
+	It is caused by the block number counter being a 16-bit field, which leads
+	to a maximum file size of ((1 << 16) - 1) * block size. Because GRUB sets
+	the block size to 1024 octets (by using the TFTP Blocksize Option from RFC
+	2348 [0]), the maximum file size that can be transferred is 67107840 bytes.
+
+	The TFTP PROTOCOL (REVISION 2) RFC 1350 [1] does not mention what a client
+	should do when a file size is bigger than the maximum, but most TFTP hosts
+	support the block number counter to be rolled over. That is, acking a data
+	packet with a block number of 0 is taken as if the 65356th block was acked.
+
+	It was working before because the block counter roll-over was happening due
+	an overflow. But that got fixed by the mentioned commit, which led to the
+	regression when attempting to fetch files larger than the maximum size.
+
+	To allow TFTP file transfers of unlimited size again, re-introduce a block
+	counter roll-over so the data packets are acked preventing the timeouts.
+
+	[0]: https://tools.ietf.org/html/rfc2348
+	[1]: https://tools.ietf.org/html/rfc1350
+
+	Fixes: 781b3e5efc3 (tftp: Do not use priority queue)
+
+	Suggested-by: Peter Jones <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Florian La Roche  <[e-mail]>
+
+	templates: Remove unnecessary trailing semicolon
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	cryptodisk: Fix incorrect calculation of start sector
+	Here dev is a grub_cryptodisk_t and dev->offset is offset in sectors of size
+	native to the cryptodisk device. The sector is correctly transformed into
+	native grub sector size, but then added to dev->offset which is not
+	transformed. It would be nice if the type system would help us with this.
+
+	Reviewed-by: Patrick Steinhardt <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Glenn Washburn  <[e-mail]>
+
+	cryptodisk: Unregister cryptomount command when removing module
+	Reviewed-by: Patrick Steinhardt <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Patrick Steinhardt  <[e-mail]>
+
+	luks2: Improve error reporting when decrypting/verifying key
+	While we already set up error messages in both luks2_verify_key() and
+	luks2_decrypt_key(), we do not ever print them. This makes it really
+	hard to discover why a given key actually failed to decrypt a disk.
+
+	Improve this by including the error message in the user-visible output.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Patrick Steinhardt  <[e-mail]>
+
+	luks: Fix out-of-bounds copy of UUID
+	When configuring a LUKS disk, we copy over the UUID from the LUKS header
+	into the new grub_cryptodisk_t structure via grub_memcpy(). As size
+	we mistakenly use the size of the grub_cryptodisk_t UUID field, which
+	is guaranteed to be strictly bigger than the LUKS UUID field we're
+	copying. As a result, the copy always goes out-of-bounds and copies some
+	garbage from other surrounding fields. During runtime, this isn't
+	noticed due to the fact that we always NUL-terminate the UUID and thus
+	never hit the trailing garbage.
+
+	Fix the issue by using the size of the local stripped UUID field.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Patrick Steinhardt  <[e-mail]>
+
+	json: Remove invalid typedef redefinition
+	The C standard does not allow for typedef redefinitions, even if they
+	map to the same underlying type. In order to avoid including the
+	jsmn.h in json.h and thus exposing jsmn's internals, we have exactly
+	such a forward-declaring typedef in json.h. If enforcing the GNU99 C
+	standard, clang may generate a warning about this non-standard
+	construct.
+
+	Fix the issue by using a simple "struct jsmntok" forward declaration
+	instead of using a typedef.
+
+	Tested-by: Chuck Tuffli <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Cao jin  <[e-mail]>
+
+	i386/relocator_common: Drop empty #ifdef
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Ave Milia  <[e-mail]>
+
+	video/bochs: Fix typo
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Colin Watson  <[e-mail]>
+
+	linux: Fix integer overflows in initrd size handling
+	These could be triggered by a crafted filesystem with very large files.
+
+	Fixes: CVE-2020-15707
+
+	Reviewed-by: Jan Setje-Eilers <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	loader/linux: Avoid overflow on initrd size calculation
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Alexey Makhalov  <[e-mail]>
+
+	efi: Fix use-after-free in halt/reboot path
+	commit 92bfc33db984 ("efi: Free malloc regions on exit")
+	introduced memory freeing in grub_efi_fini(), which is
+	used not only by exit path but by halt/reboot one as well.
+	As result of memory freeing, code and data regions used by
+	modules, such as halt, reboot, acpi (used by halt) also got
+	freed. After return to module code, CPU executes, filled
+	by UEFI firmware (tested with edk2), 0xAFAFAFAF pattern as
+	a code. Which leads to #UD exception later.
+
+	grub> halt
+	!!!! X64 Exception Type - 06(#UD - Invalid Opcode)  CPU Apic ID - 00000000 !!!!
+	RIP  - 0000000003F4EC28, CS  - 0000000000000038, RFLAGS - 0000000000200246
+	RAX  - 0000000000000000, RCX - 00000000061DA188, RDX - 0A74C0854DC35D41
+	RBX  - 0000000003E10E08, RSP - 0000000007F0F860, RBP - 0000000000000000
+	RSI  - 00000000064DB768, RDI - 000000000832C5C3
+	R8   - 0000000000000002, R9  - 0000000000000000, R10 - 00000000061E2E52
+	R11  - 0000000000000020, R12 - 0000000003EE5C1F, R13 - 00000000061E0FF4
+	R14  - 0000000003E10D80, R15 - 00000000061E2F60
+	DS   - 0000000000000030, ES  - 0000000000000030, FS  - 0000000000000030
+	GS   - 0000000000000030, SS  - 0000000000000030
+	CR0  - 0000000080010033, CR2 - 0000000000000000, CR3 - 0000000007C01000
+	CR4  - 0000000000000668, CR8 - 0000000000000000
+	DR0  - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
+	DR3  - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
+	GDTR - 00000000079EEA98 0000000000000047, LDTR - 0000000000000000
+	IDTR - 0000000007598018 0000000000000FFF,   TR - 0000000000000000
+	FXSAVE_STATE - 0000000007F0F4C0
+
+	Proposal here is to continue to free allocated memory for
+	exit boot services path but keep it for halt/reboot path
+	as it won't be much security concern here.
+	Introduced GRUB_LOADER_FLAG_EFI_KEEP_ALLOCATED_MEMORY
+	loader flag to be used by efi halt/reboot path.
+
+	Reviewed-by: Darren Kenny <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Kiper  <[e-mail]>
+
+	efi/chainloader: Propagate errors from copy_file_path()
+	Without any error propagated to the caller, make_file_path()
+	would then try to advance the invalid device path node with
+	GRUB_EFI_NEXT_DEVICE_PATH(), which would fail, returning a NULL
+	pointer that would subsequently be dereferenced. Hence, propagate
+	errors from copy_file_path().
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	efi: Fix some malformed device path arithmetic errors
+	Several places we take the length of a device path and subtract 4 from
+	it, without ever checking that it's >= 4. There are also cases where
+	this kind of malformation will result in unpredictable iteration,
+	including treating the length from one dp node as the type in the next
+	node. These are all errors, no matter where the data comes from.
+
+	This patch adds a checking macro, GRUB_EFI_DEVICE_PATH_VALID(), which
+	can be used in several places, and makes GRUB_EFI_NEXT_DEVICE_PATH()
+	return NULL and GRUB_EFI_END_ENTIRE_DEVICE_PATH() evaluate as true when
+	the length is too small. Additionally, it makes several places in the
+	code check for and return errors in these cases.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	emu: Make grub_free(NULL) safe
+	The grub_free() implementation in grub-core/kern/mm.c safely handles
+	NULL pointers, and code at many places depends on this. We don't know
+	that the same is true on all host OSes, so we need to handle the same
+	behavior in grub-emu's implementation.
+
+	Reviewed-by: Darren Kenny <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	lvm: Fix two more potential data-dependent alloc overflows
+	It appears to be possible to make a (possibly invalid) lvm PV with
+	a metadata size field that overflows our type when adding it to the
+	address we've allocated. Even if it doesn't, it may be possible to do so
+	with the math using the outcome of that as an operand. Check them both.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	hfsplus: Fix two more overflows
+	Both node->size and node->namelen come from the supplied filesystem,
+	which may be user-supplied. We can't trust them for the math unless we
+	know they don't overflow. Making sure they go through grub_add() or
+	grub_calloc() first will give us that.
+
+	Reviewed-by: Darren Kenny <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Alexey Makhalov  <[e-mail]>
+
+	relocator: Fix grub_relocator_alloc_chunk_align() top memory allocation
+	Current implementation of grub_relocator_alloc_chunk_align()
+	does not allow allocation of the top byte.
+
+	Assuming input args are:
+	  max_addr = 0xfffff000;
+	  size = 0x1000;
+
+	And this is valid. But following overflow protection will
+	unnecessarily move max_addr one byte down (to 0xffffefff):
+	  if (max_addr > ~size)
+	    max_addr = ~size;
+
+	~size + 1 will fix the situation. In addition, check size
+	for non zero to do not zero max_addr.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Chris Coulson  <[e-mail]>
+
+	script: Avoid a use-after-free when redefining a function during execution
+	Defining a new function with the same name as a previously defined
+	function causes the grub_script and associated resources for the
+	previous function to be freed. If the previous function is currently
+	executing when a function with the same name is defined, this results
+	in use-after-frees when processing subsequent commands in the original
+	function.
+
+	Instead, reject a new function definition if it has the same name as
+	a previously defined function, and that function is currently being
+	executed. Although a behavioural change, this should be backwards
+	compatible with existing configurations because they can't be
+	dependent on the current behaviour without being broken.
+
+	Fixes: CVE-2020-15706
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Chris Coulson  <[e-mail]>
+
+	script: Remove unused fields from grub_script_function struct
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Alexey Makhalov  <[e-mail]>
+
+	relocator: Protect grub_relocator_alloc_chunk_align() max_addr against integer underflow
+	This commit introduces integer underflow mitigation in max_addr calculation
+	in grub_relocator_alloc_chunk_align() invocation.
+
+	It consists of 2 fixes:
+	  1. Introduced grub_relocator_alloc_chunk_align_safe() wrapper function to perform
+	     sanity check for min/max and size values, and to make safe invocation of
+	     grub_relocator_alloc_chunk_align() with validated max_addr value. Replace all
+	     invocations such as grub_relocator_alloc_chunk_align(..., min_addr, max_addr - size, size, ...)
+	     by grub_relocator_alloc_chunk_align_safe(..., min_addr, max_addr, size, ...).
+	  2. Introduced UP_TO_TOP32(s) macro for the cases where max_addr is 32-bit top
+	     address (0xffffffff - size + 1) or similar.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Alexey Makhalov  <[e-mail]>
+
+	relocator: Protect grub_relocator_alloc_chunk_addr() input args against integer underflow/overflow
+	Use arithmetic macros from safemath.h to accomplish it. In this commit,
+	I didn't want to be too paranoid to check every possible math equation
+	for overflow/underflow. Only obvious places (with non zero chance of
+	overflow/underflow) were refactored.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Alexey Makhalov  <[e-mail]>
+
+	tftp: Do not use priority queue
+	There is not need to reassemble the order of blocks. Per RFC 1350,
+	server must wait for the ACK, before sending next block. Data packets
+	can be served immediately without putting them to priority queue.
+
+	Logic to handle incoming packet is this:
+	  - if packet block id equal to expected block id, then
+	    process the packet,
+	  - if packet block id is less than expected - this is retransmit
+	    of old packet, then ACK it and drop the packet,
+	  - if packet block id is more than expected - that shouldn't
+	    happen, just drop the packet.
+
+	It makes the tftp receive path code simpler, smaller and faster.
+	As a benefit, this change fixes CID# 73624 and CID# 96690, caused
+	by following while loop:
+
+	  while (cmp_block (grub_be_to_cpu16 (tftph->u.data.block), data->block + 1) == 0)
+
+	where tftph pointer is not moving from one iteration to another, causing
+	to serve same packet again. Luckily, double serving didn't happen due to
+	data->block++ during the first iteration.
+
+	Fixes: CID 73624, CID 96690
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Konrad Rzeszutek Wilk  <[e-mail]>
+
+	multiboot2: Fix memory leak if grub_create_loader_cmdline() fails
+	Fixes: CID 292468
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Konrad Rzeszutek Wilk  <[e-mail]>
+
+	udf: Fix memory leak
+	Fixes: CID 73796
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+	Reviewed-by: Jan Setje-Eilers <[e-mail]>
+
[phone]  Konrad Rzeszutek Wilk  <[e-mail]>
+
+	term: Fix overflow on user inputs
+	This requires a very weird input from the serial interface but can cause
+	an overflow in input_buf (keys) overwriting the next variable (npending)
+	with the user choice:
+
+	(pahole output)
+
+	struct grub_terminfo_input_state {
+	        int                        input_buf[6];         /*     0    24 */
+	        int                        npending;             /*    24     4 */ <- CORRUPT
+	        ...snip...
+
+	The magic string requires causing this is "ESC,O,],0,1,2,q" and we overflow
+	npending with "q" (aka increase npending to 161). The simplest fix is to
+	just to disallow overwrites input_buf, which exactly what this patch does.
+
+	Fixes: CID 292449
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Konrad Rzeszutek Wilk  <[e-mail]>
+
+	lzma: Make sure we don't dereference past array
+	The two dimensional array p->posSlotEncoder[4][64] is being dereferenced
+	using the GetLenToPosState() macro which checks if len is less than 5,
+	and if so subtracts 2 from it. If len = 0, that is 0 - 2 = 4294967294.
+	Obviously we don't want to dereference that far out so we check if the
+	position found is greater or equal kNumLenToPosStates (4) and bail out.
+
+	N.B.: Upstream LZMA 18.05 and later has this function completely rewritten
+	without any history.
+
+	Fixes: CID 51526
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Chris Coulson  <[e-mail]>
+
+	json: Avoid a double-free when parsing fails.
+	When grub_json_parse() succeeds, it returns the root object which
+	contains a pointer to the provided JSON string. Callers are
+	responsible for ensuring that this string outlives the root
+	object and for freeing its memory when it's no longer needed.
+
+	If grub_json_parse() fails to parse the provided JSON string,
+	it frees the string before returning an error. This results
+	in a double free in luks2_recover_key(), which also frees the
+	same string after grub_json_parse() returns an error.
+
+	This changes grub_json_parse() to never free the JSON string
+	passed to it, and updates the documentation for it to make it
+	clear that callers are responsible for ensuring that the string
+	outlives the root JSON object.
+
+	Fixes: CID 292465
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Alexey Makhalov  <[e-mail]>
+
+	xnu: Fix double free in grub_xnu_devprop_add_property()
+	grub_xnu_devprop_add_property() should not free utf8 and utf16 as it get
+	allocated and freed in the caller.
+
+	Minor improvement: do prop fields initialization after memory allocations.
+
+	Fixes: CID 292442, CID 292457, CID 292460, CID 292466
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Alexey Makhalov  <[e-mail]>
+
+	gfxmenu: Fix double free in load_image()
+	self->bitmap should be zeroed after free. Otherwise, there is a chance
+	to double free (USE_AFTER_FREE) it later in rescale_image().
+
+	Fixes: CID 292472
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Kiper  <[e-mail]>
+
+	font: Do not load more than one NAME section
+	The GRUB font file can have one NAME section only. Though if somebody
+	crafts a broken font file with many NAME sections and loads it then the
+	GRUB leaks memory. So, prevent against that by loading first NAME
+	section and failing in controlled way on following one.
+
+	Reported-by: Chris Coulson <[e-mail]>
+	Reviewed-by: Jan Setje-Eilers <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	iso9660: Don't leak memory on realloc() failures
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	malloc: Use overflow checking primitives where we do complex allocations
+	This attempts to fix the places where we do the following where
+	arithmetic_expr may include unvalidated data:
+
+	  X = grub_malloc(arithmetic_expr);
+
+	It accomplishes this by doing the arithmetic ahead of time using grub_add(),
+	grub_sub(), grub_mul() and testing for overflow before proceeding.
+
+	Among other issues, this fixes:
+	  - allocation of integer overflow in grub_video_bitmap_create()
+	    reported by Chris Coulson,
+	  - allocation of integer overflow in grub_png_decode_image_header()
+	    reported by Chris Coulson,
+	  - allocation of integer overflow in grub_squash_read_symlink()
+	    reported by Chris Coulson,
+	  - allocation of integer overflow in grub_ext2_read_symlink()
+	    reported by Chris Coulson,
+	  - allocation of integer overflow in read_section_as_string()
+	    reported by Chris Coulson.
+
+	Fixes: CVE-2020-14309, CVE-2020-14310, CVE-2020-14311
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	calloc: Use calloc() at most places
+	This modifies most of the places we do some form of:
+
+	  X = malloc(Y * Z);
+
+	to use calloc(Y, Z) instead.
+
+	Among other issues, this fixes:
+	  - allocation of integer overflow in grub_png_decode_image_header()
+	    reported by Chris Coulson,
+	  - allocation of integer overflow in luks_recover_key()
+	    reported by Chris Coulson,
+	  - allocation of integer overflow in grub_lvm_detect()
+	    reported by Chris Coulson.
+
+	Fixes: CVE-2020-14308
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	calloc: Make sure we always have an overflow-checking calloc() available
+	This tries to make sure that everywhere in this source tree, we always have
+	an appropriate version of calloc() (i.e. grub_calloc(), xcalloc(), etc.)
+	available, and that they all safely check for overflow and return NULL when
+	it would occur.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	safemath: Add some arithmetic primitives that check for overflow
+	This adds a new header, include/grub/safemath.h, that includes easy to
+	use wrappers for __builtin_{add,sub,mul}_overflow() declared like:
+
+	  bool OP(a, b, res)
+
+	where OP is grub_add, grub_sub or grub_mul. OP() returns true in the
+	case where the operation would overflow and res is not modified.
+	Otherwise, false is returned and the operation is executed.
+
+	These arithmetic primitives require newer compiler versions. So, bump
+	these requirements in the INSTALL file too.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	yylex: Make lexer fatal errors actually be fatal
+	When presented with a command that can't be tokenized to anything
+	smaller than YYLMAX characters, the parser calls YY_FATAL_ERROR(errmsg),
+	expecting that will stop further processing, as such:
+
+	  #define YY_DO_BEFORE_ACTION \
+	        yyg->yytext_ptr = yy_bp; \
+	        yyleng = (int) (yy_cp - yy_bp); \
+	        yyg->yy_hold_char = *yy_cp; \
+	        *yy_cp = '\0'; \
+	        if ( yyleng >= YYLMAX ) \
+	                YY_FATAL_ERROR( "token too large, exceeds YYLMAX" ); \
+	        yy_flex_strncpy( yytext, yyg->yytext_ptr, yyleng + 1 , yyscanner); \
+	        yyg->yy_c_buf_p = yy_cp;
+
+	The code flex generates expects that YY_FATAL_ERROR() will either return
+	for it or do some form of longjmp(), or handle the error in some way at
+	least, and so the strncpy() call isn't in an "else" clause, and thus if
+	YY_FATAL_ERROR() is *not* actually fatal, it does the call with the
+	questionable limit, and predictable results ensue.
+
+	Unfortunately, our implementation of YY_FATAL_ERROR() is:
+
+	   #define YY_FATAL_ERROR(msg)                     \
+	     do {                                          \
+	       grub_printf (_("fatal error: %s\n"), _(msg));     \
+	     } while (0)
+
+	The same pattern exists in yyless(), and similar problems exist in users
+	of YY_INPUT(), several places in the main parsing loop,
+	yy_get_next_buffer(), yy_load_buffer_state(), yyensure_buffer_stack,
+	yy_scan_buffer(), etc.
+
+	All of these callers expect YY_FATAL_ERROR() to actually be fatal, and
+	the things they do if it returns after calling it are wildly unsafe.
+
+	Fixes: CVE-2020-10713
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Marc Zyngier  <[e-mail]>
+
+	arm: Fix 32-bit ARM handling of the CTR register
+	When booting on an ARMv8 core that implements either CTR.IDC or CTR.DIC
+	(indicating that some of the cache maintenance operations can be
+	removed when dealing with I/D-cache coherency, GRUB dies with a
+	"Unsupported cache type 0x........" message.
+
+	This is pretty likely to happen when running in a virtual machine
+	hosted on an arm64 machine (I've triggered it on a system built around
+	a bunch of Cortex-A55 cores, which implements CTR.IDC).
+
+	It turns out that the way GRUB deals with the CTR register is a bit
+	harsh for anything from ARMv7 onwards. The layout of the register is
+	backward compatible, meaning that nothing that gets added is allowed to
+	break earlier behaviour. In this case, ignoring IDC is completely fine,
+	and only results in unnecessary cache maintenance.
+
+	We can thus avoid being paranoid, and align the 32bit behaviour with
+	its 64bit equivalent.
+
+	This patch has the added benefit that it gets rid of a (gnu-specific)
+	case range too.
+
+	Reviewed-by: Leif Lindholm <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Ian Jackson  <[e-mail]>
+
+	templates/20_linux_xen: Support Xen Security Modules (XSM/FLASK)
+	XSM is enabled by adding "flask=enforcing" as a Xen command line
+	argument, and providing the policy file as a grub module.
+
+	We make entries for both with and without XSM. If XSM is not compiled
+	into Xen, then there are no policy files, so no change to the boot
+	options.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Ian Jackson  <[e-mail]>
+
+	templates/20_linux_xen: Ignore xenpolicy and config files too
+	file_is_not_sym() currently only checks for xen-syms. Extend it to
+	disregard xenpolicy (XSM policy files) and files ending .config (which
+	are built by the Xen upstream build system in some configurations and
+	can therefore end up in /boot).
+
+	Rename the function accordingly, to file_is_not_xen_garbage().
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	net: Break out nested function
+	Nested functions are not supported in C, but are permitted as an extension
+	in the GNU C dialect. Commit cb2f15c5448 ("normal/main: Search for specific
+	config files for netboot") added a nested function which caused the build
+	to break when compiling with clang.
+
+	Break that out into a static helper function to make the code portable again.
+
+	Reported-by: Daniel Axtens <[e-mail]>
+	Tested-by: Daniel Axtens <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	tpm: Enable module for all EFI platforms
+	The module is only enabled for x86_64, but there's nothing specific to
+	x86_64 in the implementation and can be enabled for all EFI platforms.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Kiper  <[e-mail]>
+
+	INSTALL/configure: Update install doc and configure comment
+	..to reflect the GRUB build reality in them.
+
+	Additionally, fix text formatting a bit.
+
+	Reviewed-by: Leif Lindholm <[e-mail]>
+
[phone]  Daniel Kiper  <[e-mail]>
+
+	configure: Set gnu99 C language standard by default
+	Commit d5a32255d (misc: Make grub_strtol() "end" pointers have safer
+	const qualifiers) introduced "restrict" keyword into some functions
+	definitions. This keyword was introduced in C99 standard. However, some
+	compilers by default may use C89 or something different. This behavior
+	leads to the breakage during builds when c89 or gnu89 is in force. So,
+	let's set gnu99 C language standard for all compilers by default. This
+	way a bit random build issue will be fixed and the GRUB source will be
+	build consistently regardless of type and version of the compiler.
+
+	It was decided to use gnu99 C language standard because it fixes the
+	issue mentioned above and also provides some useful extensions which are
+	used here and there in the GRUB source. Potentially we can use gnu11
+	too. However, this may reduce pool of older compilers which can be used
+	to build the GRUB. So, let's live with gnu99 until we discover that we
+	strongly require a feature from newer C standard.
+
+	The user is still able to override C language standard using relevant
+	*_CFLAGS variables.
+
+	Reviewed-by: Leif Lindholm <[e-mail]>
+
[phone]  Tianjia Zhang  <[e-mail]>
+
+	tpm: Rename function grub_tpm_log_event() to grub_tpm_measure()
+	grub_tpm_log_event() and grub_tpm_measure() are two functions that
+	have the same effect. So, keep grub_tpm_log_event() and rename it
+	to grub_tpm_measure(). This way we get also a more clear semantics.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Kiper  <[e-mail]>
+
+	autogen: Replace -iname with -ipath in find command
+	..because -iname cannot be used to match paths.
+
+	Reviewed-by: Javier Martinez Canillas <[e-mail]>
+	Reviewed-by: Leif Lindholm <[e-mail]>
+	Reviewed-by: Daniel Axtens <[e-mail]>
+
[phone]  Daniel Kiper  <[e-mail]>
+
+	INSTALL: Update configure example
+	..to make it more relevant.
+
+	Reviewed-by: Leif Lindholm <[e-mail]>
+
[phone]  Daniel Kiper  <[e-mail]>
+
+	configure: Drop unneeded TARGET_CFLAGS expansion
+	Reviewed-by: Javier Martinez Canillas <[e-mail]>
+	Reviewed-by: Leif Lindholm <[e-mail]>
+
[phone]  Jacob Kroon  <[e-mail]>
+
+	docs/grub: Support for probing partition UUID on MSDOS disks
+	Support was implemented in commit c7cb11b21 (probe: Support probing for
+	msdos PARTUUID).
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Tianjia Zhang  <[e-mail]>
+
+	verifiers: Add verify string debug message
+	Like grub_verifiers_open(), the grub_verify_string() should also
+	display this debug message, which is very helpful for debugging.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	envblk: Fix buffer overrun when attempting to shrink a variable value
+	If an existing variable is set with a value whose length is smaller than
+	the current value, a memory corruption can happen due copying padding '#'
+	characters outside of the environment block buffer.
+
+	This is caused by a wrong calculation of the previous free space position
+	after moving backward the characters that followed the old variable value.
+
+	That position is calculated to fill the remaining of the buffer with the
+	padding '#' characters. But since isn't calculated correctly, it can lead
+	to copies outside of the buffer.
+
+	The issue can be reproduced by creating a variable with a large value and
+	then try to set a new value that is much smaller:
+
+	$ grub2-editenv --version
+	grub2-editenv (GRUB) 2.04
+
+	$ grub2-editenv env create
+
+	$ grub2-editenv env set a="$(for i in {1..500}; do var="b$var"; done; echo $var)"
+
+	$ wc -c env
+	1024 grubenv
+
+	$ grub2-editenv env set a="$(for i in {1..50}; do var="b$var"; done; echo $var)"
+	malloc(): corrupted top size
+	Aborted (core dumped)
+
+	$ wc -c env
+	0 grubenv
+
+	Reported-by: Renaud Métrich <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Hans Ulrich Niedermann  <[e-mail]>
+
+	docs: Remove docs for non-existing uppermem command
+	Remove all documentation of and mentions of the uppermem
+	command from the docs/grub.texi file.
+
+	The uppermem command is not implemented in the GRUB source
+	at all and appears to never have been implemented despite
+	former plans to add an uppermem command.
+
+	To reduce user confusion, this even removes the paragraph
+	describing how GRUB's uppermem command was supposed to
+	complement the Linux kernel's mem= parameter.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Hans Ulrich Niedermann  <[e-mail]>
+
+	docs: Remove docs for non-existing pxe_unload command
+	Remove the documentation of the pxe_unload command from the
+	docs/grub.texi file.
+
+	The pxe_unload command is not implemented in the grub source
+	at this time at all. It appears to have been removed in commit
+	671a78acb (cleanup pxe and efi network release).
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Hans Ulrich Niedermann  <[e-mail]>
+
+	gitignore: Add a few forgotten file patterns
+	Add a few patterns to .gitignore to cover files which are generated
+	by building grub ("make", "make check", "make dist") but which have
+	been forgotten to add to .gitignore in the past.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Hans Ulrich Niedermann  <[e-mail]>
+
+	gitignore: Add leading slashes where appropriate
+	Going through the list of gitignore patterns without a leading slash,
+	this adds a leading slash where it appears to have been forgotten.
+
+	Some gitignore patterns like ".deps/" or "Makefile" clearly should
+	match everywhere, so those definitively need no leading slash.
+
+	For some patterns like "ascii.bitmaps", it is unclear where in the
+	source tree they should match. Those patterns are kept as they are,
+	matching the patterns in the whole tree of subdirectories.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Hans Ulrich Niedermann  <[e-mail]>
+
+	gitignore: Add trailing slashes for directories
+	Add trailing slashes for all patterns matching directories.
+
+	Note that we do *not* add trailing slashes for *symlinks*
+	to directories.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Hans Ulrich Niedermann  <[e-mail]>
+
+	gitignore: Sort both pattern groups alphabetically
+	Alphabetically sort the two groups of gitignore patterns:
+
+	  * The group of patterns without slashes, matching anywhere
+	    in the directory subtree.
+
+	  * The group of patterns with slashes, matching relative to the
+	    .gitignore file's directory
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Hans Ulrich Niedermann  <[e-mail]>
+
+	gitignore: Group patterns with and without slash
+	Group the .gitignore patterns into two groups:
+
+	  * Pattern not including a slash, i.e. matching files anywhere in
+	    the .gitignore file's directory and all of its subdirectories.
+
+	  * Patterns including a slash, i.e. matching only relative to the
+	    .gitignore file's directory.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Hans Ulrich Niedermann  <[e-mail]>
+
+	gitignore: Consistent leading slash is easier to read
+	As all gitignore patterns containing a left or middle slash match
+	only relative to the .gitignore file's directory, we write them
+	all in the same manner with a leading slash.
+
+	This makes the file significantly easier to read.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Kiper  <[e-mail]>
+
+	mips/cache: Add missing nop's in delay slots
+	Lack of them causes random instructions to be executed before the
+	jump really happens.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Patrick Steinhardt  <[e-mail]>
+
+	luks2: Propagate error when reading area key fails
+	When decrypting a given keyslot, all error cases except for one set up
+	an error and return the error code. The only exception is when we try to
+	read the area key: instead of setting up an error message, we directly
+	print it via grub_dprintf().
+
+	Convert the outlier to use grub_error() to allow more uniform handling
+	of errors.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Patrick Steinhardt  <[e-mail]>
+
+	json: Get rid of casts for "jsmntok_t"
+	With the upstream change having landed that adds a name to the
+	previously anonymous "jsmntok" typedef, we can now add a forward
+	declaration for that struct in our code. As a result, we no longer have
+	to store the "tokens" member of "struct grub_json" as a void pointer but
+	can instead use the forward declaration, allowing us to get rid of casts
+	of that field.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Patrick Steinhardt  <[e-mail]>
+
+	json: Update jsmn library to upstream commit 053d3cd
+	Update our embedded version of the jsmn library to upstream commit
+	053d3cd (Merge pull request #175 from pks-t/pks/struct-type,
+	2020-04-02).
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Steve Langasek  <[e-mail]>
+
+	templates: Output a menu entry for firmware setup on UEFI FastBoot systems
+	The fwsetup command allows to reboot into the EFI firmware setup menu, add
+	a template to include a menu entry on EFI systems that makes use of that
+	command to reboot into the EFI firmware settings.
+
+	This is useful for users since the hotkey to enter into the EFI setup menu
+	may not be the same on all systems so users can use the menu entry without
+	needing to figure out what key needs to be pressed.
+
+	Also, if fastboot is enabled in the BIOS then often it is not possible to
+	enter the firmware setup menu. So the entry is again useful for this case.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Hans de Goede  <[e-mail]>
+
+	kern/term: Accept ESC, F4 and holding SHIFT as user interrupt keys
+	On some devices the ESC key is the hotkey to enter the BIOS/EFI setup
+	screen, making it really hard to time pressing it right. Besides that
+	ESC is also pretty hard to discover for a user who does not know it
+	will unhide the menu.
+
+	This commit makes F4, which was chosen because is not used as a hotkey
+	to enter the BIOS setup by any vendor, also interrupt sleeps / stop the
+	menu countdown.
+
+	This solves the ESC gets into the BIOS setup and also somewhat solves
+	the discoverability issue, but leaves the timing issue unresolved.
+
+	This commit fixes the timing issue by also adding support for keeping
+	SHIFT pressed during boot to stop the menu countdown. This matches
+	what Ubuntu is doing, which should also help with discoverability.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Hans de Goede  <[e-mail]>
+
+	efi/console: Do not set text-mode until we actually need it
+	If we're running with a hidden menu we may never need text mode, so do not
+	change the video-mode to text until we actually need it.
+
+	This allows to boot a machine without unnecessary graphical transitions and
+	provide a seamless boot experience to users.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Hans de Goede  <[e-mail]>
+
+	efi/console: Implement getkeystatus() support
+	Implement getkeystatus() support in the EFI console driver.
+
+	This is needed because the logic to determine if a key was pressed to make
+	the menu countdown stop will be changed by a later patch to also take into
+	account the SHIFT key being held down.
+
+	For this reason the EFI console driver has to support getkeystatus() to
+	allow detecting that event.
+
+	Note that if a non-modifier key gets pressed and repeated calls to
+	getkeystatus() are made then it will return the modifier status at the
+	time of the non-modifier key, until that key-press gets consumed by a
+	getkey() call.
+
+	This is a side-effect of how the EFI simple-text-input protocol works
+	and cannot be avoided.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Hans de Goede  <[e-mail]>
+
+	efi/console: Add grub_console_read_key_stroke() helper function
+	This is a preparatory patch for adding getkeystatus() support to the
+	EFI console driver.
+
+	We can get modifier status through the simple_text_input read_key_stroke()
+	method, but if a non-modifier key is (also) pressed the read_key_stroke()
+	call will consume that key from the firmware's queue.
+
+	The new grub_console_read_key_stroke() helper buffers upto 1 key-stroke.
+	If it has a non-modifier key buffered, it will return that one, if its
+	buffer is empty, it will fills its buffer by getting a new key-stroke.
+
+	If called with consume=1 it will empty its buffer after copying the
+	key-data to the callers buffer, this is how getkey() will use it.
+
+	If called with consume=0 it will keep the last key-stroke buffered, this
+	is how getkeystatus() will call it. This means that if a non-modifier
+	key gets pressed, repeated getkeystatus() calls will return the modifiers
+	of that key-press until it is consumed by a getkey() call.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Hans de Goede  <[e-mail]>
+
+	kern/term: Make grub_getkeystatus() helper function available everywhere
+	Move grub_getkeystatushelper() function from grub-core/commands/keystatus.c
+	to grub-core/kern/term.c and export it so that it can be used outside of
+	the keystatus command code too.
+
+	There's no logic change in this patch. The function definition is moved so
+	it can be called from grub-core/kern/term.c in a subsequent patch. It will
+	be used to determine if a SHIFT key has was held down and use that also to
+	interrupt the countdown, without the need to press a key at the right time.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	efi/console: Move grub_console_set{colorstate,cursor} higher in the file
+	This is just a preparatory patch to move the functions higher in the file,
+	since these will be called by the grub_prepare_for_text_output() function
+	that will be introduced in a later patch.
+
+	The logic is unchanged by this patch. Functions definitions are just moved
+	to avoid a forward declaration in a later patch, keeping the code clean.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Paul Menzel  <[e-mail]>
+
+	docs/grub: Fix typo in *preferred*
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Axtens  <[e-mail]>
+
+	powerpc/mkimage: Fix CHRP note descsz
+	Currently, an image generated with 'grub-mkimage -n' causes an error when
+	read with 'readelf -a':
+
+	Displaying notes found at file offset 0x000106f0 with length 0x0000002c:
+	  Owner                Data size        Description
+	readelf: Warning: note with invalid namesz and/or descsz found at offset 0x0
+	readelf: Warning:  type: 0x1275, namesize: 0x00000008, descsize: 0x0000002c, alignment: 4
+
+	This is because the descsz of the CHRP note is set to
+	 sizeof (struct grub_ieee1275_note)
+	which is the size of the entire note, including name and elf header. The
+	desczs should contain only the contents, not the name and header sizes.
+
+	Set the descsz instead to 'sizeof (struct grub_ieee1275_note_desc)'
+
+	Resultant readelf output:
+
+	Displaying notes found at file offset 0x00010710 with length 0x0000002c:
+	  Owner                Data size        Description
+	  PowerPC              0x00000018       Unknown note type: (0x00001275)
+	   description data: ff ff ff ff 00 c0 00 00 ff ff ff ff ff ff ff ff ff ff ff ff 00 00 40 00
+
+	So far as I can tell this issue has existed for as long as the note
+	generation code has existed, but I guess nothing really checks descsz.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Flavio Suligoi  <[e-mail]>
+
+	efi: Add missed space in GRUB_EFI_GLOBAL_VARIABLE_GUID
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Michael Chang  <[e-mail]>
+
+	zfs: Fix gcc10 error -Werror=zero-length-bounds
+	We bumped into the build error while testing gcc-10 pre-release.
+
+	In file included from ../../include/grub/file.h:22,
+			from ../../grub-core/fs/zfs/zfs.c:34:
+	../../grub-core/fs/zfs/zfs.c: In function 'zap_leaf_lookup':
+	../../grub-core/fs/zfs/zfs.c:2263:44: error: array subscript '<unknown>' is outside the bounds of an interior zero-length array 'grub_uint16_t[0]' {aka 'short unsigned int[0]'} [-Werror=zero-length-bounds]
+	2263 |   for (chunk = grub_zfs_to_cpu16 (l->l_hash[LEAF_HASH (blksft, h, l)], endian);
+	../../include/grub/types.h:241:48: note: in definition of macro 'grub_le_to_cpu16'
+	 241 | # define grub_le_to_cpu16(x) ((grub_uint16_t) (x))
+	     |                                                ^
+	../../grub-core/fs/zfs/zfs.c:2263:16: note: in expansion of macro 'grub_zfs_to_cpu16'
+	2263 |   for (chunk = grub_zfs_to_cpu16 (l->l_hash[LEAF_HASH (blksft, h, l)], endian);
+	     |                ^~~~~~~~~~~~~~~~~
+	In file included from ../../grub-core/fs/zfs/zfs.c:48:
+	../../include/grub/zfs/zap_leaf.h:72:16: note: while referencing 'l_hash'
+	  72 |  grub_uint16_t l_hash[0];
+	     |                ^~~~~~
+
+	Here I'd like to quote from the gcc document [1] which seems best to
+	explain what is going on here.
+
+	"Although the size of a zero-length array is zero, an array member of
+	this kind may increase the size of the enclosing type as a result of
+	tail padding. The offset of a zero-length array member from the
+	beginning of the enclosing structure is the same as the offset of an
+	array with one or more elements of the same type. The alignment of a
+	zero-length array is the same as the alignment of its elements.
+
+	Declaring zero-length arrays in other contexts, including as interior
+	members of structure objects or as non-member objects, is discouraged.
+	Accessing elements of zero-length arrays declared in such contexts is
+	undefined and may be diagnosed."
+
+	The l_hash[0] is apparnetly an interior member to the enclosed structure
+	while l_entries[0] is the trailing member. And the offending code tries
+	to access members in l_hash[0] array that triggers the diagnose.
+
+	Given that the l_entries[0] is used to get proper alignment to access
+	leaf chunks, we can accomplish the same thing through the ALIGN_UP macro
+	thus eliminating l_entries[0] from the structure. In this way we can
+	pacify the warning as l_hash[0] now becomes the last member to the
+	enclosed structure.
+
+	[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Michael Chang  <[e-mail]>
+
+	mdraid1x_linux: Fix gcc10 error -Werror=array-bounds
+	We bumped into the build error while testing gcc-10 pre-release.
+
+	../../grub-core/disk/mdraid1x_linux.c: In function 'grub_mdraid_detect':
+	../../grub-core/disk/mdraid1x_linux.c:181:15: error: array subscript <unknown> is outside array bounds of 'grub_uint16_t[0]' {aka 'short unsigned int[0]'} [-Werror=array-bounds]
+	  181 |      (char *) &sb.dev_roles[grub_le_to_cpu32 (sb.dev_number)]
+	      |               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+	../../grub-core/disk/mdraid1x_linux.c:98:17: note: while referencing 'dev_roles'
+	   98 |   grub_uint16_t dev_roles[0]; /* Role in array, or 0xffff for a spare, or 0xfffe for faulty.  */
+	      |                 ^~~~~~~~~
+	../../grub-core/disk/mdraid1x_linux.c:127:33: note: defined here 'sb'
+	  127 |       struct grub_raid_super_1x sb;
+	      |                                 ^~
+	cc1: all warnings being treated as errors
+
+	Apparently gcc issues the warning when trying to access sb.dev_roles
+	array's member, since it is a zero length array as the last element of
+	struct grub_raid_super_1x that is allocated sparsely without extra
+	chunks for the trailing bits, so the warning looks legitimate in this
+	regard.
+
+	As the whole thing here is doing offset computation, it is undue to use
+	syntax that would imply array member access then take address from it
+	later. Instead we could accomplish the same thing through basic array
+	pointer arithmetic to pacify the warning.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Simon Hardy  <[e-mail]>
+
+	build: Fix GRUB i386-pc build with Ubuntu gcc
+	With recent versions of gcc on Ubuntu a very large lzma_decompress.img file is
+	output. (e.g. 134479600 bytes instead of 2864.) This causes grub-mkimage to
+	fail with: "error: Decompressor is too big."
+
+	This seems to be caused by a section .note.gnu.property that is placed at an
+	offset such that objcopy needs to pad the img file with zeros.
+
+	This issue is present on:
+	Ubuntu 19.10 with gcc (Ubuntu 8.3.0-26ubuntu1~19.10) 8.3.0
+	Ubuntu 19.10 with gcc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008
+
+	This issue is not present on:
+	Ubuntu 19.10 with gcc (Ubuntu 7.5.0-3ubuntu1~19.10) 7.5.0
+	RHEL 8.0 with gcc 8.3.1 20190507 (Red Hat 8.3.1-4)
+
+	The issue can be fixed by removing the section using objcopy as shown in
+	this patch.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Tianjia Zhang  <[e-mail]>
+
+	efi/tpm: Fix memory leak in grub_tpm1/2_log_event()
+	The memory requested for the event is not released here,
+	causing memory leaks. This patch fixes this problem.
+
+	Reviewed-by: Javier Martinez Canillas <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Michael Chang  <[e-mail]>
+
+	docs: Document notes on LVM cache booting
+	Add notes on LVM cache booting to the GRUB manual to help user understanding
+	the outstanding issue and status.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Michael Chang  <[e-mail]>
+
+	lvm: Add LVM cache logical volume handling
+	The LVM cache logical volume is the logical volume consisting of the original
+	and the cache pool logical volume. The original is usually on a larger and
+	slower storage device while the cache pool is on a smaller and faster one. The
+	performance of the original volume can be improved by storing the frequently
+	used data on the cache pool to utilize the greater performance of faster
+	device.
+
+	The default cache mode "writethrough" ensures that any data written will be
+	stored both in the cache and on the origin LV, therefore grub can be straight
+	to read the original lv as no data loss is guarenteed.
+
+	The second cache mode is "writeback", which delays writing from the cache pool
+	back to the origin LV to have increased performance. The drawback is potential
+	data loss if losing the associated cache device.
+
+	During the boot time grub reads the LVM offline i.e. LVM volumes are not
+	activated and mounted, hence it should be fine to read directly from original
+	lv since all cached data should have been flushed back in the process of taking
+	it offline.
+
+	It is also not much helpful to the situation by adding fsync calls to the
+	install code. The fsync did not force to write back dirty cache to the original
+	device and rather it would update associated cache metadata to complete the
+	write transaction with the cache device. IOW the writes to cached blocks still
+	go only to the cache device.
+
+	To write back dirty cache, as LVM cache did not support dirty cache flush per
+	block range, there'no way to do it for file. On the other hand the "cleaner"
+	policy is implemented and can be used to write back "all" dirty blocks in a
+	cache, which effectively drain all dirty cache gradually to attain and last in
+	the "clean" state, which can be useful for shrinking or decommissioning a
+	cache. The result and effect is not what we are looking for here.
+
+	In conclusion, as it seems no way to enforce file writes to the original
+	device, grub may suffer from power failure as it cannot assemble the cache
+	device and read the dirty data from it. However since the case is only
+	applicable to writeback mode which is sensitive to data lost in nature, I'd
+	still like to propose my (relatively simple) patch and treat reading dirty
+	cache as improvement.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Patrick Steinhardt  <[e-mail]>
+
+	gnulib: Fix build of base64 when compiling with memory debugging
+	When building GRUB with memory management debugging enabled, then the
+	build fails because of `grub_debug_malloc()` and `grub_debug_free()`
+	being undefined in the luks2 module. The cause is that we patch
+	"base64.h" to unconditionaly include "config-util.h", which shouldn't be
+	included for modules at all. As a result, `MM_DEBUG` is defined when
+	building the module, causing it to use the debug memory allocation
+	functions. As these are not built into modules, we end up with a linker
+	error.
+
+	Fix the issue by removing the <config-util.h> include altogether. The
+	sole reason it was included was for the `_GL_ATTRIBUTE_CONST` macro,
+	which we can simply define as empty in case it's not set.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Patrick Steinhardt  <[e-mail]>
+
+	build: Fix option to explicitly disable memory debugging
+	The memory management system supports a debug mode that can be enabled
+	at build time by passing "--enable-mm-debug" to the configure script.
+	Passing the option will cause us define MM_DEBUG as expected, but in
+	fact the reverse option "--disable-mm-debug" will do the exact same
+	thing and also set up the define. This currently causes the build of
+	"lib/gnulib/base64.c" to fail as it tries to use `grub_debug_malloc()`
+	and `grub_debug_free()` even though both symbols aren't defined.
+
+	Seemingly, `AC_ARG_ENABLE()` will always execute the third argument if
+	either the positive or negative option was passed. Let's thus fix the
+	issue by moving the call to`AC_DEFINE()` into an explicit `if test
+	$xenable_mm_debug` block, similar to how other defines work.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+	Reviewed-by: Paul Menzel <[e-mail]>
+
[phone]  David Michael  <[e-mail]>
+
+	fat: Support file modification times
+	This allows comparing file ages on EFI system partitions.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  David Michael  <[e-mail]>
+
+	exfat: Save the matching directory entry struct when searching
+	This provides the node's attributes outside the iterator function
+	so the file modification time can be accessed and reported.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Mike Gilbert  <[e-mail]>
+
+	datetime: Enable the datetime module for the emu platform
+	Fixes a build failure:
+
+	  grub-core/commands/date.c:49: undefined reference to `grub_get_weekday_name'
+	  grub-core/commands/ls.c:155: undefined reference to `grub_unixtime2datetime'
+
+	Bug: https://bugs.gentoo.org/711512
+
+	Reviewed-by: Javier Martinez Canillas <[e-mail]>
+	Tested-by: Javier Martinez Canillas <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  John Paul Adrian Glaubitz  <[e-mail]>
+
+	build: Add soft-float handling for SuperH (sh4)
+	While GRUB has no platform support for SuperH (sh4) yet, this change
+	adds the target-specific handling of soft-floats such that the GRUB
+	utilities can be built on this target.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	efi: Fix the type of grub_efi_status_t
+	Currently, in some builds with some checkers, we see:
+
+	1. grub-core/disk/efi/efidisk.c:601: error[shiftTooManyBitsSigned]: Shifting signed 64-bit value by 63 bits is undefined behaviour
+
+	This is because grub_efi_status_t is defined as grub_efi_intn_t, which is
+	signed, and shifting into the sign bit is not defined behavior.  UEFI fixed
+	this in the spec in 2.3:
+
+	2.3 | Change the defined type of EFI_STATUS from INTN to UINTN | May 7, 2009
+
+	And the current EDK2 code has:
+	MdePkg/Include/Base.h-//
+	MdePkg/Include/Base.h-// Status codes common to all execution phases
+	MdePkg/Include/Base.h-//
+	MdePkg/Include/Base.h:typedef UINTN RETURN_STATUS;
+	MdePkg/Include/Base.h-
+	MdePkg/Include/Base.h-/**
+	MdePkg/Include/Base.h-  Produces a RETURN_STATUS code with the highest bit set.
+	MdePkg/Include/Base.h-
+	MdePkg/Include/Base.h-  @param  StatusCode    The status code value to convert into a warning code.
+	MdePkg/Include/Base.h-                        StatusCode must be in the range 0x00000000..0x7FFFFFFF.
+	MdePkg/Include/Base.h-
+	MdePkg/Include/Base.h-  @return The value specified by StatusCode with the highest bit set.
+	MdePkg/Include/Base.h-
+	MdePkg/Include/Base.h-**/
+	MdePkg/Include/Base.h-#define ENCODE_ERROR(StatusCode)     ((RETURN_STATUS)(MAX_BIT | (StatusCode)))
+	MdePkg/Include/Base.h-
+	MdePkg/Include/Base.h-/**
+	MdePkg/Include/Base.h-  Produces a RETURN_STATUS code with the highest bit clear.
+	MdePkg/Include/Base.h-
+	MdePkg/Include/Base.h-  @param  StatusCode    The status code value to convert into a warning code.
+	MdePkg/Include/Base.h-                        StatusCode must be in the range 0x00000000..0x7FFFFFFF.
+	MdePkg/Include/Base.h-
+	MdePkg/Include/Base.h-  @return The value specified by StatusCode with the highest bit clear.
+	MdePkg/Include/Base.h-
+	MdePkg/Include/Base.h-**/
+	MdePkg/Include/Base.h-#define ENCODE_WARNING(StatusCode)   ((RETURN_STATUS)(StatusCode))
+	MdePkg/Include/Base.h-
+	MdePkg/Include/Base.h-/**
+	MdePkg/Include/Base.h-  Returns TRUE if a specified RETURN_STATUS code is an error code.
+	MdePkg/Include/Base.h-
+	MdePkg/Include/Base.h-  This function returns TRUE if StatusCode has the high bit set.  Otherwise, FALSE is returned.
+	MdePkg/Include/Base.h-
+	MdePkg/Include/Base.h-  @param  StatusCode    The status code value to evaluate.
+	MdePkg/Include/Base.h-
+	MdePkg/Include/Base.h-  @retval TRUE          The high bit of StatusCode is set.
+	MdePkg/Include/Base.h-  @retval FALSE         The high bit of StatusCode is clear.
+	MdePkg/Include/Base.h-
+	MdePkg/Include/Base.h-**/
+	MdePkg/Include/Base.h-#define RETURN_ERROR(StatusCode)     (((INTN)(RETURN_STATUS)(StatusCode)) < 0)
+	...
+	Uefi/UefiBaseType.h:typedef RETURN_STATUS             EFI_STATUS;
+
+	This patch makes grub's implementation match the Edk2 declaration with regards
+	to the signedness of the type.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	efi/gop: Add debug output on GOP probing
+	Add debug information to EFI GOP video driver probing function.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	efi/uga: Use video instead of fb as debug condition
+	All other video drivers use "video" as the debug condition instead of "fb"
+	so change this in the efi/uga driver to make it consistent with the others.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	efi: Print error messages to grub_efi_allocate_pages_real()
+	No messages were printed in this function, add some to ease debugging.
+
+	Also, the function returns a void * pointer so return NULL instead of
+	0 to make the code more readable.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Andrei Borzenkov  <[e-mail]>
+
+	efi/uga: Use 64 bit for fb_base
+	We get 64 bit from PCI BAR but then truncate by assigning to 32 bit.
+	Make sure to check that pointer does not overflow on 32 bit platform.
+
+	Closes: 50931
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Alexander Graf  <[e-mail]>
+
+	efi/gop: Add support for BLT_ONLY adapters
+	EFI GOP has support for multiple different bitness types of frame buffers
+	and for a special "BLT only" type which is always defined to be RGBx.
+
+	Because grub2 doesn't ever directly access the frame buffer but instead
+	only renders graphics via the BLT interface anyway, we can easily support
+	these adapters.
+
+	The reason this has come up now is the emerging support for virtio-gpu
+	in OVMF. That adapter does not have the notion of a memory mapped frame
+	buffer and thus is BLT only.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	normal/completion: Fix possible NULL pointer dereference
+	Coverity Scan reports that the grub_strrchr() function can return NULL if
+	the character is not found. Check if that's the case for dirfile pointer.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	kern: Add grub_debug_enabled()
+	Add a grub_debug_enabled() helper function instead of open coding it.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	Makefile: Make libgrub.pp depend on config-util.h
+	If you build with "make -j48" a lot, sometimes you see:
+
+	gcc -E -DHAVE_CONFIG_H -I. -I..  -Wall -W -DGRUB_UTIL=1 -D_FILE_OFFSET_BITS=64 -I./include -DGRUB_FILE=\"grub_script.tab.h\" -I. -I.. -I. -I.. -I../include -I./include -I../grub-core/lib/libgcrypt-grub/src/  -I../grub-core/lib/minilzo -I../grub-core/lib/xzembed -DMINILZO_HAVE_CONFIG_H -Wall -W -DGRUB_UTIL=1 -D_FILE_OFFSET_BITS=64 -I./include -DGRUB_FILE=\"grub_script.tab.h\" -I. -I.. -I. -I.. -I../include -I./include -I../grub-core/lib/libgcrypt-grub/src/  -I./grub-core/gnulib -I../grub-core/gnulib -I/builddir/build/BUILD/grub-2.02/grub-aarch64-efi-2.02 -D_FILE_OFFSET_BITS=64 \
+	  -D'GRUB_MOD_INIT(x)=@MARKER@x@' grub_script.tab.h grub_script.yy.h ../grub-core/commands/blocklist.c ../grub-core/commands/macbless.c ../grub-core/commands/xnu_uuid.c ../grub-core/commands/testload.c ../grub-core/commands/ls.c ../grub-core/disk/dmraid_nvidia.c ../grub-core/disk/loopback.c ../grub-core/disk/lvm.c ../grub-core/disk/mdraid_linux.c ../grub-core/disk/mdraid_linux_be.c ../grub-core/disk/mdraid1x_linux.c ../grub-core/disk/raid5_recover.c ../grub-core/disk/raid6_recover.c ../grub-core/font/font.c ../grub-core/gfxmenu/font.c ../grub-core/normal/charset.c ../grub-core/video/fb/fbblit.c ../grub-core/video/fb/fbutil.c ../grub-core/video/fb/fbfill.c ../grub-core/video/fb/video_fb.c ../grub-core/video/video.c ../grub-core/video/capture.c ../grub-core/video/colors.c ../grub-core/unidata.c ../grub-core/io/bufio.c ../grub-core/fs/affs.c ../grub-core/fs/afs.c ../grub-core/fs/bfs.c ../grub-core/fs/btrfs.c ../grub-core/fs/cbfs.c ../grub-core/fs/cpio.c ../grub-core/fs/cpio_be.c ../grub-core/fs/odc.c ../grub-core/fs/newc.c ../grub-core/fs/ext2.c ../grub-core/fs/fat.c ../grub-core/fs/exfat.c ../grub-core/fs/fshelp.c ../grub-core/fs/hfs.c ../grub-core/fs/hfsplus.c ../grub-core/fs/hfspluscomp.c ../grub-core/fs/iso9660.c ../grub-core/fs/jfs.c ../grub-core/fs/minix.c ../grub-core/fs/minix2.c ../grub-core/fs/minix3.c ../grub-core/fs/minix_be.c ../grub-core/fs/minix2_be.c ../grub-core/fs/minix3_be.c ../grub-core/fs/nilfs2.c ../grub-core/fs/ntfs.c ../grub-core/fs/ntfscomp.c ../grub-core/fs/reiserfs.c ../grub-core/fs/romfs.c ../grub-core/fs/sfs.c ../grub-core/fs/squash4.c ../grub-core/fs/tar.c ../grub-core/fs/udf.c ../grub-core/fs/ufs2.c ../grub-core/fs/ufs.c ../grub-core/fs/ufs_be.c ../grub-core/fs/xfs.c ../grub-core/fs/zfs/zfscrypt.c ../grub-core/fs/zfs/zfs.c ../grub-core/fs/zfs/zfsinfo.c ../grub-core/fs/zfs/zfs_lzjb.c ../grub-core/fs/zfs/zfs_lz4.c ../grub-core/fs/zfs/zfs_sha256.c ../grub-core/fs/zfs/zfs_fletcher.c ../grub-core/lib/envblk.c ../grub-core/lib/hexdump.c ../grub-core/lib/LzFind.c ../grub-core/lib/LzmaEnc.c ../grub-core/lib/crc.c ../grub-core/lib/adler32.c ../grub-core/lib/crc64.c ../grub-core/normal/datetime.c ../grub-core/normal/misc.c ../grub-core/partmap/acorn.c ../grub-core/partmap/amiga.c ../grub-core/partmap/apple.c ../grub-core/partmap/sun.c ../grub-core/partmap/plan.c ../grub-core/partmap/dvh.c ../grub-core/partmap/sunpc.c ../grub-core/partmap/bsdlabel.c ../grub-core/partmap/dfly.c ../grub-core/script/function.c ../grub-core/script/lexer.c ../grub-core/script/main.c ../grub-core/script/script.c ../grub-core/script/argv.c ../grub-core/io/gzio.c ../grub-core/io/xzio.c ../grub-core/io/lzopio.c ../grub-core/kern/ia64/dl_helper.c ../grub-core/kern/arm/dl_helper.c ../grub-core/kern/arm64/dl_helper.c ../grub-core/lib/minilzo/minilzo.c ../grub-core/lib/xzembed/xz_dec_bcj.c ../grub-core/lib/xzembed/xz_dec_lzma2.c ../grub-core/lib/xzembed/xz_dec_stream.c ../util/misc.c ../grub-core/kern/command.c ../grub-core/kern/device.c ../grub-core/kern/disk.c ../grub-core/lib/disk.c ../util/getroot.c ../grub-core/osdep/unix/getroot.c ../grub-core/osdep/getroot.c ../grub-core/osdep/devmapper/getroot.c ../grub-core/osdep/relpath.c ../grub-core/kern/emu/hostdisk.c ../grub-core/osdep/devmapper/hostdisk.c ../grub-core/osdep/hostdisk.c ../grub-core/osdep/unix/hostdisk.c ../grub-core/osdep/exec.c ../grub-core/osdep/sleep.c ../grub-core/osdep/password.c ../grub-core/kern/emu/misc.c ../grub-core/kern/emu/mm.c ../grub-core/kern/env.c ../grub-core/kern/err.c ../grub-core/kern/file.c ../grub-core/kern/fs.c ../grub-core/kern/list.c ../grub-core/kern/misc.c ../grub-core/kern/partition.c ../grub-core/lib/crypto.c ../grub-core/disk/luks.c ../grub-core/disk/geli.c ../grub-core/disk/cryptodisk.c ../grub-core/disk/AFSplitter.c ../grub-core/lib/pbkdf2.c ../grub-core/commands/extcmd.c ../grub-core/lib/arg.c ../grub-core/disk/ldm.c ../grub-core/disk/diskfilter.c ../grub-core/partmap/gpt.c ../grub-core/partmap/msdos.c ../grub-core/fs/proc.c ../grub-core/fs/archelp.c > libgrub.pp || (rm -f libgrub.pp; exit 1)
+	rm -f stamp-h1
+	touch ../config-util.h.in
+	cd . && /bin/sh ./config.status config-util.h
+	config.status: creating config-util.h
+	In file included from ../include/grub/mm.h:25:0,
+	                 from ../include/grub/disk.h:29,
+	                 from ../include/grub/file.h:26,
+	                 from ../grub-core/fs/btrfs.c:21:
+	./config.h:38:10: fatal error: ./config-util.h: No such file or directory
+	 #include <config-util.h>
+	          ^~~~~~~~~~~~~~~
+	compilation terminated.
+	make: *** [Makefile:13098: libgrub.pp] Error 1
+
+	This is because libgrub.pp is built with -DGRUB_UTIL=1, which means
+	it'll try to include config-util.h, but a parallel make is actually
+	building that file.  I think.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	efi: Print more debug info in our module loader
+	The function that searches the mods section base address does not have
+	any debug information. Add some debugging outputs that could be useful.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	linux/getroot: Handle rssd storage device names
+	The Micron PCIe SSDs Linux driver (mtip32xx) exposes block devices
+	as /dev/rssd[a-z]+[0-9]*. Add support for these rssd device names.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Julian Andres Klode  <[e-mail]>
+
+	smbios: Add a --linux argument to apply linux modalias-like filtering
+	Linux creates modalias strings by filtering out non-ASCII, space,
+	and colon characters. Provide an option that does the same filtering
+	so people can create a modalias string in GRUB, and then match their
+	modalias patterns against it.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Mike Gilbert  <[e-mail]>
+
+	po: Fix replacement of %m in sed programs
+	When running make dist, I hit this error:
+
+	  rm -f [e-mail] && /usr/bin/gmsgfmt -c --statistics --verbose -o [e-mail] [e-mail]
+	  [e-mail]:5312: 'msgstr' is not a valid C format string, unlike 'msgid'.
+	  Reason: The character that terminates the directive number 3 is not a valid conversion specifier.
+	  /usr/bin/gmsgfmt: found 1 fatal error
+
+	This was caused by "%m" being replaced with foreign Unicode characters.
+	For example:
+
+	  msgid "cannot rename the file %s to %s: %m"
+	  msgstr "ﺹﺎﻨﻧﻮﺗ ﺮﻌﻧﺎﻤﻋ ﺖﻬﻋ ﻒִﻴﻠﻋ %s ﺕﻭ %s: %ﻡ"
+
+	Mimic the workaround used for "%s" by reversing the replacement of "%m" at
+	the end of the sed programs.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Colin Watson  <[e-mail]>
+
+	gettext: Restore patches to po/Makefile.in.in
+	These were inadvertently lost during the conversion to Gnulib (gnulib:
+	Upgrade Gnulib and switch to bootstrap tool; commit 35b909062). The
+	files in po/gettext-patches/ can be imported using "git am" on top of
+	the gettext tag corresponding to AM_GNU_GETTEXT_VERSION in configure.ac
+	(currently 0.18.3). They handle translation of messages in shell files,
+	make msgfmt output in little-endian format, and arrange to use @SHELL@
+	rather than /bin/sh.
+
+	There were some changes solely for the purpose of distributing extra
+	files; for ease of maintenance, I've added these to
+	conf/Makefile.extra-dist instead.
+
+	Fixes: https://savannah.gnu.org/bugs/?57298
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	misc: Make grub_strtol() "end" pointers have safer const qualifiers
+	Currently the string functions grub_strtol(), grub_strtoul(), and
+	grub_strtoull() don't declare the "end" pointer in such a way as to
+	require the pointer itself or the character array to be immutable to the
+	implementation, nor does the C standard do so in its similar functions,
+	though it does require us not to change any of it.
+
+	The typical declarations of these functions follow this pattern:
+
+	long
+	strtol(const char * restrict nptr, char ** restrict endptr, int base);
+
+	Much of the reason for this is historic, and a discussion of that
+	follows below, after the explanation of this change.  (GRUB currently
+	does not include the "restrict" qualifiers, and we name the arguments a
+	bit differently.)
+
+	The implementation is semantically required to treat the character array
+	as immutable, but such accidental modifications aren't stopped by the
+	compiler, and the semantics for both the callers and the implementation
+	of these functions are sometimes also helped by adding that requirement.
+
+	This patch changes these declarations to follow this pattern instead:
+
+	long
+	strtol(const char * restrict nptr,
+	       const char ** const restrict endptr,
+	       int base);
+
+	This means that if any modification to these functions accidentally
+	introduces either an errant modification to the underlying character
+	array, or an accidental assignment to endptr rather than *endptr, the
+	compiler should generate an error.  (The two uses of "restrict" in this
+	case basically mean strtol() isn't allowed to modify the character array
+	by going through *endptr, and endptr isn't allowed to point inside the
+	array.)
+
+	It also means the typical use case changes to:
+
+	  char *s = ...;
+	  const char *end;
+	  long l;
+
+	  l = strtol(s, &end, 10);
+
+	Or even:
+
+	  const char *p = str;
+	  while (p && *p) {
+		  long l = strtol(p, &p, 10);
+		  ...
+	  }
+
+	This fixes 26 places where we discard our attempts at treating the data
+	safely by doing:
+
+	  const char *p = str;
+	  long l;
+
+	  l = strtol(p, (char **)&ptr, 10);
+
+	It also adds 5 places where we do:
+
+	  char *p = str;
+	  while (p && *p) {
+		  long l = strtol(p, (const char ** const)&p, 10);
+		  ...
+		  /* more calls that need p not to be pointer-to-const */
+	  }
+
+	While moderately distasteful, this is a better problem to have.
+
+	With one minor exception, I have tested that all of this compiles
+	without relevant warnings or errors, and that /much/ of it behaves
+	correctly, with gcc 9 using 'gcc -W -Wall -Wextra'.  The one exception
+	is the changes in grub-core/osdep/aros/hostdisk.c , which I have no idea
+	how to build.
+
+	Because the C standard defined type-qualifiers in a way that can be
+	confusing, in the past there's been a slow but fairly regular stream of
+	churn within our patches, which add and remove the const qualifier in many
+	of the users of these functions.  This change should help avoid that in
+	the future, and in order to help ensure this, I've added an explanation
+	in misc.h so that when someone does get a compiler warning about a type
+	error, they have the fix at hand.
+
+	The reason we don't have "const" in these calls in the standard is
+	purely anachronistic: C78 (de facto) did not have type qualifiers in the
+	syntax, and the "const" type qualifier was added for C89 (I think; it
+	may have been later).  strtol() appears to date from 4.3BSD in 1986,
+	which means it could not be added to those functions in the standard
+	without breaking compatibility, which is usually avoided.
+
+	The syntax chosen for type qualifiers is what has led to the churn
+	regarding usage of const, and is especially confusing on string
+	functions due to the lack of a string type.  Quoting from C99, the
+	syntax is:
+
+	 declarator:
+	  pointer[opt] direct-declarator
+	 direct-declarator:
+	  identifier
+	  ( declarator )
+	  direct-declarator [ type-qualifier-list[opt] assignment-expression[opt] ]
+	  ...
+	  direct-declarator [ type-qualifier-list[opt] * ]
+	  ...
+	 pointer:
+	  * type-qualifier-list[opt]
+	  * type-qualifier-list[opt] pointer
+	 type-qualifier-list:
+	  type-qualifier
+	  type-qualifier-list type-qualifier
+	 ...
+	 type-qualifier:
+	  const
+	  restrict
+	  volatile
+
+	So the examples go like:
+
+	const char foo;			// immutable object
+	const char *foo;		// mutable pointer to object
+	char * const foo;		// immutable pointer to mutable object
+	const char * const foo;		// immutable pointer to immutable object
+	const char const * const foo; 	// XXX extra const keyword in the middle
+	const char * const * const foo; // immutable pointer to immutable
+					//   pointer to immutable object
+	const char ** const foo;	// immutable pointer to mutable pointer
+					//   to immutable object
+
+	Making const left-associative for * and right-associative for everything
+	else may not have been the best choice ever, but here we are, and the
+	inevitable result is people using trying to use const (as they should!),
+	putting it at the wrong place, fighting with the compiler for a bit, and
+	then either removing it or typecasting something in a bad way.  I won't
+	go into describing restrict, but its syntax has exactly the same issue
+	as with const.
+
+	Anyway, the last example above actually represents the *behavior* that's
+	required of strtol()-like functions, so that's our choice for the "end"
+	pointer.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Mike Gilbert  <[e-mail]>
+
+	build: Disable PIE in TARGET_CCASFLAGS if needed
+	PIE should be disabled in assembly sources as well, or else GRUB will
+	fail to boot.
+
+	Bug: https://bugs.gentoo.org/667852
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+	Tested-by: John Paul Adrian Glaubitz <[e-mail]>
+
[phone]  Mike Gilbert  <[e-mail]>
+
+	build: Move TARGET_* assignments earlier
+	On a 32-bit SPARC userland, configure fails to compile assembly and the
+	build fails:
+
+	    checking for options to compile assembly... configure: error: could not compile assembly
+
+	config.log shows:
+
+	    asm-tests/sparc64.S: Assembler messages:
+	    asm-tests/sparc64.S:5: Error: Architecture mismatch on "lduw [%o4+4],%o4".
+	    asm-tests/sparc64.S:5: (Requires v9|v9a|v9b|v9c|v9d|v9e|v9v|v9m|m8; requested architecture is sparclite.)
+	    asm-tests/sparc64.S:7: Error: Architecture mismatch on "stw %o5,[%o3]".
+	    asm-tests/sparc64.S:7: (Requires v9|v9a|v9b|v9c|v9d|v9e|v9v|v9m|m8; requested architecture is sparclite.)
+	    asm-tests/sparc64.S:8: Error: Architecture mismatch on "bne,pt %icc,1b ,pt %icc,1b".
+	    asm-tests/sparc64.S:8: (Requires v9|v9a|v9b|v9c|v9d|v9e|v9v|v9m|m8; requested architecture is sparclite.)
+
+	Simply moving these blocks earlier in configure.ac is sufficient to
+	ensure that the tests are executed with the appropriate flags
+	(specifically -m64 in this case).
+
+	Bug: https://bugs.gentoo.org/667850
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+	Tested-by: John Paul Adrian Glaubitz <[e-mail]>
+
[phone]  Patrick Steinhardt  <[e-mail]>
+
+	luks2: Add missing newline to debug message
+	The debug message printed when decryption with a keyslot fails is
+	missing its trailing newline. Add it to avoid mangling it with
+	subsequent output.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Michael Chang  <[e-mail]>
+
+	verifiers: Fix calling uninitialized function pointer
+	The necessary check for NULL before use of function ver->close is not
+	taking place in the failure path. This patch simply adds the missing
+	check and fixes the problem that GRUB hangs indefinitely after booting
+	rogue image without valid signature if secure boot is turned on.
+
+	Now it displays like this for booting rogue UEFI image:
+
+	  error: bad shim signature
+	  error: you need to load the kernel first
+
+	  Press any key to continue...
+
+	and then you can go back to boot menu by pressing any key or after a few
+	seconds expired.
+
+	Reviewed-by: Javier Martinez Canillas <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	grub-editenv: Make grub-editenv chase symlinks including those across devices
+	The grub-editenv create command will wrongly overwrite /boot/grub2/grubenv
+	with a regular file if grubenv is a symbolic link. But instead, it should
+	create a new file in the path the symlink points to.
+
+	This lets /boot/grub2/grubenv be a symlink to /boot/efi/EFI/fedora/grubenv
+	even when they're different mount points, which allows grub2-editenv to be
+	the same across platforms (i.e. UEFI vs BIOS).
+
+	For example, in Fedora the GRUB EFI builds have prefix set to /EFI/fedora
+	(on the EFI System Partition), but for BIOS machine it'll be /boot/grub2
+	(which may or may not be its own mountpoint).
+
+	With this patch, on EFI machines we can make /boot/grub2/grubenv a symlink
+	to /boot/efi/EFI/fedora/grubenv, and the same copy of grub-set-default will
+	work on both kinds of systems.
+
+	Windows doesn't implement a readlink primitive, so the current behaviour is
+	maintained for this operating system.
+
+	Reviewed-by: Adam Jackson <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	grub-editenv: Add grub_util_readlink()
+	Currently grub-editenv and related tools are not able to follow symbolic
+	links when finding their config file. For example the grub-editenv create
+	command will wrongly overwrite a symlink in /boot/grub2/grubenv with a new
+	regular file, instead of creating a file in the path the symlink points to.
+
+	A following patch will change that and add support in grub-editenv to
+	follow symbolic links when finding the grub environment variables file.
+
+	Add a grub_util_readlink() helper function that is just a wrapper around
+	the platform specific function to read the value of a symbolic link. This
+	helper function will be used by the following patch for grub-editenv.
+
+	The helper function is not added for Windows, since this operating system
+	doesn't have a primitive to read the contents of a symbolic link.
+
+	Reviewed-by: Adam Jackson <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Robert Marshall  <[e-mail]>
+
+	docs: Update info with grub.cfg netboot selection order
+	Add documentation to the GRUB manual that specifies the order netboot
+	clients use to select a GRUB configuration file.
+
+	Also explain that the feature is enabled by default but can be disabled
+	by setting the "feature_net_search_cfg" environment variable to "n" in
+	an embedded configuration file.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Paulo Flabiano Smorigo  <[e-mail]>
+
+	normal/main: Search for specific config files for netboot
+	This patch implements a search for a specific configuration when the config
+	file is on a remoteserver. It uses the following order:
+	   1) DHCP client UUID option.
+	   2) MAC address (in lower case hexadecimal with dash separators);
+	   3) IP (in upper case hexadecimal) or IPv6;
+	   4) The original grub.cfg file.
+
+	This procedure is similar to what is used by pxelinux and yaboot:
+	http://www.syslinux.org/wiki/index.php/PXELINUX#config
+
+	It is enabled by default but can be disabled by setting the environment
+	variable "feature_net_search_cfg" to "n" in an embedded configuration.
+
+	Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=873406
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Paulo Flabiano Smorigo  <[e-mail]>
+
+	net/dhcp: Set net_<interface>_client{id, uuid} variables from DHCP options
+	This patch sets a net_<interface>_clientid and net_<interface>_clientuuid
+	GRUB environment variables, using the DHCP client ID and UUID options if
+	these are found.
+
+	In the same way than net_<interface>_<option> variables are set for other
+	options such domain name, boot file, next server, etc.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	net/dhcp: Consistently use decimal numbers for DHCP/BOOTP options enum
+	The DHCP Options and BOOTP Vendor Extensions enum values are a mixture of
+	decimal and hexadecimal numbers. Change this to consistently use decimal
+	numbers for all since that is how these values are defined by RFC 2132.
+
+	Suggested-by: Daniel Kiper <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Paulo Flabiano Smorigo  <[e-mail]>
+
+	kern: Add %X option to printf functions
+	The printf(3) function has support for the %X format specifier, to output
+	an unsigned hexadecimal integer in uppercase.
+
+	This can be achived in GRUB using the %x format specifier in grub_printf()
+	and calling grub_toupper(), but it is more convenient if there is support
+	for %X in grub_printf().
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Javier Martinez Canillas  <[e-mail]>
+
+	normal: Move common datetime functions out of the normal module
+	The common datetime helper functions are currently included in the normal
+	module, but this makes any other module that calls these functions to have
+	a dependency with the normal module only for this reason.
+
+	Since the normal module does a lot of stuff, it calls functions from other
+	modules. But since other modules may depend on it for calling the datetime
+	helpers, this could lead to circular dependencies between modules.
+
+	As an example, when platform == xen the grub_get_datetime() function from
+	the datetime module calls to the grub_unixtime2datetime() helper function
+	from the normal module. Which leads to the following module dependency:
+
+	    datetime -> normal
+
+	and send_dhcp_packet() from the net module calls the grub_get_datetime()
+	function, which leads to the following module dependency:
+
+	    net -> datetime -> normal
+
+	but that means that the normal module is not allowed to depend on net or
+	any other module that depends on it due the transitive dependency caused
+	by datetime. A recent patch attempted to add support to fetch the config
+	file over the network, which leads to the following circular dependency:
+
+	    normal -> net -> datetime -> normal
+
+	So having the datetime helpers in the normal module makes it quite fragile
+	and easy to add circular dependencies like these, that break the build due
+	the genmoddep.awk script catching the issues.
+
+	Fix this by taking the datetime helper functions out of the normal module
+	and instead add them to the datetime module itself. Besides fixing these
+	issues, it makes more sense to have these helper functions there anyways.
+
+	Reported-by: Daniel Kiper <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	minilzo: Update to minilzo-2.08
+	This patch updates the miniLZO library to a newer version, which among other
+	things fixes "CVE-2014-4607 - lzo: lzo1x_decompress_safe() integer overflow"
+	that is present in the current used in GRUB.
+
+	It also updates the "GRUB Developers Manual", to mention that the library is
+	used and describes the process to update it to a newer release when needed.
+
+	Resolves: http://savannah.gnu.org/bugs/?42635
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Peter Jones  <[e-mail]>
+
+	squash4: Fix an uninitialized variable
+	gcc says:
+
+	grub-core/fs/squash4.c: In function ‘direct_read’:
+	grub-core/fs/squash4.c:868:10: error: ‘err’ may be used uninitialized in
+	this function [-Werror=maybe-uninitialized]
+	  868 |       if (err)
+	      |          ^
+	cc1: all warnings being treated as errors
+
+	This patch initializes it to GRUB_ERR_NONE.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  C. Masloch  <[e-mail]>
+
+	freedos: Fix FreeDOS command booting large files (near or above 64 KiB)
+	While testing the 86-DOS lDebug [1] booting from GRUB2, newer versions of the
+	debugger would fail to load when booted using GRUB's freedos command. The
+	behaviour observed in a qemu i386 machine was that the ROM-BIOS's boot load
+	would start anew, instead of loading the selected debugger as kernel.
+
+	It came to light that there was a size limit: Kernel files that were 58880
+	bytes (E600h) long or shorter succeeded to boot, while files that were 64000
+	bytes or longer failed in the manner described.
+
+	Eventually it turned out that the relocator16 stub succeeded whenever it was
+	placed completely within the first 64 KiB of the Low Memory Area. The chunk
+	for the relocator is allocated with a minimum address of 0x8010 and a maximum
+	address just below 0xA0000 [2]. That means if the kernel is, for instance,
+	E600h bytes long, then the kernel will be allocated memory starting at 00600h
+	(the fixed FreeDOS kernel load address) up to E600h + 00600h = 0EC00h, which
+	leaves 1400h (5120) bytes for the relocator to stay in the first 64 KiB.
+	If the kernel is 64000 bytes (FA00h) long, then the relocator must go to
+	FA00h + 00600h = 10000h at least which is outside the first 64 KiB.
+
+	The problem is that the relocator16 initialises the DS register with a
+	"pseudo real mode" descriptor, which is defined with a segment limit of
+	64 KiB and a segment base of zero. After that, the relocator addressed
+	parts of itself (implicitly) using the DS register, with an offset from
+	ESI, which holds the linear address of the relocator's base [3]. With the
+	larger kernel files this would lead to accessing data beyond the 64 KiB
+	segment limit, presumably leading to a fault and perhaps a subsequent
+	triple-fault or such.
+
+	This patch fixes the relocator to set the segment base of the descriptors
+	to the base address of the relocator; then, the subsequent accesses to
+	the relocator's variables are done without the ESI register as an index.
+	This does not interfere with the relocator's or its target's normal
+	operation; the segment limits are still loaded with 64 KiB and all the
+	segment bases are subsequently reset by the relocator anyway.
+
+	Current versions of the debugger to test are uploaded to [4]. The file
+	ldebugnh.com (LZ4-compressed and built with -D_EXTHELP=0) at 58368 bytes
+	loads successfully, whereas ldebug.com at 64000 bytes fails. Loading one
+	of these files requires setting root to a FAT FS partition and using the
+	freedos command to specify the file as kernel:
+
+	set root='(hd0,msdos1)'
+	freedos /ldebug.com
+	boot
+
+	Booting the file using the multiboot command (which uses a WIP entrypoint
+	of the debugger) works, as it does not use GRUB's relocator16 but instead
+	includes a loader in the kernel itself, which drops it back to 86 Mode.
+
+	[1]: https://hg.ulukai.org/ecm/ldebug
+	[2]: http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/lib/i386/relocator.c?id=495781f5ed1b48bf27f16c53940d6700c181c74c#n127
+	[3]: http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/lib/i386/relocator16.S?id=495781f5ed1b48bf27f16c53940d6700c181c74c#n97
+	[4]: https://ulukai.org/ecm/lDebug-5479a7988d21-nohelp.zip
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Patrick Steinhardt  <[e-mail]>
+
+	disk: Implement support for LUKS2
+	With cryptsetup 2.0, a new version of LUKS was introduced that breaks
+	compatibility with the previous version due to various reasons. GRUB
+	currently lacks any support for LUKS2, making it impossible to decrypt
+	disks encrypted with that version. This commit implements support for
+	this new format.
+
+	Note that LUKS1 and LUKS2 are quite different data formats. While they
+	do share the same disk signature in the first few bytes, representation
+	of encryption parameters is completely different between both versions.
+	While the former version one relied on a single binary header, only,
+	LUKS2 uses the binary header only in order to locate the actual metadata
+	which is encoded in JSON. Furthermore, the new data format is a lot more
+	complex to allow for more flexible setups, like e.g. having multiple
+	encrypted segments and other features that weren't previously possible.
+	Because of this, it was decided that it doesn't make sense to keep both
+	LUKS1 and LUKS2 support in the same module and instead to implement it
+	in two different modules luks and luks2.
+
+	The proposed support for LUKS2 is able to make use of the metadata to
+	decrypt such disks. Note though that in the current version, only the
+	PBKDF2 key derival function is supported. This can mostly attributed to
+	the fact that the libgcrypt library currently has no support for either
+	Argon2i or Argon2id, which are the remaining KDFs supported by LUKS2. It
+	wouldn't have been much of a problem to bundle those algorithms with
+	GRUB itself, but it was decided against that in order to keep down the
+	number of patches required for initial LUKS2 support. Adding it in the
+	future would be trivial, given that the code structure is already in
+	place.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Patrick Steinhardt  <[e-mail]>
+
+	luks: Move configuration of ciphers into cryptodisk
+	The luks module contains quite a lot of logic to parse cipher and
+	cipher-mode strings like aes-xts-plain64 into constants to apply them
+	to the grub_cryptodisk_t structure. This code will be required by the
+	upcoming luks2 module, as well, which is why this commit moves it into
+	its own function grub_cryptodisk_setcipher in the cryptodisk module.
+	While the strings are probably rather specific to the LUKS modules, it
+	certainly does make sense that the cryptodisk module houses code to set
+	up its own internal ciphers instead of hosting that code in the luks
+	module.
+
+	Except for necessary adjustments around error handling, this commit does
+	an exact move of the cipher configuration logic from luks.c to
+	cryptodisk.c. Any behavior changes are unintentional.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Patrick Steinhardt  <[e-mail]>
+
+	afsplitter: Move into its own module
+	While the AFSplitter code is currently used only by the luks module,
+	upcoming support for luks2 will add a second module that depends on it.
+	To avoid any linker errors when adding the code to both modules because
+	of duplicated symbols, this commit moves it into its own standalone
+	module afsplitter as a preparatory step.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Patrick Steinhardt  <[e-mail]>
+
+	bootstrap: Add gnulib's base64 module
+	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>.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Patrick Steinhardt  <[e-mail]>
+
+	json: Implement wrapping interface
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Patrick Steinhardt  <[e-mail]>
+
+	json: Import upstream jsmn-1.1.0
+	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
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Lukasz Hawrylko  <[e-mail]>
+
+	multiboot2: Set min address for mbi allocation to 0x1000
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Paul Menzel  <[e-mail]>
+
+	docs: Export "superusers" variable to apply to submenus
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Daniel Kiper  <[e-mail]>
+
+	loader/i386/linux: Fix an underflow in the setup_header length calculation
+	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: e683cfb0cf5 (loader/i386/linux: Calculate the setup_header length)
+
+	Reviewed-by: Javier Martinez Canillas <[e-mail]>
+	Reviewed-by: Ross Philipson <[e-mail]>
+	Reviewed-by: Krystian Hebel <[e-mail]>
+
[phone]  David Sterba  <[e-mail]>
+
+	btrfs: Add support for new RAID1C34 profiles
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Lenny Szubowicz  <[e-mail]>
+
+	tftp: Normalize slashes in TFTP paths
+	Some TFTP servers do not handle multiple consecutive slashes correctly.
+	This patch avoids sending TFTP requests with non-normalized paths.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Michael Chang  <[e-mail]>
+
+	grub-editenv: Warn a user against editing environment block
+	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.
+
+	Reviewed-by: Javier Martinez Canillas <[e-mail]>
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Michael Chang  <[e-mail]>
+
+	hostdisk: Set linux file descriptor to O_CLOEXEC as default
+	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.
+
+	Reviewed-by: Daniel Kiper <[e-mail]>
+
[phone]  Eli Schwartz  <[e-mail]>
+
+	grub-mkconfig: Use portable "command -v" to detect installed programs
+	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