| Age | Commit message (Collapse) | Author |
|---|
|
EFI_TCG2 depends not only on TPMv2 but also on the underlying algorithms.
So select the missing SHA1, SHA256, SHA384 and SHA512 we currently support
Reported-by: Michal Simek <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
Add 'default y'.
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
enabled
Enable building of the crypto helper functions used during capsule
authentication by selecting IMAGE_SIGN_INFO.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
The ESRT is initialised during efi_init_objlist after
efi_initialize_system_table().
The ESRT is recreated from scratch at the following events:
- successful UpdateCapsule;
- FMP instance install.
The code ensures that every ESRT entry has a unique fw_class value.
Limitations:
- The ESRT is not updated if an FMP instance is uninstalled;
- the fields image_type and flags are in the current implementation left
undefined. Setting these values will require a per-platform function
that returns the image_type/flags as a function of the image fw_class.
CC: Heinrich Schuchardt <[email protected]>
CC: Sughosh Ganu <[email protected]>
CC: AKASHI Takahiro <[email protected]>
CC: Ilias Apalodimas <[email protected]>
CC: Andre Przywara <[email protected]>
CC: Alexander Graf <[email protected]>
CC: [email protected]
Signed-off-by: Jose Marinho <[email protected]>
Remove two EFI_CALL() indirections.
Move ESRT GUID in efidebug's list of GUIDs.
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Up to now we install EFI_LOAD_FILE2_PROTOCOL to load an initrd
unconditionally. Although we correctly return various EFI exit codes
depending on the file status (i.e EFI_NO_MEDIA, EFI_NOT_FOUND etc), the
kernel loader, only falls back to the cmdline interpreted initrd if the
protocol is not installed.
This creates a problem for EFI installers, since they won't be able to
load their own initrd and continue the installation. It also makes the
feature hard to use, since we can either have a single initrd or we have
to recompile u-boot if the filename changes.
So let's introduce a different logic that will decouple the initrd
path from the config option we currently have.
When defining a UEFI BootXXXX we can use the filepathlist and store
a file path pointing to our initrd. Specifically the EFI spec describes:
"The first element of the array is a device path that describes the device
and location of the Image for this load option. Other device paths may
optionally exist in the FilePathList, but their usage is OSV specific"
When the EFI application is launched through the bootmgr, we'll try to
interpret the extra device path. If that points to a file that exists on
our disk, we'll now install the load_file2 and the efi-stub will be able
to use it.
This opens up another path using U-Boot and defines a new boot flow.
A user will be able to control the kernel/initrd pairs without explicit
cmdline args or GRUB.
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
GRUB_ARM32_WORKAROUND can be disabled on ARCH_SUNXI as the Allwinner SoCs
only have a level 2 cache controlled via CP15 and not an architecturally
defined cache. Having the cache available speeds up booting Linux.
On ARCH_BCM283X it is already disabled via rpi_2_defconfig. But let's move
this setting to Kconfig.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
In EFI 1.10 a version of the Unicode collation protocol using ISO 639-2
language codes existed. This protocol is not part of the UEFI specification
any longer. It was however required to run the UEFI Self Certification Test
(SCT) II, version 2.6, 2017. So we implemented it for the sole purpose of
running the SCT.
As the SCT does not need the protocol anymore it is time for removal.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Allow the EFI_DEVICE_PATH_UTILITIES_PROTOCOL to be disabled via
configuration.
On systems that are very tight on U-Boot image size we may want to disable
the protocol. As it is required to run the UEFI Shell enable it by default.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Allow EFI_DT_FIXUP_PROTOCOL to be disabled via configuration.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Some boards are very tight on the binary size. Booting via UEFI is possible
without using the boot manager.
Provide a configuration option to make the boot manager available.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Add support for authenticating uefi capsules. Most of the signature
verification functionality is shared with the uefi secure boot
feature.
The root certificate containing the public key used for the signature
verification is stored as part of the device tree blob. The root
certificate is stored as an efi signature list(esl) file -- this file
contains the x509 certificate which is the root certificate.
Signed-off-by: Sughosh Ganu <[email protected]>
|
|
Currently the size of the buffer to keep UEFI variables in memory is fixed
at 16384 bytes. This size has proven to be too small for some use cases.
Make the size of the memory buffer for UEFI variables customizable.
Reported-by: Paulo Alcantara (SUSE) <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
Implement a reset function that we can call after ExitBootServices(),
when all driver model devices are gone.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
In this commit, a very simple firmware management protocol driver
is implemented. It will take a binary image in a capsule file and
apply the data using dfu backend storage drivers via dfu_write_by_alt()
interface.
So "dfu_alt_info" variable should be properly set to specify a device
and location to be updated. Please read README.dfu.
Signed-off-by: AKASHI Takahiro <[email protected]>
|
|
In this commit, a very simple firmware management protocol driver
is implemented. It will take a common FIT image firmware in a capsule
file and apply the data using dfu backend storage drivers via
update_fit() interface.
So "dfu_alt_info" variable should be properly set to specify a device
and location to be updated. Please read README.dfu.
Fit image is a common file format for firmware update on U-Boot, and
this protocol works neatly just as a wrapper for one.
Signed-off-by: AKASHI Takahiro <[email protected]>
|
|
A capsule tagged with the guid, EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID,
is handled as a firmware update object.
What efi_update_capsule() basically does is to load any firmware management
protocol (or fmp) drivers contained in a capsule, find out an appropriate
fmp driver and then invoke its set_image() interface against each binary
in a capsule.
In this commit, however, loading drivers is not supported.
The result of applying a capsule is set to be stored in "CapsuleXXXX"
variable, but its implementation is deferred to a fmp driver.
Signed-off-by: AKASHI Takahiro <[email protected]>
|
|
Capsule data can be loaded into the system either via UpdateCapsule
runtime service or files on a file system (of boot device).
The latter case is called "capsules on disk", and actual updates will
take place at the next boot time.
In this commit, we will support capsule on disk mechanism.
Please note that U-Boot itself has no notion of "boot device" and
all the capsule files to be executed will be detected only if they
are located in a specific directory, \EFI\UpdateCapsule, on a device
that is identified as a boot device by "BootXXXX" variables.
Signed-off-by: AKASHI Takahiro <[email protected]>
|
|
In this commit, skeleton functions for capsule-related API's are
added under CONFIG_EFI_UPDATE_CAPSULE configuration.
Detailed implementation for a specific capsule type will be added
in the succeeding patches.
Signed-off-by: AKASHI Takahiro <[email protected]>
|
|
In the previous patches we only introduced a minimal subset of the
EFI_TCG2_PROTOCOL protocol implementing GetCapability().
So let's continue adding features to it, introducing the
GetEventLog() and HashLogExtendEvent() functions.
In order to do that we first need to construct the eventlog in memory,
specifically in EFI_BOOT_SERVICES_DATA memory and a configuration table
from EFI_ACPI_MEMORY_NVS.
U-Boot won't currently add any events to the log or measure any
components, but will expose the necessary EFI APIs for applications
to do so.
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
Enable EFI_SET_TIME on the sandbox and QEMU ARM to ensure that we compile
and test the relevant code.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Since U-boot EFI implementation is getting richer it makes sense to
add support for EFI_TCG2_PROTOCOL taking advantage of any hardware TPM
available on the device.
This is the initial implementation of the protocol which only adds
support for GetCapability(). It's limited in the newer and safer
TPMv2 devices.
Signed-off-by: Ilias Apalodimas <[email protected]>
Acked-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
If this option, CONFIG_EFI_SETUP_EARLY, is enabled, the initialisation
of UEFI subsystem will be done as part of U-Boot initialisation.
Please note that this option won't be enabled explicitly by users,
instead, should be enabled implicitly by other configuration options.
Specifically, this feature will be utilised in implementing capsule-on-disk
feature.
Signed-off-by: AKASHI Takahiro <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
CONFIG_EFI_GRUB_ARM32 is only needed for architectures with caches that are
not managed via CP15 (or for some outdated buggy versions of GRUB). It
makes more sense to disable the setting per architecture than per defconfig.
Move QEMU's CONFIG_EFI_GRUB_ARM32_WORKAROUND=n from defconfig to Kconfig.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
In this commit, efi_signature_verify(with_sigdb) will be re-implemented
using pcks7_verify_one() in order to support certificates chain, where
the signer's certificate will be signed by an intermediate CA (certificate
authority) and the latter's certificate will also be signed by another CA
and so on.
What we need to do here is to search for certificates in a signature,
build up a chain of certificates and verify one by one. pkcs7_verify_one()
handles most of these steps except the last one.
pkcs7_verify_one() returns, if succeeded, the last certificate to verify,
which can be either a self-signed one or one that should be signed by one
of certificates in "db". Re-worked efi_signature_verify() will take care
of this step.
Signed-off-by: AKASHI Takahiro <[email protected]>
|
|
Include a file with the initial values for non-volatile UEFI variables
into the U-Boot binary. If this variable is set, changes to variable PK
will not be allowed.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
The file based and the OP-TEE based UEFI variable store are mutually
exclusive. Define them as choice options in Kconfig.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Persist non-volatile UEFI variables in a file on the EFI system partition.
The file is written whenever a non-volatile UEFI variable is changed after
initialization of the UEFI sub-system.
The file is read during the UEFI sub-system initialization to restore
non-volatile UEFI variables.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
The UEFI spec requires support for the FAT file system.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
In OP-TEE we can run EDK2's StandAloneMM on a secure partition.
StandAloneMM is responsible for the UEFI variable support. In
combination with OP-TEE and it's U-Boot supplicant, variables are
authenticated/validated in secure world and stored on an RPMB partition.
So let's add a new config option in U-Boot implementing the necessary
calls to OP-TEE for the variable management.
Signed-off-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Pipat Methavanitpong <[email protected]>
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Under this configuration, UEFI secure boot support will be added
in later patches.
Signed-off-by: AKASHI Takahiro <[email protected]>
|
|
Enable EFI_RNG_PROTOCOL by default if DM_RNG is set.
Signed-off-by: Peter Robinson <[email protected]>
Acked-by: Sughosh Ganu <[email protected]>
Remove superfluous 'if DM_RNG'
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
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/[email protected]/T/#m4a25eb33112fab7a22faa0fd65d4d663209af32f
Signed-off-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Do not use quotation marks for Kconfig help text.
Replace rng abbreviation by full words.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Changed SPDX header to use /* instead of //.
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
UEFI applications like GRUB and SCT assume that function keys are enabled
on the keyboard.
Let EFI_LOADER imply USB_KEYBOARD_FN_KEYS.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Some of the ARM11 boards have tight limits on the size of U-Boots. Hence
use EFI_LOADER=n as default on ARM11.
Set EFI_LOADER=y for the Raspberry Pi and Raspberry Pi Zero as these boards
have sufficient storage on the SD card.
Suggested-by: Tom Rini <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
With an implementation for allow_unaligned() available for arm1136 and
arm1176 UEFI can be supported on these architectures.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
fatload USB was reported to fail on the Sheevaplug. Debugging showed that
this was caused by an incorrect unaligned write to memory in
path_to_uefi().
UEFI on ARM requires that unaligned memory access is enabled.
* ARMv5 does not support unaligned access at all.
* ARMv6 supports unaligned access when we clear the A flag and set the
U flag.
* On ARMv7 unaligned access is possible when clearing the aligned flag,
which we do in function allow_unaligned() (arch/arm/cpu/armv7/sctlr.S).
For none of the other cpus in arch/arm/cpu/ we have implemented a
similar function.
* ARMv8 allows unaligned access.
Let EFI_LOADER on ARM depend on SYS_CPU=armv7 or SYS_CPU=armv8.
Once we have implemented allow_unaligned() for other ARM CPUs we can add
these to Kconfig.
Reported-by: Gray Remlin <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
GRUB on ARM 32bit prior to version 2.04 lacks proper handling of caches.
In U-Boot v2019.04 a workaround for this was inadvertently removed.
The workaround is currently also needed for booting on systems with caches
that cannot be managed via CP15 (e.g. with an i.MX6 CPU).
Re-enable the workaround and make it customizable.
Fixes: f69d63fae281 ("efi_loader: use efi_start_image() for bootefi")
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Move the logic determining which board supports reset at runtime to Kconfig.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
The GetTime() and the SetTime() runtime services are not obligatory. So
let's make them customizable.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
In EFI 1.10 a version of the Unicode collation protocol using ISO 639-2
language codes existed. This protocol is not part of the UEFI specification
any longer. Unfortunately it is required to run the UEFI Self Certification
Test (SCT) II, version 2.6, 2017. So we implement it here for the sole
purpose of running the SCT. It can be removed once a compliant SCT is
available.
The configuration option defaults to no.
Signed-off-by: Rob Clark <[email protected]>
Most of Rob's original patch is already merged. Only the deprecated
protocol is missing. Rebase it and make it configurable.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Rename variables to make it clear they refer to the Unicode collation
protocol identified by the EFI_UNICODE_PROTOCOL2_GUID.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
The device path to text protocol is not needed for EBBR compliance. So
let's make it a customizable option.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
The Unicode collation protocol is not needed for EBBR compliance. So let's
make it a customizable option.
The Unicode capitalization table is only needed by this protocol. So let it
depend on the Unicode collation protocol.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
No need to mention U-Boot in brief description.
Fix several typos, mention iPXE.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Use if/endif for dependencies to give structure to the configuration menu.
Sort important settings to the top.
Abbreviate the short description of EFI_LOADER_HII.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
The UEFI variables PlatformLang and PlatformLangCodes specify the current
firmware language and the list of all available languages.
Currently their values are hard coded. With the patch a new configuration
variable EFI_PLATFORM_LANG_CODES is provided.
When initializing the UEFI subsystem this configuration variable is used to
initialize PlatformLangCodes. The value of variable PlatformLang is read.
If it is not set, the first language specified in EFI_PLATFORM_LANG_CODES
is used to initialize PlatformLang.
Suggested-by: Takahiro Akashi <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
As the UEFI shell requires the HII protocols let's enable them by default.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Heinrich ran into issues with HII and iPXE which lead to #SErrors on
his Odroid-C2 system. We definitely do not want to regress just yet,
so let's not expose the HII protocols by default.
Instead, let's make it a config option that people can play with
This way, we can stabilize the code in tree without breaking any
users.
Once someone figures out, why this breaks iPXE (probably a NULL
dereference), we can enable it by default.
Reported-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
---
v1 -> v2:
- Remove HII selftest as well
v2 -> v3:
- Make config option
|
