'vendor' is both an input and an output parameter. So it cannot be
constant.
Fixes: 0bda81bfdc ("efi_loader: use const efi_guid_t * for variable services")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
For EFI binaries we have to provide an implementation of memmove() in
efi_freestanding.c.
Before this patch the memmove() function was copying in the wrong
direction.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
GetNextVariableName should report the length of the variable including the
final 0x0000 in bytes.
Check this in the unit test.
Increase the buffer size for variable names. 40 bytes is too short.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The runtime service GetNextVariable() returns the length of the next
variable including the closing 0x0000. This length should be in bytes.
Comparing the output of EDK2 and U-Boot shows that this is currently not
correctly implemented:
EDK2:
OsIndicationsSupported: 46
PlatformLang: 26
PlatformLangCodes: 36
U-Boot:
OsIndicationsSupported: 23
PlatformLang: 13
PlatformLangCodes: 18
Provide correct length in GetNextVariable().
Fixes: d99a87f84b ("efi_loader: implement GetNextVariableName()")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
This is a preparatory patch.
Those functions will be used in an implementation of UEFI firmware
management protocol as part of my capsule update patch.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Currently, if GetMemoryMap API returns EFI_BUFFER_TOO_SMALL, it doesn't
set valid values to other parameters, descriptor_size and
descriptor_version, except memory_map_size.
Some efi applications, however, may use those value; in particular,
xen uses descriptor_size to calculate a size of buffer to be allocated.
While UEFI specification is ambiguous in this point, it would be better
to address this issue proactively to maximize the compatibility with
existing efi applications.
With this patch, for example, xen.efi (and hence linux kernel) can be
started via bootefi without modification.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Provide a unit test loading an initial ramdisk using the
EFI_LOAD_FILE2_PROTOCOL. The test is only executed on request.
An example usage - given a file image with a file system in partition 1
holding file initrd - is:
* Configure the sandbox with
CONFIG_EFI_SELFTEST=y
CONFIG_EFI_LOAD_FILE2_INITRD=y
CONFIG_EFI_INITRD_FILESPEC="host 0:1 initrd"
* Run ./u-boot and execute
host bind 0 image
setenv efi_selftest load initrd
bootefi selftest
This would provide a test output like:
Testing EFI API implementation
Selected test: 'load initrd'
Setting up 'load initrd'
Setting up 'load initrd' succeeded
Executing 'load initrd'
Loaded 12378613 bytes
CRC32 2997478465
Executing 'load initrd' succeeded
Now the size and CRC32 can be compared to the provided file.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Following kernel's proposal for an arch-agnostic initrd loading
mechanism [1] let's implement the U-boot counterpart.
This new approach has a number of advantages compared to what we did up
to now. The file is loaded into memory only when requested limiting the
area of TOCTOU attacks. Users will be allowed to place the initramfs
file on any u-boot accessible partition instead of just the ESP one.
Finally this is an attempt of a generic interface across architectures
in the linux kernel so it makes sense to support that.
The file location is intentionally only supported as a config option
argument(CONFIG_EFI_INITRD_FILESPEC), in an effort to enhance security.
Although U-boot is not responsible for verifying the integrity of the
initramfs, we can enhance the offered security by only accepting a
built-in option, which will be naturally verified by UEFI Secure Boot.
This can easily change in the future if needed and configure that via ENV
or UEFI variable.
[1] https://lore.kernel.org/linux-efi/20200207202637.GA3464906@rani.riverdale.lan/T/#m4a25eb33112fab7a22faa0fd65d4d663209af32f
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
UEFI spec 2.8 errata A replaces the RuntimeServicesSupported variable
defined in UEFI spec 2.8 by the configuration table
EFI_RT_PROPERTIES_TABLE. So let's follow suit.
Cc: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tested-by: Ard Biesheuvel <ardb@kernel.org>
At present dm/device.h includes the linux-compatible features. This
requires including linux/compat.h which in turn includes a lot of headers.
One of these is malloc.h which we thus end up including in every file in
U-Boot. Apart from the inefficiency of this, it is problematic for sandbox
which needs to use the system malloc() in some files.
Move the compatibility features into a separate header file.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present devres.h is included in all files that include dm.h but few
make use of it. Also this pulls in linux/compat which adds several more
headers. Drop the automatic inclusion and require files to include devres
themselves. This provides a good indication of which files use devres.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
In upstream libfdt, 6dcb8ba4 "libfdt: Add helpers for accessing
unaligned words" introduced changes to support unaligned reads for ARM
platforms and 11738cf01f15 "libfdt: Don't use memcpy to handle unaligned
reads on ARM" improved the performance of these helpers.
In practice however, this only occurs when the user has forced the
device tree to be placed in memory in a non-aligned way, which in turn
violates both our rules and the Linux Kernel rules for how things must
reside in memory to function.
This "in practice" part is important as handling these other cases adds
visible (1 second or more) delay to boot in what would be considered the
fast path of the code.
Cc: Patrice CHOTARD <patrice.chotard@st.com>
Cc: Patrick DELAUNAY <patrick.delaunay@st.com>
Link: https://www.spinics.net/lists/devicetree-compiler/msg02972.html
Signed-off-by: Tom Rini <trini@konsulko.com>
Tested-by: Patrice Chotard <patrice.chotard@st.com>
As hinted by GCC 9, there is a return statement that returns
an uninitialized variable in optee_copy_firmware_node().
This patch addresses this.
Signed-off-by: Christoph Müllner <christoph.muellner@theobroma-systems.com>
Reviewed-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
drivers/rng/sandbox_rng.c requires rand() to be defined but configuration
option CONFIG_CONFIG_LIB_RAND selected in drivers/rng/Kconfig does not
exist.
test/lib/test_aes.c requires rand() to be defined.
Fix the selection criteria for choice "Pseudo-random library support type".
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
CONFIG_SPL_RSA is meant to control if lib/rsa/* is used for SPL. Adjust
lib/Makefile to consider this setting.
This was correctly setup with commit 51c14cd128 ("verified-boot: Minimal
support for booting U-Boot proper from SPL") and got lost with commit
089df18bfe ("lib: move hash CONFIG options to Kconfig").
Fixes: 089df18bfe ("lib: move hash CONFIG options to Kconfig")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Correct some function comments. Convert to Sphinx style.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
This is not really a CONFIG since it is not intended to be set by boards.
Move it into the compiler header with other similar defines, and rename
it.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present panic() is in the vsprintf.h header file. That does not seem
like an obvious choice for hang(), even though it relates to panic(). So
let's put hang() in its own header.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Migrate a few more files]
Signed-off-by: Tom Rini <trini@konsulko.com>
This commit add to u-boot the support to decrypt
fit image encrypted with aes. The FIT image contains
the key name and the IV name. Then u-boot look for
the key and IV in his device tree and decrypt images
before moving to the next stage.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
This commit add the support of encrypting image with aes
in mkimage. To enable the ciphering, a node cipher with
a reference to a key and IV (Initialization Vector) must
be added to the its file. Then mkimage add the encrypted
image to the FIT and add the key and IV to the u-boot
device tree.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Until now, we only support aes128. This commit add the support
of aes192 and aes256.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In the code, we use the size of the key for the
size of the block. It's true when the key is 128 bits,
but it become false for key of 192 bits and 256 bits.
So to prepare the support of aes192 and 256,
we introduce a constant for the iaes block size.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
UEFI programs like GRUB make change terminal colors which requires support
for ANSI escape sequences.
Let CONFIG_EFI_LOADER=y imply CONFIG_VIDEO_ANSI.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Use the correct protocol in efi_uc_stop() when detaching the driver from
the controller.
Change the block IO unit test for the block device driver to throw an error
instead of a todo if teardown fails.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
For automating testing we should be able to power off the test system.
The implementation of EFI_RESET_SHUTDOWN requires the do_poweroff()
function which is only available if CONFIG_CMD_POWEROFF=y.
Enable CONFIG_CMD_POWEROFF if PSCI reset is available.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Provide a unit test for the EFI_RNG_PROTOCOL.
The list of algorithms is read. Two random numbers are generated. The test
checks that the two numbers differ.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Install the EFI_RNG_PROTOCOL implementation for it's subsequent use by
the kernel for features like kaslr.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Add support for the EFI_RNG_PROTOCOL routines for the qemu arm64
platform. EFI_RNG_PROTOCOL is an uefi boottime service which is
invoked by the efi stub in the kernel for getting random seed for
kaslr.
The routines are platform specific, and use the virtio-rng device on
the platform to get random data.
The feature can be enabled through the following config
CONFIG_EFI_RNG_PROTOCOL
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Changed SPDX header to use /* instead of //.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Add guidcpy function to copy the source guid to the destination
guid. Use this function instead of memcpy for copying to the
destination guid.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Use void * instead of efi_guid_t * for arguments to allow copying unaligned
GUIDs. The GUIDs of configuration tables are __packed.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
U-Boot can be compiled with function tracing enabled.
When compiling with FTRACE __cyg_profile_func_enter() is called when a
function is entered and __cyg_profile_func_exit() when the function is
left.
To avoid a crash we have to define these function for the free-standing
UEFI binaries.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
On a VT100 terminal <ESC>[2J should be enough to both clear the whole
screen and set the cursor to position (1, 1). But the Linux console does
not behave like this. So send an extra <ESC>[H. For reference see the
console_codes(4) man page.
Add a function description.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Add the following file to .gitignore
efi_miniapp_file_image_exception.h
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Use efi_miniapp_*.h instead of file enumeration.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
When the GetInfo() method of the EFI_FILE_PROTOCOL is called to retrieve
the file system info we claim that the volume is read only and has no free
space. This leads to failures in programs that check this information
before writing to the volume like SCT's InstallSct.efi.
Currently there is no function to determine these parameters in U-Boot. So
let's return optimistic values:
Return that the volume is writable.
Return the volume size as free space.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
