From UEFI specifications 2.10, section 13.2.2, EFI_LOAD_FILE2_PROTOCOL.LoadFile
(see https://uefi.org/specs/UEFI/2.10/13_Protocols_Media_Access.html), for BufferSize:
On input the size of Buffer in bytes. On output with a return code
of EFI_SUCCESS, the amount of data transferred to Buffer. On output
with a return code of EFI_BUFFER_TOO_SMALL, the size of Buffer
required to retrieve the requested file.
So, set *buffer_size correctly.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Not reusing these handles will result in image measurements showing up
twice in the event log.
On the occasion add missing grub_free() call.
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Not reusing these handles will result in image measurements showing up
twice in the event log.
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Use loader protocol for image verification where available, otherwise
fall back to the old shim lock protocol.
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
These can be used to register a different implementation later,
for example, when shim provides a protocol with those functions.
Signed-off-by: Julian Andres Klode <julian.klode@canonical.com>
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Unload previous Linux kernel/initrd before updating the global variable
kernel_size. Otherwise the previous Linux kernel gets deallocated with
the kernel_size of the Linux kernel that is being currently loaded.
Signed-off-by: Adriano Cordova <adriano.cordova@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
If a simple string for arguments are passed it should be NUL terminated.
This is true for other code but not for "linux" command.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This is more consistent with the above code using sizeof(grub_efi_char16_t).
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Although the length should not exceed 2^31 grub_size_t is more
suitable for that variable. len is used to compute the size
of buffers which in C is a size_t, not a int. It is used
for GRUB_EFI_BYTES_TO_PAGES which expects unsigned values.
It is assigned to load_options_size which is unsigned, not signed.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The size passed to grub_utf8_to_utf16() for the source string is
used as a limit for the string if NUL character is not encountered.
However, len, which is "strlen(src) * 2 + 2" is surely greater than
strlen(src). Pass the exact correct length.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
If the following allocation fails this would leave load_options NULL
while load_options_size not valid. If the allocation succeed
load_options_size is overwritten.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Avoid dangling pointer. Code should not be reached but better safe than sorry.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The function called is grub_utf8_to_utf16().
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Users have no reason to see this and it can break graphical boot.
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The fdtdump command allows dumping arbitrary device tree properties
and saving them to a variable similar to the smbios command.
This is useful in scripts where further actions such as selecting
a kernel or loading another device tree depend on the compatible
or model values of the device tree provided by the firmware.
For now only the root level properties of the dtb are exposed.
Signed-off-by: Tobias Heider <tobias.heider@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Recent mixed-mode Linux kernels, i.e., v4.0 or newer, can access EFI
runtime services at OS runtime even when the OS was not entered via the
EFI stub. This is because, instead of reverting back to the firmware's
segment selectors, GDTs and IDTs, the 64-bit kernel simply calls 32-bit
runtime services using compatibility mode, i.e., the same mode used for
32-bit user space, without taking down all interrupt handling, exception
handling, etc.
This means that GRUB's legacy x86 boot mode is sufficient to make use of
this: 32-bit i686 builds of GRUB can already boot 64-bit kernels in EFI
enlightened mode, but without going via the EFI stub, and provide all
the metadata that the OS needs to map the EFI runtime regions and call
EFI runtime services successfully.
It does mean that GRUB should not attempt to invoke the firmware's
LoadImage()/StartImage() methods on kernel builds that it knows cannot
be started natively. So, add a check for this in the native EFI boot
path and fall back to legacy x86 mode in such cases.
Note that in the general case, booting non-native images of the same
native word size, e.g., x64 EFI apps on arm64 firmware, might be
supported by means of emulation. So, let's only disallow images that use
a non-native word size. This will also permit booting i686 kernels on
x86_64 builds, although without access to runtime services, as this is
not supported by Linux.
This change on top of 2.12-rc1 is sufficient to boot ordinary Linux
mixed mode builds and get full access to the EFI runtime services.
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Steve McIntyre <steve@einval.com>
Cc: Julian Andres Klode <julian.klode@canonical.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The LoadImage() provided by the shim does not consult MOK when loading
an image. So, simply signature verification fails when it should not.
This means we cannot use Linux EFI stub to start the kernel when the
shim is loaded. We have to fallback to legacy mode on x86 architectures.
This is not possible on other architectures due to lack of legacy mode.
This is workaround which should disappear when the shim provides
LoadImage() which looks up MOK during signature verification.
On the occasion align constants in include/grub/efi/sb.h.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
EFI status codes are of different classes depending on the first byte and
all error status codes defined in appendix D of the main spec start from
1 and have the high bit set. When printing as a uint, the decimal is a very
large number that needs have the high bit cleared get the spec error code.
This can be easily visually done by a human if the number is printed as hex.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The EFI chainloader checks that a device path can be created for the $root
device before allowing chainloading to a given file. This is probably to
ensure that the given file can be accessed and loaded by the firmware.
However, since GRUB is loading the image itself, the firmware need not
be able to access the file location of the image. So remove this check.
Also, this fixes an issue where chainloading an image file on a location
that is accessible by the firmware, e.g. (hd0,1)/efi/boot.efi, would
fail when root is a location inaccessible by the firmware, e.g. memdisk.
Use GRUB_EFI_BYTES_TO_PAGES() instead of doing the calculation explicitly.
Add comment noting the section where the load options for the chainloaded
EFI application is constructed.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
There are 3 implementations of a GUID in GRUB. Replace them with
a common one, placed in types.h.
It uses the "packed" flavor of the GUID structs, the alignment attribute
is dropped, since it is not required.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The EFI spec mandates that the handle produced by the LoadImage boot
service has a LoadedImage protocol instance installed on it, but for
robustness, we should still deal with a NULL return value from the
helper routine that obtains this protocol pointer.
If this happens, don't try to start the image but unload it and return
an error.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Switch the x86 based EFI platform builds to the generic EFI loader,
which exposes the initrd via the LoadFile2 protocol instead of the
x86-specific setup header. This will launch the Linux kernel via its EFI
stub, which performs its own initialization in the EFI boot services
context before calling ExitBootServices() and performing the bare metal
Linux boot.
Given that only Linux kernel versions v5.8 and later support this initrd
loading method, the existing x86 loader is retained as a fallback, which
will also be used for Linux kernels built without the EFI stub. In this
case, GRUB calls ExitBootServices() before entering the Linux kernel,
and all EFI related information is provided to the kernel via struct
boot_params in the setup header, as before.
Note that this means that booting EFI stub kernels older than v5.8 is
not supported even when not using an initrd at all. Also, the EFI
handover protocol, which has no basis in the UEFI specification, is not
implemented.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Now that GCC can generate function calls using the correct calling
convention for us, we can stop using the efi_call_XX() wrappers, and
just dereference the function pointers directly.
This avoids the untyped variadic wrapper routines, which means better
type checking for the method calls.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The arch specific image header details are not very useful as most of
the GRUB just looks at the PE/COFF spec parameters (PE32 magic and
header offset).
Remove the arch specific images headers and define a generic arch
headers that provide enough PE/COFF fields for the GRUB to parse
kernel images correctly.
Signed-off-by: Atish Patra <atishp@rivosinc.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
ARM64 linux loader code is written in such a way that it can be reused
across different architectures without much change. Move it to common
code so that RISC-V doesn't have to define a separate loader.
Signed-off-by: Atish Patra <atishp@rivosinc.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Now that we implemented support for the LoadFile2 protocol for initrd
loading, there is no longer a need to pass the initrd parameters via
the device tree. This means that when the LoadFile2 protocol is being
used, there is no reason to update the device tree in the first place,
and so we can ignore it entirely.
The only remaining reason to deal with the devicetree is if we are
using the "devicetree" command to load one from disk, so tweak the
logic in grub_fdt_install() to take that into account.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This ports the EFI chainloader to use grub_loader_set_ex() in order to fix
a use-after-free bug that occurs when grub_cmd_chainloader() is executed
more than once before a boot attempt is performed.
Fixes: CVE-2022-28736
Signed-off-by: Chris Coulson <chris.coulson@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The chainloader command retains the source buffer and device path passed
to LoadImage(), requiring the unload hook passed to grub_loader_set() to
free them. It isn't required to retain this state though - they aren't
required by StartImage() or anything else in the boot hook, so clean them
up before grub_cmd_chainloader() finishes.
Signed-off-by: Chris Coulson <chris.coulson@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
According to the Embedded Base Boot Requirements (EBBR) specification the
device-tree passed to Linux as a configuration table must reside in
EfiACPIReclaimMemory.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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().
Signed-off-by: Chris Coulson <chris.coulson@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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.
Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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
Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The address of fp->path_name could be unaligned since seeking into the
device path buffer for a given node could end in byte boundary.
The fix is using aligned buffer allocated by grub_malloc for receiving
the converted UTF16 string by grub_utf8_to_utf16 and also the processing
after. The resulting string then gets copied to fp->path_name.
[ 243s] ../../grub-core/loader/efi/chainloader.c: In function 'copy_file_path':
[ 243s] ../../grub-core/loader/efi/chainloader.c:136:32: error: taking address of packed member of 'struct grub_efi_file_path_device_path' may result in an unaligned pointer value [-Werror=address-of-packed-member]
[ 243s] 136 | size = grub_utf8_to_utf16 (fp->path_name, len * GRUB_MAX_UTF16_PER_UTF8,
[ 243s] | ~~^~~~~~~~~~~
[ 243s] ../../grub-core/loader/efi/chainloader.c:138:12: error: taking address of packed member of 'struct grub_efi_file_path_device_path' may result in an unaligned pointer value [-Werror=address-of-packed-member]
[ 243s] 138 | for (p = fp->path_name; p < fp->path_name + size; p++)
[ 243s] | ^~
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
We should not try to copy any memory area which is outside of the original
fdt. If this extra memory is controlled by a hypervisor this might end
with a crash.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The verifiers framework changed the API of grub_file_open(), but did not
fix up all users. Add the file type GRUB_FILE_TYPE_DEVICE_TREE_IMAGE
to the "devicetree" command handler call.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Let's provide file type info to the I/O layer. This way verifiers
framework and its users will be able to differentiate files and verify
only required ones.
This is preparatory patch.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
When booting an arm* system on UEFI with an empty device tree (currently
only when hardware description comes from ACPI), we don't currently set
default to 1 cell (32 bits).
Set both of these properties, to 2 cells (64 bits), to resolve issues
with kexec on some platforms.
This change corresponds with linux kernel commit ae8a442dfdc4
("efi/libstub/arm*: Set default address and size cells values for an empty dtb")
and ensures booting through grub does not behave differently from booting
the stub loader directly.
See also https://patchwork.kernel.org/patch/9561201/
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The EFI page definitions and macros are generic and should not be confined
to arm64 headers - so move to efi/memory.h.
Also add EFI_PAGE_SIZE macro.
Update loader sources to reflect new header location.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In preparation for turning this into a common loader for 32-bit and 64-bit
platforms, ensure the code will compile cleanly for either.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
There is nothing ARM64 (or even ARM) specific about the efi fdt helper
library, which is used for locating or overriding a firmware-provided
devicetree in a UEFI system - so move it to loader/efi for reuse.
Move the fdtload.h include file to grub/efi and update path to
efi/fdtload.h in source code referring to it.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
EFI File Path Media Device Path is defined as NULL terminated string;
but chainloader built file paths without final NULL. This caused error
with Secure Boot and Linux Foundation PreLoader on Acer with InsydeH20 BIOS.
Apparently firmware failed verification with EFI_INVALID_PARAMETER which is
considered fatal error by PreLoader.
Reported and tested by Giovanni Santini <itachi.sama.amaterasu@gmail.com>
