All other architectures have start symbol.

Hopefully this resolves:

    BUILDSTDERR: ././grub-mkimage: error: undefined symbol start.

Signed-off-by: David Abdurachmanov <[email protected]>

The python-unversioned-command package is not installed in the buildroot,
but the bootstrap script expects the python command to be present if one
is not defined. So building the package leads to the following error:

./autogen.sh: line 20: python: command not found

This is harmless since gnulib is included as a source anyways, because the
builders can't download. But still the issue should be fixed by forcing to
use python3 that's the default in Fedora now.

Signed-off-by: Javier Martinez Canillas <[email protected]>

The fw_path environment variable is used by http_configure() function to
determine the HTTP path that should be used as prefix when using relative
HTTP paths. And this is stored in the http_path environment variable.

Later, that variable is looked up by grub_efihttp_open() to generate the
complete path to be used in the HTTP request.

But these variables are not exported, which means that are not global and
so are only found in the initial context.

This can cause commands like configfile that create a new context to fail
because the fw_path and http_path variables will not be found.

Resolves: rhbz#1616395

Signed-off-by: Javier Martinez Canillas <[email protected]>

According to RFC 2732 (https://www.ietf.org/rfc/rfc2732.txt), literal IPv6
addresses must be enclosed in square brackets. But GRUB currently does not
do this and is causing HTTP servers to send Bad Request (400) responses.

For example, the following is the HTTP stream when fetching a config file:

HEAD /EFI/BOOT/grub.cfg HTTP/1.1
Host: 2000:dead:beef:a::1
Accept: */*
User-Agent: UefiHttpBoot/1.0

HTTP/1.1 400 Bad Request
Date: Thu, 05 Mar 2020 14:46:02 GMT
Server: Apache/2.4.41 (Fedora) OpenSSL/1.1.1d
Connection: close
Content-Type: text/html; charset=iso-8859-1

and after enclosing the IPv6 address the HTTP request is successful:

HEAD /EFI/BOOT/grub.cfg HTTP/1.1
Host: [2000:dead:beef:a::1]
Accept: */*
User-Agent: UefiHttpBoot/1.0

HTTP/1.1 200 OK
Date: Thu, 05 Mar 2020 14:48:04 GMT
Server: Apache/2.4.41 (Fedora) OpenSSL/1.1.1d
Last-Modified: Thu, 27 Feb 2020 17:45:58 GMT
ETag: "206-59f924b24b1da"
Accept-Ranges: bytes
Content-Length: 518

Resolves: rhbz#1732765

Signed-off-by: Javier Martinez Canillas <[email protected]>

The grub_efi_net_parse_address() function is not covering the case where a
port number is specified in an IPv4 or IPv6 address, so will fail to parse
the network address.

For most cases the issue is harmless, because the function is only used to
match an address with a network interface and if fails the default is used.

But still is a bug that has to be fixed and it causes error messages to be
printed like the following:

error: net/efi/net.c:782:unrecognised network address '192.168.122.1:8080'

error: net/efi/net.c:781:unrecognised network address '[2000:dead:beef:a::1]:8080'

Resolves: rhbz#1732765

Signed-off-by: Javier Martinez Canillas <[email protected]>

The grub_efi_string_to_ip4_address() function wrongly assumes that an IPv6
address is an IPv4 address, because it doesn't take into account the case
of a caller passing an IPv6 address as a string.

This leads to the grub_efi_net_parse_address() function to fail and print
the following error message:

error: net/efi/net.c:785:unrecognised network address '2000:dead:beef:a::1'

Resolves: rhbz#1732765

Signed-off-by: Javier Martinez Canillas <[email protected]>

Currently if parsing the address fails an error message is printed. But in
most cases this isn't a fatal error since the grub_efi_net_parse_address()
function is only used to match an address with a network interface to use.

And if this fails, the default interface is used which is good enough for
most cases. So instead of printing an error that would pollute the console
just print a debug message if the address is not parsed correctly.

A user can enable debug messages for the efinet driver to have information
about the failure and the fact that the default interface is being used.

Related: rhbz#1732765

Signed-off-by: Javier Martinez Canillas <[email protected]>

Make F8, which used to be the hotkey to show the Windows boot menu during
boot for a long long time, also interrupt sleeps / stop the menu countdown.

Signed-off-by: Javier Martinez Canillas <[email protected]>

Upstream GRUB uses the EFI LoadImage() and StartImage() to boot the Linux
kernel. But our custom EFI loader that supports Secure Boot instead uses
the EFI handover protocol (for x86) or jumping directly to the PE/COFF
entry point (for aarch64).

This is done to allow the bootloader to verify the images using the shim
lock protocol to avoid booting untrusted binaries.

Since the bootloader loads the kernel from the boot media instead of using
LoadImage(), it is responsible to set the Loaded Image base address before
booting the kernel.

Otherwise the kernel EFI stub will complain that it was not set correctly
and print the following warning message:

EFI stub: ERROR: FIRMWARE BUG: efi_loaded_image_t::image_base has bogus value

Resolves: rhbz#1814690

Signed-off-by: Javier Martinez Canillas <[email protected]>

Currently if the EFI firmware fails to do a TPM measurement for a file,
the error will be propagated to the verifiers framework and so opening
the file will not succeed.

This mean that buggy firmwares will prevent the system to boot since the
loader won't be able to open any file. But failing to do TPM measurements
shouldn't be a fatal error and the system should still be able to boot.

Signed-off-by: Javier Martinez Canillas <[email protected]>

The EFI linux loader allocates a bounce buffer to copy the initrd since in
some machines doing DMA on addresses above 4GB is not possible during EFI.

But the verifiers framework also allocates a buffer to copy the initrd in
its grub_file_open() handler. It does this since the data to verify has to
be passed as a single chunk to modules that use the verifiers framework.

If the initrd image size is big there may not be enough memory in the heap
to allocate two buffers of that size. This causes an allocation failure in
the verifiers framework and leads to the initrd not being read.

To prevent these allocation failures, let's reduce the maximum size of the
bounce buffer used in the EFI loader. Since the data read can be copied to
the actual initrd address in multilple chunks.

Resolves: rhbz#1838633

Signed-off-by: Javier Martinez Canillas <[email protected]>

There are two different HTTP drivers that can be used when requesting an
HTTP resource: the efi/http that uses the EFI_HTTP_PROTOCOL and the http
that uses GRUB's HTTP and TCP/IP implementation.

The efi/http driver appends a prefix that is defined in the variable
http_path, but the http driver doesn't.

So using this driver and attempting to fetch a resource using a relative
path fails.

Signed-off-by: Javier Martinez Canillas <[email protected]>

Somewhere along the way this got mis-merged to include a return without
a value.  Fix it up.

Signed-off-by: Peter Jones <[email protected]>

Signed-off-by: Peter Jones <[email protected]>

Signed-off-by: Peter Jones <[email protected]>

In theory all of this data comes from the firmware stack and it should
be safe, but it's better to be paranoid.

Signed-off-by: Peter Jones <[email protected]>

These could be triggered by an extremely large number of arguments to
the initrd command on 32-bit architectures, or a crafted filesystem with
very large files on any architecture.

Signed-off-by: Colin Watson <[email protected]>

If certificates that signed grub are installed into db, grub can be
booted directly. It will then boot any kernel without signature
validation. The booted kernel will think it was booted in secureboot
mode and will implement lockdown, yet it could have been tampered.

This version of the patch skips calling verification, when booted
without secureboot. And is indented with gnu ident.

CVE-2020-15705

Reported-by: Mathieu Trudel-Lapierre <[email protected]>
Signed-off-by: Dimitri John Ledkov <[email protected]>

This will need to get folded back in the right place on the next rebase,
but it's before "Make grub_strtol() "end" pointers have safer const
qualifiers" currently, so for now I'm leaving it here instead of merging
it back with the original patch.

Signed-off-by: Peter Jones <[email protected]>

This will need to get folded back in the right place on the next rebase,
but it's before "Make grub_strtol() "end" pointers have safer const
qualifiers" currently, so for now I'm leaving it here instead of merging
it back with the original patch.

Signed-off-by: Peter Jones <[email protected]>

This will need to get folded back in the right place on the next rebase,
but it's before "Make grub_strtol() "end" pointers have safer const
qualifiers" currently, so for now I'm leaving it here instead of merging
it back with the original patch.

Signed-off-by: Peter Jones <[email protected]>

This will need to get folded back in the right place on the next rebase,
but it's before "Make grub_strtol() "end" pointers have safer const
qualifiers" currently, so for now I'm leaving it here instead of merging
it back with the original patch.

Signed-off-by: Peter Jones <[email protected]>

This will need to get folded back in the right place on the next rebase,
but it's before "Make grub_strtol() "end" pointers have safer const
qualifiers" currently, so for now I'm leaving it here instead of merging
it back with the original patch.

Signed-off-by: Peter Jones <[email protected]>

…er-menu=xxx" work with grub

This commit adds a number of scripts / config files to make
"systemctl reboot --boot-loader-menu=xxx" work with grub:

1. /lib/systemd/system/systemd-logind.service.d/10-grub.conf
This sets SYSTEMD_REBOOT_TO_BOOT_LOADER_MENU in the env. for logind,
indicating that the boot-loader which is used supports this feature, see:
https://github.com/systemd/systemd/blob/master/docs/ENVIRONMENT.md

2. /lib/systemd/system/grub-systemd-integration.service
   /lib/systemd/system/reboot.target.wants/grub-systemd-integration.service ->
     ../grub-systemd-integration.service
   /usr/libexec/grub/grub-systemd-integration.sh

The symlink in the .wants dir causes the added service file to be started
by systemd just before rebooting the system.
If /run/systemd/reboot-to-boot-loader-menu exist then the service will run
the grub-systemd-integration.sh script.
This script sets the new menu_show_once_timeout grubenv variable to the
requested timeout in seconds.

3. /etc/grub.d/14_menu_show_once

This new grub-mkconfig snippet adds the necessary code to the generated
grub.conf to honor the new menu_show_once_timeout variable, and to
automatically clear it after consuming it.

Note the service and libexec script use grub-systemd-integration as name
because in the future they may be used to add further integration with
systemctl reboot --foo options, e.g. support for --boot-loader-entry=NAME.

A few notes about upstreaming this patch from the rhboot grub2 fork:
1. I have deliberately put the grub.conf bits for this in a new / separate
   grub-mkconfig snippet generator for easy upstreaming
2. Even though the commit message mentions the .wants symlink for the .service
   I have been unable to come up with a clean way to do this at "make install"
   time, this should be fixed before upstreaming.

Downstream notes:
1. Since make install does not add the .wants symlink, this needs to be done
   in grub2.spec %install
2. This is keeping support for the "old" Fedora specific menu_show_once env
   variable, which has a hardcoded timeout of 60 sec in 12_menu_auto_hide in
   place for now. This can be dropped (eventually) in a follow-up patch once
   GNOME has been converted to use the systemd dbus API equivalent of
   "systemctl reboot --boot-loader-menu=xxx".

Signed-off-by: Hans de Goede <[email protected]>

Downstream RH / Fedora patch for compatibility with old, not (yet)
regenerated grub.cfg files which miss the menu_show_once_timeout check.
This older grubenv variable leads to a fixed timeout of 60 seconds.

Note that the new menu_show_once_timeout will overrule these 60 seconds
if both are set and the grub.cfg does have the menu_show_once_timeout
check.

Signed-off-by: Hans de Goede <[email protected]>

When keyboard controller acts in Translate mode (0x40 mask), then use
set 1 since translation is done.
Otherwise use the mode queried from the controller (usually set 2).

Added "atkeyb" debugging messages in at_keyboard module as well.

Resolves: rhbz#1897587

Tested on:
- Asus N53SN (set 1 used)
- Dell Precision (set 1 used)
- HP Elitebook (set 2 used)
- HP G5430 (set 1 used, keyboard in XT mode!)
- Lenovo P71 & Lenovo T460s (set 2 used)
- QEMU/KVM (set 1 used)

Signed-off-by: Renaud Métrich <[email protected]>

For each platform, GRUB is shipped as a kernel image and a set of
modules. These files are then used by the grub-install utility to
install GRUB on a specific device. However, in order to support UEFI
Secure Boot, the resulting EFI binary must be signed by a recognized
private key. For this reason, for EFI platforms, most distributions also
ship prebuilt EFI binaries signed by a distribution-specific private
key. In this case, however, the grub-install utility should not be used
because it would overwrite the signed EFI binary.

The current fix is suboptimal because it preserves all EFI-related code.
A better solution could be to modularize the code and provide a
build-time option.

Resolves: rhbz#1737444

Signed-off-by: Jan Hlavac <[email protected]>
[rharwood: drop man page]

…th absolute and relative timestamp

Signed-off-by: Renaud Métrich <[email protected]>

…uccess

Signed-off-by: Renaud Métrich <[email protected]>

… is in the environment and not empty

Signed-off-by: Renaud Métrich <[email protected]>

Signed-off-by: Renaud Métrich <[email protected]>
[[email protected]: rebase fuzz]
Signed-off-by: Robbie Harwood <[email protected]>

grub_file_open() calls grub_file_get_device_name(), but doesn't check
the return. Instead, it checks if grub_errno is set.

However, nothing initialises grub_errno here when grub_file_open()
starts. This means that trying to open one file that doesn't exist and
then trying to open another file that does will (incorrectly) also
fail to open that second file.

Let's fix that.

Signed-off-by: Steve McIntyre <[email protected]>

Signed-off-by: Renaud Métrich <[email protected]>

Signed-off-by: Diego Domingos <[email protected]>

grub-ofpathname doesn't work with fibre channel because there is no
function currently implemented for it.
This patch enables it by prividing a function that looks for the port
name, building the entire path for OF devices.

Signed-off-by: Diego Domingos <[email protected]>

this patch enables the device mapper discovery on ofpath.c. Currently,
when we are dealing with a device like /dev/dm-* the ofpath returns null
since there is no function implemented to handle this case.

This patch implements a function that will look into /sys/block/dm-*
devices and search recursively inside slaves directory to find the root
disk.

Signed-off-by: Diego Domingos <[email protected]>

This seems required with HP DL380p Gen 8 systems.
Indeed, with this system, we can see the following sequence:

1. controller is queried to get current configuration (returns 0x30 which is quite standard)
2. controller is queried to get the current keyboard set in used, using code 0xf0 (first part)
3. controller answers with 0xfa which means "ACK" (== ok)
4. then we send "0" to tell "we want to know which set your are supporting"
5. controller answers with 0xfa ("ACK")
6. controller should then give us 1, 2, 3 or 0x43, 0x41, 0x3f, but here it gives us 0xfe which means "NACK"

Since there seems no way to determine the current set, and in fact the
controller expects set2 to be used, we need to rely on an environment
variable.
Everything has been tested on this system: using 0xFE (resend command),
making sure we wait for ACK in the 2 steps "write_mode", etc.

Below is litterature I used to come up with "there is no other
solution":
- https://wiki.osdev.org/%228042%22_PS/2_Controller
- http://www-ug.eecg.toronto.edu/msl/nios_devices/datasheets/PS2%20Keyboard%20Protocol.htm
- http://www.s100computers.com/My%20System%20Pages/MSDOS%20Board/PC%20Keyboard.pdf

Signed-off-by: Renaud Métrich <[email protected]>
Signed-off-by: Robbie Harwood <[email protected]>

Add infrastructure to allow firmware to verify the integrity of grub
by use of a Linux-kernel-module-style appended signature. We initially
target powerpc-ieee1275, but the code should be extensible to other
platforms.

Usually these signatures are appended to a file without modifying the
ELF file itself. (This is what the 'sign-file' tool does, for example.)
The verifier loads the signed file from the file system and looks at the
end of the file for the appended signature. However, on powerpc-ieee1275
platforms, the bootloader is often stored directly in the PReP partition
as raw bytes without a file-system. This makes determining the location
of an appended signature more difficult.

To address this, we add a new ELF note.

The name field of shall be the string "Appended-Signature", zero-padded
to 4 byte alignment. The type field shall be 0x41536967 (the ASCII values
for the string "ASig"). It must be the final section in the ELF binary.

The description shall contain the appended signature structure as defined
by the Linux kernel. The description will also be padded to be a multiple
of 4 bytes. The padding shall be added before the appended signature
structure (not at the end) so that the final bytes of a signed ELF file
are the appended signature magic.

A subsequent patch documents how to create a grub core.img validly signed
under this scheme.

Signed-off-by: Daniel Axtens <[email protected]>
Signed-off-by: Rashmica Gupta <[email protected]>

Before adding information about how grub is signed with an appended
signature scheme, it's worth adding some information about how it
can currently be signed for UEFI.

Signed-off-by: Daniel Axtens <[email protected]>

Signing grub for firmware that verifies an appended signature is a
bit fiddly. I don't want people to have to figure it out from scratch
so document it here.

Signed-off-by: Daniel Axtens <[email protected]>

Trying to start grub-emu with a module that calls grub_dl_set_persistent
will crash because grub-emu fakes modules and passes NULL to the module
init function.

Provide an empty function for the emu case.

Fixes: ee7808e (dl: Add support for persistent modules)
Signed-off-by: Daniel Axtens <[email protected]>

rsa_pad does the PKCS#1 v1.5 padding for the RSA signature scheme.
We want to use it in other RSA signature verification applications.

I considered and rejected putting it in lib/crypto.c. That file doesn't
currently require any MPI functions, but rsa_pad does. That's not so
much of a problem for the grub kernel and modules, but crypto.c also
gets built into all the grub utilities. So - despite the utils not
using any asymmetric ciphers -  we would need to built the entire MPI
infrastructure in to them.

A better and simpler solution is just to spin rsa_pad out into its own
PKCS#1 v1.5 module.

Signed-off-by: Daniel Axtens <[email protected]>

The way gcry_rsa and friends (the asymmetric ciphers) are loaded for the
pgp module is a bit quirky.

include/grub/crypto.h contains:
  extern struct gcry_pk_spec *grub_crypto_pk_rsa;

commands/pgp.c contains the actual storage:
  struct gcry_pk_spec *grub_crypto_pk_rsa;

And the module itself saves to the storage in pgp.c:
  GRUB_MOD_INIT(gcry_rsa)
  {
    grub_crypto_pk_rsa = &_gcry_pubkey_spec_rsa;
  }

This is annoying: gcry_rsa now has a dependency on pgp!

We want to be able to bring in gcry_rsa without bringing in PGP,
so move the storage to crypto.c.

Previously, gcry_rsa depended on pgp and mpi. Now it depends on
crypto and mpi. As pgp depends on crypto, this doesn't add any new
module dependencies using the PGP verfier.

[FWIW, the story is different for the symmetric ciphers. cryptodisk
and friends (zfs encryption etc) use grub_crypto_lookup_cipher_by_name()
to get a cipher handle. That depends on grub_ciphers being populated
by people calling grub_cipher_register. import_gcry.py ensures that the
symmetric ciphers call it.]

Signed-off-by: Daniel Axtens <[email protected]>

 - Define SIZEOF_UNSIGNED_LONG_INT, it's the same as
   SIZEOF_UNSIGNED_LONG.

 - Define WORD_BIT, the size in bits of an int. This is a defined
   in the Single Unix Specification and in gnulib's limits.h. gnulib
   assumes it's 32 bits on all our platforms, including 64 bit
   platforms, so we also use that value.

 - Provide strto[u]l[l] preprocessor macros that resolve to
   grub_strto[u]l[l]. To avoid gcrypt redefining strtoul, we
   also define HAVE_STRTOUL here.

Signed-off-by: Daniel Axtens <[email protected]>

Import a very trimmed-down set of libtasn1 files:

pushd /tmp
wget https://ftp.gnu.org/gnu/libtasn1/libtasn1-4.16.0.tar.gz
popd
pushd grub-core/lib
mkdir libtasn1
cp /tmp/libtasn1-4.16.0/{README.md,LICENSE} libtasn1/
mkdir libtasn1/lib
cp /tmp/libtasn1-4.16.0/lib/{coding.c,decoding.c,element.c,element.h,errors.c,gstr.c,gstr.h,int.h,parser_aux.c,parser_aux.h,structure.c,structure.h}  libtasn1/lib
cp /tmp/libtasn1-4.16.0/lib/includes/libtasn1.h ../../include/grub/
git add libtasn1/ ../../include/grub/libtasn1.h
popd

Signed-off-by: Daniel Axtens <[email protected]>

We don't expect to be able to write ASN.1, only read it,
so we can disable some code.

Do that with #if 0/#endif, rather than deletion. This means
that the difference between upstream and grub is smaller,
which should make updating libtasn1 easier in the future.

With these exclusions we also avoid the need for minmax.h,
which is convenient because it means we don't have to
import it from gnulib.

Signed-off-by: Daniel Axtens <[email protected]>

Do a few things to make libtasn1 compile as part of grub:

 - replace strcat. grub removed strcat so replace it with the appropriate
   calls to memcpy and strlen.

 - replace c_isdigit with grub_isdigit (and don't import c-ctype from
   gnulib) grub_isdigit provides the same functionality as c_isdigit: it
   determines if the input is an ASCII digit without regard for locale.

 - replace GL_ATTRIBUTE_PURE with __attribute__((pure)) which been
   supported since gcc-2.96. This avoids messing around with gnulib.

 - adjust libtasn1.h: drop the ASN1_API logic, it's not needed for our
   modules. Unconditionally support const and pure attributes and adjust
   header paths.

 - adjust header paths to "grub/libtasn1.h".

 - replace a 64 bit division with a call to grub_divmod64, preventing
   creation of __udivdi3 calls on 32 bit platforms.

Signed-off-by: Daniel Axtens <[email protected]>

Create a wrapper file that specifies the module license.
Set up the makefile so it is built.

Signed-off-by: Daniel Axtens <[email protected]>

Import tests from libtasn1 that don't use functionality we don't
import. I have put them here rather than in the libtasn1 directory
because:

 -  They need much more significant changes to run in the grub
    context.

 -  I don't expect they will need to be changed when updating
    libtasn1: I expect the old tests will usually continue to pass on
    new versions.

This doesn't test the full decoder but that will be exercised in
test suites for coming patch sets.

Signed-off-by: Daniel Axtens <[email protected]>

To support verification of appended signatures, we need a way to
embed the necessary public keys. Existing appended signature schemes
in the Linux kernel use X.509 certificates, so allow certificates to
be embedded in the grub core image in the same way as PGP keys.

Signed-off-by: Alastair D'Silva <[email protected]>
Signed-off-by: Daniel Axtens <[email protected]>

In order to parse PKCS#7 messages and X.509 certificates with libtasn1,
we need some information about how they are encoded.

We get these from GNUTLS, which has the benefit that they support the
features we need and are well tested.

The GNUTLS license is LGPLv2.1+, which is GPLv3 compatible, allowing
us to import it without issue.

Signed-off-by: Daniel Axtens <[email protected]>

This code allows us to parse:

 - PKCS#7 signedData messages. Only a single signerInfo is supported,
   which is all that the Linux sign-file utility supports creating
   out-of-the-box. Only RSA, SHA-256 and SHA-512 are supported.
   Any certificate embedded in the PKCS#7 message will be ignored.

 - X.509 certificates: at least enough to verify the signatures on the
   PKCS#7 messages. We expect that the certificates embedded in grub will
   be leaf certificates, not CA certificates. The parser enforces this.

Signed-off-by: Daniel Axtens <[email protected]>

Building on the parsers and the ability to embed x509 certificates, as
well as the existing gcrypt functionality, add a module for verifying
appended signatures.

This includes a verifier that requires that Linux kernels and grub modules
have appended signatures, and commands to manage the list of trusted
certificates for verification.

Verification must be enabled by setting check_appended_signatures. If
GRUB is locked down when the module is loaded, verification will be
enabled and locked automatically.

As with the PGP verifier, it is not a complete secure-boot solution:
other mechanisms, such as a password or lockdown, must be used to ensure
that a user cannot drop to the grub shell and disable verification.

Signed-off-by: Daniel Axtens <[email protected]>
[pjones: fix missing format specifier]
Signed-off-by: Robbie Harwood <[email protected]>

These tests are run through all_functional_test and test a range
of commands and behaviours.

Signed-off-by: Daniel Axtens <[email protected]>

This explains how appended signatures can be used to form part of
a secure boot chain, and documents the commands and variables
introduced.

Signed-off-by: Daniel Axtens <[email protected]>

If the 'ibm,secure-boot' property of the root node is 2 or greater,
enter lockdown.

Signed-off-by: Daniel Axtens <[email protected]>

HEAP_MAX_ADDR is confusing. Currently it is set to 32MB, except
on ieee1275 on x86, where it is 64MB.

There is a comment which purports to explain it:

/* If possible, we will avoid claiming heap above this address, because it
   seems to cause relocation problems with OSes that link at 4 MiB */

This doesn't make a lot of sense when the constants are well above 4MB
already. It was not always this way. Prior to
commit 7b5d0fe ("Increase heap limit") in 2010, HEAP_MAX_SIZE and
HEAP_MAX_ADDR were indeed 4MB. However, when the constants were increased
the comment was left unchanged.

It's been over a decade. It doesn't seem like we have problems with
claims over 4MB on powerpc or x86 ieee1275. (sparc does things completely
differently and never used the constant.)

Drop the constant and the check.

The only use of HEAP_MIN_SIZE was to potentially override the
HEAP_MAX_ADDR check. It is now unused. Remove it.

Signed-off-by: Daniel Axtens <[email protected]>

Red Hat certificates have both Key Usage and Extended Key Usage extensions
present, but the appended signatures x509 parser doesn't handle the latter
and so buils due finding an unrecognised critical extension:

Error loading initial key:
../../grub-core/commands/appendedsig/x509.c:780:Unhandled critical x509 extension with OID 2.5.29.37

Fix this by also parsing the Extended Key Usage extension and handle it by
verifying that the certificate has a single purpose, that is code signing.

Signed-off-by: Javier Martinez Canillas <[email protected]>
Signed-off-by: Daniel Axtens <[email protected]>

This patch aims to make grub more robust when booting from SAN/Multipath disks.

If a path is failing intermittently so grub will retry the OPEN and READ the
disk (grub_ieee1275_open and grub_ieee1275_read) until the total amount of times
specified in MAX_RETRIES.

Signed-off-by: Diego Domingos <[email protected]>

Signed-off-by: Dimitri John Ledkov <[email protected]>
Signed-off-by: Robbie Harwood <[email protected]>

If a proxyDHCP configuration is used, the server name, server IP and boot
file values should be taken from the DHCP proxy offer instead of the DHCP
server ack packet. Currently that case is not handled, add support for it.

Signed-off-by: Ian Page Hands <[email protected]>
Signed-off-by: Robbie Harwood <[email protected]>

This incompat feature is used to denote that the filesystem stored its
metadata checksum seed in the superblock. This is used to allow tune2fs
to change the UUID on a mounted metadata_csum filesystem without having
to rewrite all the disk metadata.

But GRUB doesn't use the metadata checksum in anyway, so can just ignore
this feature if is enabled. This is consistent with GRUB filesystem code
in general which just does a best effort to access the filesystem's data.

It may be removed from the ignored list in the future if supports to do
metadata checksumming verification is added to the read-only FS driver.

Suggested-by: Eric Sandeen <[email protected]>
Suggested-by: Lukas Czerner <[email protected]>
Signed-off-by: Javier Martinez Canillas <[email protected]>

On OPAL ppc64le machines with an old petitboot version that doesn't have
support to parse BLS snippets, the grub2-mkconfig script is executed to
generate menuentry commands from the BLS snippets.

In this case, the script is executed with the --no-grubenv-update option
that indicates that no side effects should happen when running the script.

But the options field in the BLS snippets are updated regardless, only do
the update if --no-grubenv-update was not used.

Signed-off-by: Javier Martinez Canillas <[email protected]>

Colin Watson's patch from comment rhboot#11 on the upstream bug:
https://savannah.gnu.org/bugs/?35880#comment11

Resolves: rhbz#1592124

Signed-off-by: Paulo Flabiano Smorigo <[email protected]>

The GRUB configuration file is always placed in /boot/grub2/ now, even for
EFI. But the tool is still creating the user.cfg in the ESP and not there.

Resolves: rhbz#1955294

Signed-off-by: Javier Martinez Canillas <[email protected]>

The 30_uefi-firmware template checks if an OsIndicationsSupported UEFI var
exists and EFI_OS_INDICATIONS_BOOT_TO_FW_UI bit is set, to decide whether
a "fwsetup" menu entry would be added or not to the GRUB menu.

But this has the problem that it will only work if the configuration file
was created on an UEFI machine that supports booting to a firmware UI.

This for example doesn't support creating GRUB config files when executing
on systems that support both UEFI and legacy BIOS booting. Since creating
the config file from legacy BIOS wouldn't allow to access the firmware UI.

To prevent this, make the template to unconditionally create the grub.cfg
snippet but check at runtime if was booted through UEFI to decide if this
entry should be added. That way it won't be added when booting with BIOS.

There's no need to check if EFI_OS_INDICATIONS_BOOT_TO_FW_UI bit is set,
since that's already done by the "fwsetup" command when is executed.

Resolves: rhbz#1823864

Signed-off-by: Javier Martinez Canillas <[email protected]>

The "fwsetup" command is only registered if the firmware supports booting
to the firmware setup UI. But it could be possible that the GRUB config
already contains a "fwsetup" entry, because it was generated in a machine
that has support for this feature.

To prevent users getting a "can't find command `fwsetup`" error if it is
not supported by the firmware, let's just always register the command but
print a more accurate message if the firmware doesn't support this option.

Resolves: rhbz#1823864

Signed-off-by: Javier Martinez Canillas <[email protected]>

We are currently allocating just enough memory for the file size,
which means that the kernel BSS is in limbo (and not even zeroed).

We are also not honoring the alignment specified in the image
PE header.

This makes us use the PE optional header in which the kernel puts the
actual size it needs, including BSS, and make sure we clear it, and
honors the specified alignment for the image.

Signed-off-by: Benjamin Herrenschmidt <[email protected]>
[pjones: arm: check for the PE magic for the compiled arch]
Signed-off-by: Peter Jones <[email protected]>
Signed-off-by: Robbie Harwood <[email protected]>

The GRUB core.img is generated locally, when this is done the grub2-probe
tool figures out the device and partition that needs to be read to parse
the GRUB configuration file.

But in some cases the core.img can't be generated on the host and instead
has to be done at package build time. For example, if needs to get signed
with a key that's only available on the package building infrastructure.

If that's the case, the prefix variable won't have a device and partition
but only a directory path. So there's no way for GRUB to know from which
device has to read the configuration file.

To allow GRUB to continue working on that scenario, fallback to iterating
over all the available devices, if reading the config failed when using
the prefix and fw_path variables.

Signed-off-by: Javier Martinez Canillas <[email protected]>

On RHEL-signed powerpc grub, we sign a grub with -p /grub2 and expect
that there's a boot partition.

Unfortunately grub_set_prefix_and_root tries to convert this to
($fwdevice)/grub2. This ends up being (ieee1275/disk)/grub2 and that
falls apart pretty quickly - there's no file-system on ieee1275/disk,
and it makes the search routine try things like
(ieee1275/disk,msdos2)(ieee1275/disk)/grub2 which also doesn't work.

Detect if we would be about to create (ieee1275/disk)/path and don't:
preserve a prefix of /path instead and hope the search later finds us.

Related: rhbz#1899864

Signed-off-by: Daniel Axtens <[email protected]>
[[email protected]: squash in fixup commit]
Signed-off-by: Robbie Harwood <[email protected]>

The commit 8b1e5d1 (fs/xfs: Add bigtime incompat feature support)
introduced the bigtime support by adding some features in v3 inodes.
This change extended grub_xfs_inode struct by 76 bytes but also changed
the computation of XFS_V2_INODE_SIZE and XFS_V3_INODE_SIZE. Prior this
commit, XFS_V2_INODE_SIZE was 100 bytes. After the commit it's 84 bytes
XFS_V2_INODE_SIZE becomes 16 bytes too small.

As a result, the data structures aren't properly aligned and the GRUB
generates "attempt to read or write outside of partition" errors when
trying to read the XFS filesystem:

                             GNU GRUB  version 2.11
	....
	grub> set debug=efi,gpt,xfs
	grub> insmod part_gpt
	grub> ls (hd0,gpt1)/
	partmap/gpt.c:93: Read a valid GPT header
	partmap/gpt.c:115: GPT entry 0: start=4096, length=1953125
	fs/xfs.c:931: Reading sb
	fs/xfs.c:270: Validating superblock
	fs/xfs.c:295: XFS v4 superblock detected
	fs/xfs.c:962: Reading root ino 128
	fs/xfs.c:515: Reading inode (128) - 64, 0
	fs/xfs.c:515: Reading inode (739521961424144223) - 344365866970255880, 3840
	error: attempt to read or write outside of partition.

This commit change the XFS_V2_INODE_SIZE computation by subtracting 76
bytes instead of 92 bytes from the actual size of grub_xfs_inode struct.
This 76 bytes value comes from added members:
	20 grub_uint8_t   unused5
	 1 grub_uint64_t  flags2
        48 grub_uint8_t   unused6

This patch explicitly splits the v2 and v3 parts of the structure.
The unused4 is still ending of the v2 structures and the v3 starts
at unused5. Thanks to this we will avoid future corruptions of v2
or v3 inodes.

The XFS_V2_INODE_SIZE is returning to its expected size and the
filesystem is back to a readable state:

                      GNU GRUB  version 2.11
	....
	grub> set debug=efi,gpt,xfs
	grub> insmod part_gpt
	grub> ls (hd0,gpt1)/
	partmap/gpt.c:93: Read a valid GPT header
	partmap/gpt.c:115: GPT entry 0: start=4096, length=1953125
	fs/xfs.c:931: Reading sb
	fs/xfs.c:270: Validating superblock
	fs/xfs.c:295: XFS v4 superblock detected
	fs/xfs.c:962: Reading root ino 128
	fs/xfs.c:515: Reading inode (128) - 64, 0
	fs/xfs.c:515: Reading inode (128) - 64, 0
	fs/xfs.c:931: Reading sb
	fs/xfs.c:270: Validating superblock
	fs/xfs.c:295: XFS v4 superblock detected
	fs/xfs.c:962: Reading root ino 128
	fs/xfs.c:515: Reading inode (128) - 64, 0
	fs/xfs.c:515: Reading inode (128) - 64, 0
	fs/xfs.c:515: Reading inode (128) - 64, 0
	fs/xfs.c:515: Reading inode (131) - 64, 768
	efi/ fs/xfs.c:515: Reading inode (3145856) - 1464904, 0
	grub2/ fs/xfs.c:515: Reading inode (132) - 64, 1024
	grub/ fs/xfs.c:515: Reading inode (139) - 64, 2816
	grub>

Fixes: 8b1e5d1 (fs/xfs: Add bigtime incompat feature support)

Signed-off-by: Erwan Velu <[email protected]>
Tested-by: Carlos Maiolino <[email protected]>
Reviewed-by: Daniel Kiper <[email protected]>
(cherry picked from commit a4b4955)

At the very least, this will make it easier to track down the problem
module - or, if something else has gone wrong, provide more information
for debugging.

Signed-off-by: Robbie Harwood <[email protected]>

This was first reported under PFW but reproduces under SLOF.

 - The core.elf was 2126152 = 0x207148 bytes in size with the following
   program headers (per readelf):

Entry point 0x200000
There are 4 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000160 0x00200000 0x00200000 0x21f98 0x2971c RWE 0x8
  GNU_STACK      0x0220f8 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
  LOAD           0x0220f8 0x00232000 0x00232000 0x1e4e50 0x1e4e50 RWE 0x4
  NOTE           0x206f48 0x00000000 0x00000000 0x00200 0x00000 R   0x4

 - SLOF places the ELF file at 0x4000 (after the reserved space for
   interrupt handlers etc.) upwards. The image was 2126152 = 0x207148
   bytes in size, so it runs from 0x4000 - 0x20b148. We'll call 0x4000 the
   load address.

0x0        0x4000         0x20b148
 |----------|--------------|
 | reserved | ELF contents |

 - SLOF then copies the first LOAD program header (for .text). That runs
   for 0x21f98 bytes. It runs from
      (load addr + 0x160) to (load addr + 0x160 + 0x21f98)
    = 0x4160 to 0x260f8
   and we copy it to 0x200000 to 0x221f98. This overwrites the end of the
   image:

0x0       0x4000     0x200000        0x221f98
 |----------|------------|---------------|
 | reserved | ELF cont.. | .text section |

 - SLOF zeros the bss up to PhysAddr + MemSize = 0x22971c

0x0       0x4000      0x200000       0x221f98 0x22971c
 |----------|------------|---------------|--------|
 | reserved | ELF cont.. | .text section | bss 0s |

 - SLOF then goes to fulfil the next LOAD header (for mods), which is
   for 0x1e4e50 bytes. We copy from
      (load addr + 0x220f8) to (load addr + 0x220f8 + 0x1e4e50)
    = 0x260f8 to 0x20af48
   and we copy it to 0x232000 to 0x416e50:

0x0       0x4000      0x200000       0x221f98 0x22971c
 |----------|------------|---------------|--------|
 | reserved | ELF cont.. | .text section | bss 0s |
               |-------------|
               | copied area |
            0x260f8      0x20af48

   This goes poorly:

0x0       0x4000      0x200000       0x221f98 0x22971c 0x232000 0x40bf08      0x416e50
 |----------|------------|---------------|--------|-----|-----------|-------------|
 | reserved | ELF cont.. | .text section | bss 0s | pad | some mods | .text start |

This matches the observations on the running system - 0x40bf08 was where
the contents of memory no longer matched the contents of the ELF file.

This was reported as a license verification failure on SLOF as the
last module's .module_license section fell past where the corruption
began.

Signed-off-by: Daniel Axtens <[email protected]>
[[email protected]: trim very detailed commit message]
Signed-off-by: Robbie Harwood <[email protected]>

Since commit:

  ab2e53c grub-mkconfig: Honor a symlink when generating configuration
by grub-mkconfig

has inadvertently discarded umask for creating grub.cfg in the process
of grub-mkconfig. The resulting wrong permission (0644) would allow
unprivileged users to read grub's configuration file content. This
presents a low confidentiality risk as grub.cfg may contain non-secured
plain-text passwords.

This patch restores the missing umask and set the file mode of creation
to 0600 preventing unprivileged access.

Fixes: CVE-2021-3981

Signed-off-by: Michael Chang <[email protected]>

Up to now GRUB can only embed to the first 64 KiB before primary
superblock of btrfs, effectively limiting the GRUB core size. That
could consequently pose restrictions to feature enablement like
advanced zstd compression.

This patch attempts to utilize full unused area reserved by btrfs for
the bootloader outlined in the document [1]:

  The first 1MiB on each device is unused with the exception of primary
  superblock that is on the offset 64KiB and spans 4KiB.

Apart from that, adjacent sectors to superblock and first block group
are not used for embedding in case of overflow and logged access to
adjacent sectors could be useful for tracing it up.

This patch has been tested to provide out of the box support for btrfs
zstd compression with which GRUB has been installed to the partition.

[1] https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs(5)#BOOTLOADER_SUPPORT

Signed-off-by: Michael Chang <[email protected]>
Reviewed-by: Daniel Kiper <[email protected]>
(cherry picked from commit b0f06a8)

In Fedora 35, and possibly earlier, grub would fail to configure with a
complaint about DejaVu being "not found" even though it was installed.
The DejaVu sans font search path is updated to reflect the
distribution's current install path.

Signed-off-by: Erik Edwards <[email protected]>
[[email protected]: slight commit message edits]
Signed-off-by: Robbie Harwood <[email protected]>

…EOUT_STYLE_HIDDEN

When the user has asked the menu code to be hidden/quiet and the current
entry is being autobooted because the timeout has expired don't show
the "Booting `%s'" msg.

This is necessary to let flicker-free boots really be flicker free,
otherwise the "Booting `%s'" msg will kick the EFI fb into text mode
and show the msg, breaking the flicker-free experience.

Signed-off-by: Hans de Goede <[email protected]>

Grub EFI builds are now often used in combination with flicker-free
boot, but this breaks with upstream grub because the "Welcome to GRUB!"
message will kick the EFI fb into text mode and show the msg,
breaking the flicker-free experience.

EFI systems are so fast, that when the menu or the countdown are enabled
the message will be immediately overwritten, so in these cases not
printing the message does not matter.

And in case when the timeout_style is set to TIMEOUT_STYLE_HIDDEN,
the user has asked grub to be quiet (for example to allow flickfree
boot) annd thus the message should not be printed.

Signed-off-by: Hans de Goede <[email protected]>

GRUB_MOD_INIT(normal) does an unconditional:

grub_env_set ("color_normal", "light-gray/black");

which triggers a grub_term_setcolorstate() call. The original version
of the "efi/console: Do not set text-mode until we actually need it" patch:
https://lists.gnu.org/archive/html/grub-devel/2018-03/msg00125.html

Protected against this by caching the requested state in
grub_console_setcolorstate () and then only applying it when the first
text output actually happens. During refactoring to move the
grub_console_setcolorstate () up higher in the grub-core/term/efi/console.c
file the code to cache the color-state + bail early was accidentally
dropped.

Restore the cache the color-state + bail early behavior from the original.

Cc: Javier Martinez Canillas <[email protected]>
Fixes: 2d7c3ab ("efi/console: Do not set text-mode until we actually need it")
Signed-off-by: Hans de Goede <[email protected]>

To allow flickerfree boot the EFI console code does not call
grub_efi_set_text_mode (1) until some text is actually output.

Depending on if the output text is because of an error loading
e.g. the .cfg file; or because of showing the menu the cursor needs
to be on or off when the first text is shown.

So far the cursor was hardcoded to being on, but this is causing
drawing artifacts + slow drawing of the menu as reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=1946969

Handle the cursorstate in the same way as the colorstate to fix this,
when no text has been output yet, just cache the cursorstate and
then use the last set value when the first text is output.

Fixes: 2d7c3ab ("efi/console: Do not set text-mode until we actually need it")
Signed-off-by: Hans de Goede <[email protected]>

Signed-off-by: Robbie Harwood <[email protected]>
(cherry picked from commit de8051f)
[rharwood: GRUB_RPM_CONFIG presence]

gnulib defines go in config-util.h, and we need to know whether to
provide duplicates in config.h or not.

Signed-off-by: Robbie Harwood <[email protected]>
(cherry picked from commit 46e82b2)
[rharwood: gensymlist isn't part of tarballs]

Originally added in 9fbdec2 and
subsequently modified in 552c9fd,
fix-base64.patch handled two problems we have using gnulib, which are
exerciesd by the base64 module but not directly caused by it.

First, grub2 defines its own bool type, while gnulib expects the
equivalent of stdbool.h to be present.  Rather than patching gnulib,
instead use gnulib's stdbool module to provide a bool type if needed.
(Suggested by Simon Josefsson.)

Second, our config.h doesn't always inherit config-util.h, which is
where gnulib-related options like _GL_ATTRIBUTE_CONST end up.
fix-base64.h worked around this by defining the attribute away, but this
workaround is better placed in config.h itself, not a gnulib patch.

Signed-off-by: Robbie Harwood <[email protected]>
(cherry picked from commit 54fd1c3)

Originally added in db7337a, this
patched out all relevant invocations of abort() in gnulib.  While it was
not documented why at the time, testing suggests that there's no abort()
implementation available for gnulib to use.

gnulib's position is that the use of abort() is correct here, since it
happens when input violates a "shall" from POSIX.  Additionally, the
code in question is probably not reachable.  Since abort() is more
friendly to user-space, they prefer to make no change, so we can just
carry a define instead.  (Suggested by Paul Eggert.)

Signed-off-by: Robbie Harwood <[email protected]>
(cherry picked from commit 5137c8e)

In addition to the changes carried in our gnulib patches, several
Coverity and code hygiene fixes that were previously downstream are also
included in this 3-year gnulib increment.

Unfortunately, fix-width.patch is retained.

Bump minimum autoconf version from 2.63 to 2.64 and automake from 1.11
to 1.14, as required by gnulib.

Sync bootstrap script itself with gnulib.

Update regexp module for new dynarray dependency.

Fix various new warnings.

Signed-off-by: Robbie Harwood <[email protected]>
(cherry picked from commit deb18ff)
[rharwood: backport around requirements in INSTALL]

When using --no-floppy and a floppy was encountered, iterate_device()
was returning 1, causing the iteration to stop instead of continuing.

Signed-off-by: Renaud Métrich <[email protected]>
Reviewed-by: Daniel Kiper <[email protected]>
(cherry picked from commit 68ba54c)
Signed-off-by: Robbie Harwood <[email protected]>

When using 'search' on EFI systems, we sometimes want to exclude devices
that are not EFI disks (e.g. md, lvm).
This is typically used when wanting to chainload when having a software
raid (md) for EFI partition:
with no option, 'search --file /EFI/redhat/shimx64.efi' sets root envvar
to 'md/boot_efi' which cannot be used for chainloading since there is no
effective EFI device behind.

This commit also refactors handling of --no-floppy option.

Signed-off-by: Renaud Métrich <[email protected]>
[rharwood: apply rmetrich's flags initialization fix]
Signed-off-by: Robbie Harwood <[email protected]>

When efi.quickboot is enabled on VMWare (which is the default for
hardware release 16 and later), it may happen that not all EFI devices
are connected. Due to this, browsing the devices in make_devices() just
fails to find devices, in particular disks or partitions for a given
disk.
This typically happens when network booting, then trying to chainload to
local disk (this is used in deployment tools such as Red Hat Satellite),
which is done through using the following grub.cfg snippet:
-------- 8< ---------------- 8< ---------------- 8< --------
unset prefix
search --file --set=prefix /EFI/redhat/grubx64.efi
if [ -n "$prefix" ]; then
  chainloader ($prefix)/EFI/redhat/grubx64/efi
...
-------- 8< ---------------- 8< ---------------- 8< --------

With efi.quickboot, none of the devices are connected, causing "search"
to fail. Sometimes devices are connected but not the partition of the
disk matching $prefix, causing partition to not be found by
"chainloader".

This patch introduces a new "connectefi pciroot|scsi" command which
recursively connects all EFI devices starting from a given controller
type:
- if 'pciroot' is specified, recursion is performed for all PCI root
  handles
- if 'scsi' is specified, recursion is performed for all SCSI I/O
  handles (recommended usage to avoid connecting unwanted handles which
  may impact Grub performances)

Typical grub.cfg snippet would then be:
-------- 8< ---------------- 8< ---------------- 8< --------
connectefi scsi
unset prefix
search --file --set=prefix /EFI/redhat/grubx64.efi
if [ -n "$prefix" ]; then
  chainloader ($prefix)/EFI/redhat/grubx64/efi
...
-------- 8< ---------------- 8< ---------------- 8< --------

The code is easily extensible to handle other arguments in the future if
needed.

Signed-off-by: Renaud Métrich <[email protected]>
Signed-off-by: Robbie Harwood <[email protected]>

On codebases that have shim-lock-verifier built into the grub core
(like 2.06 upstream), shim-lock-verifier is in enforcing mode when
booted with secureboot. It means that grub_cmd_linux() command
attempts to perform shim validate upon opening linux kernel image,
including kernel measurement. And the verifier correctly returns file
open error when shim validate protocol is not present or shim fails to
validate the kernel.

This makes the call to grub_linuxefi_secure_validate() redundant, but
also harmful. As validating the kernel image twice, extends the PCRs
with the same measurement twice. Which breaks existing sealing
policies when upgrading from grub2.04+rhboot+sb+linuxefi to
grub2.06+rhboot+sb+linuxefi builds. It is also incorrect to measure
the kernel twice.

This patch must not be ported to older editions of grub code bases
that do not have verifiers framework, or it is not builtin, or
shim-lock-verifier is an optional module.

This patch is tested to ensure that unsigned kernels are not possible
to boot in secureboot mode when shim rejects kernel, or shim protocol
is missing, and that the measurements become stable once again. The
above also ensures that CVE-2020-15705 is not reintroduced.

Signed-off-by: Dimitri John Ledkov <[email protected]>

Call to grub_file_open(, GRUB_FILE_TYPE_LINUX_KERNEL) already passes
the kernel file through shim-lock verifier when secureboot is on. Thus
there is no need to validate the kernel image again. And when doing so
again, duplicate PCR measurement is performed, breaking measurements
compatibility with 2.04+linuxefi.

This patch must not be ported to older editions of grub code bases
that do not have verifiers framework, or it is not builtin, or
shim-lock-verifier is an optional module.

Signed-off-by: Dimitri John Ledkov <[email protected]>

On secureboot systems, with shimlock verifier, call to
grub_file_open(, GRUB_FILE_TYPE_EFI_CHAINLOADED_IMAGE) will already
pass the chainloader target through shim-lock protocol verify
call. And create a TPM measurement. If verification fails,
grub_cmd_chainloader will fail at file open time.

This makes previous code paths for negative, and zero return codes
from grub_linuxefi_secure_validate unreachable under secureboot. But
also breaking measurements compatibility with 2.04+linuxefi codebases,
as the chainloader file is passed through shim_lock->verify() twice
(via verifier & direct call to grub_linuxefi_secure_validate)
extending the PCRs twice.

This reduces grub_loader options to perform
grub_secureboot_chainloader when secureboot is on, and otherwise
attempt grub_chainloader_boot.

It means that booting with secureboot off, yet still with shim (which
always verifies things successfully), will stop choosing
grub_secureboot_chainloader, and opting for a more regular
loadimage/startimage codepath. If we want to use the
grub_secureboot_chainloader codepath in such scenarios we should adapt
the code to simply check for shim_lock protocol presence /
shim_lock->context() success?! But I am not sure if that is necessary.

This patch must not be ported to older editions of grub code bases
that do not have verifiers framework, or it is not builtin, or
shim-lock-verifier is an optional module.

Signed-off-by: Dimitri John Ledkov <[email protected]>

…lidate

Drop the now unused grub_linuxefi_secure_validate() as all prior users
of this API now rely on the shim-lock-verifier codepath instead.

This patch must not be ported to older editions of grub code bases
that do not have verifiers framework, or it is not builtin, or
shim-lock-verifier is an optional module.

Signed-off-by: Dimitri John Ledkov <[email protected]>

Frustratingly, the device name itself can contain an embedded comma:
e.g /pci@800000020000015/pci1014,034A@0/sas/disk@5000c50098a0ee8b

So my previous approach was wrong: we cannot rely upon the presence
of a comma to say that a partition has been specified!

It turns out for prefixes like (,gpt2)/grub2 we really want to make
up a full (device,partition)/patch prefix, because root discovery code
in 10_linux will reset the root variable and use search to fill it again.
If you have run grub-install, you probably don't have search built in,
and if you don't have prefix containing (device,partition), grub will
construct ($root)$prefix/powerpc-ieee1275/search.mod - but because $root
has just been changed, this will no longer work, and the boot will fail!

Retain the gist of the logic, but instead of looking for a comma, look for
a leading '('. This matches the earlier code better anyway.

There's certainly a better fix to be had. But any time you chose to build
with a bare prefix like '/grub2', you're almost certainly going to build in
search anyway, so this will do.

Signed-off-by: Daniel Axtens <[email protected]>

The feature Retry on Fail added to GRUB can cause a LPM to take
longer if the SAN is slow.

When a LPM to external site occur, the path of the disk can change
and thus the disk search function on grub can take some time since
it is used as a hint. This can cause the Retry on Fail feature to
try to access the disk 20x times (since this is hardcoded number)
and, if the SAN is slow, the boot time can increase a lot.
In some situations not acceptable.

The following patch enables a configuration at user space of the
maximum number of retries we want for this feature.

The variable ofdisk_retries should be set using grub2-editenv
and will be checked by retry function. If the variable is not set,
so the default number of retries will be used instead.

grub_load_and_start_image only loads an image - it still requires the
caller to start it. This renames it to grub_load_image.

It's called from 2 places:
- grub_cmd_chainloader when not using the shim protocol.
- grub_secureboot_chainloader_boot if handle_image returns an error.
In this case, the image is loaded and then nothing else happens which
seems strange. I assume the intention is that it falls back to LoadImage
and StartImage if handle_image fails, so I've made it do that.

Signed-off-by: Chris Coulson <[email protected]>
(cherry picked from commit b4d70820a65c00561045856b7b8355461a9545f6)