At present EFI_SECURE BOOT selects RSA but does not necessarily enable
FIT_SIGNATURE. Mostly this is fine, but a few boards do not enable it,
so U-Boot tries to do RSA verification when loading FIT images, but it
is not enabled.
This worked because the condition for checking the RSA signature is
wrong in the fit_image_verify_with_data() function. In order to fix it
we need to fix this dependency. Make sure that FIT_SIGNATURE is enabled
so that RSA can be used.
It might be better to avoid using 'select' in this situation.
Signed-off-by: Simon Glass <sjg@chromium.org>
This was unfortunately applied despite much discussion about it beiong
the wrong way to implement this feature.
Revert it before too many other things are built on top of it.
This reverts commit ddf67daac3.
Signed-off-by: Simon Glass <sjg@chromium.org>
The move to driver model should by now be completed. To be able to remove
pre-driver model code from our block IO code require CONFIG_BLK=y for UEFI
support.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
When dropping SHA512_ALGO in general, we didn't catch some cases where
an option was selecting both SHA512 and SHA512_ALGO and caused them to
select SHA512 twice. Kconfig doesn't complain, but this is still wrong
and should be corrected.
Fixes: e60e449931 ("lib: Drop SHA512_ALGO in lieu of SHA512")
Reported-by: Andreas Schwab <schwab@suse.de>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
SHA512_ALGO was used as a "either SHA512 or SHA384", although the
implementations of these two algorithms share a majority of code.
From a Kconfig interface perspective, it makes sense to present two
distinct options. This requires #ifdefing out the SHA512
implementation from sha512.c. The latter doesn't make any sense.
It's reasonable to say in Kconfig that SHA384 depends on SHA512, and
seems to be the more polite way to handle the selection.
Thus, automatically select SHA512 when SHA384 is enabled.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
default n/no doesn't need to be specified. It is default option anyway.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
[trini: Rework FSP_USE_UPD portion]
Signed-off-by: Tom Rini <trini@konsulko.com>
The capsule signature is now part of our DTB. This is problematic when a
user is allowed to change/fixup that DTB from U-Boots command line since he
can overwrite the signature as well.
So Instead of adding the key on the DTB, embed it in the u-boot binary it
self as part of it's .rodata. This assumes that the U-Boot binary we load
is authenticated by a previous boot stage loader.
Reviewed-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Tested-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Tested-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
TCG PC Client PFP spec says "The Log Area Minimum Length
for the TCG event log MUST be at least 64KB." in ACPI chapter.
This commit increase the buffer size to 64KB.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Previously, the GPT device GUID was being used instead of the partition,
which was incorrect.
Signed-off-by: Alfonso Sánchez-Beato <alfonso.sanchez-beato@canonical.com>
Let EFI_LOADER select CONFIG_PARTITION_UUIDS.
Use log_warning() instead of printf() for warning.
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Although U-Boot supports capsule update on-disk, it's lack of support for
SetVariable at runtime prevents applications like fwupd from using it.
In order to perform the capsule update on-disk the spec says that the OS
must copy the capsule to the \EFI\UpdateCapsule directory and set a bit in
the OsIndications variable. The firmware then checks for the
EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED bit in OsIndications
variable, which is set by the submitter to trigger processing of the
capsule on the next reboot.
Let's add a config option which ignores the bit and just relies on the
capsule being present. Since U-Boot deletes the capsule while processing
it, we won't end up applying it multiple times.
Note that this is allowed for all capsules. In the future, once
authenticated capsules are fully supported, we can limit the functionality
to those only.
Signed-off-by: apalos <ilias.apalodimas@linaro.org>
Reword Kconfig description.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Chapter 23 of the EFI spec (rev 2.9) says:
"A specific updatable hardware firmware store must be represented by
exactly one FMP instance".
This is not the case for us, since both of our FMP protocols can be
installed at the same time because they are controlled by a single
'dfu_alt_info' env variable.
So make the config options depend on each other and allow the user to
install one of them at any given time. If we fix the meta-data provided
by the 'dfu_alt_info' in the future, to hint about the capsule type
(fit or raw) we can revise this and enable both FMPs to be installed, as
long as they target different firmware hardware stores
Note that we are not using a Kconfig 'choice' on purpose, since we
want to allow both of those to be installed and tested in sandbox
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
"TCG PC Client Platform Firmware Profile Specification"
requires to measure every attempt to load and execute
a OS Loader(a UEFI application) into PCR[4].
This commit adds the PE/COFF image measurement, extends PCR,
and appends measurement into Event Log.
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Replace CONFIG_HASH_CALCULATE by CONFIG_HASH
Fix conversions between pointers and u64.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The hash_calculate() symbol is provided by hash-checksum.c. It depends
on hash_progressive_lookup_algo(), provided when CONFIG_HASH=y.
The issue is that hash_calculate() is used by the efi_loader,
irregardless of CONFIG_FIT_SIGNATURE. As pointed out in
commit 87316da05f ("lib: introduce HASH_CALCULATE option"),
enabling hash_calculate() based on CONFIG_FIT_SIGNATURE is incorrect.
To resolve this, use CONFIG_HASH as the compile switch for
hash-checksum.c. This ensures that all dependencies are compiled, and
is the most natural Kconfig to use.
There is the issue of having to 'select HASH' in a couple of places
that already 'select SHA256'. This is a deeper problem with how hashes
are organized, and fixing it is beyonf the scope of this change.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Acked-by: Masahisa Kojima <masahisa.kojima@linaro.org>
When we think of Kconfig, we usually think of features that we like
to enable or not. Ideally, we wouldn't use Kconfig to fix a build
issue, although sometimes it might make sense. With Kconfig it's hard
to guarantee that the fix is universal. We can only say that it works
for the set of tested configurations. In the majority of cases, it's
preferable to let the linker figure things out for us.
The reverted commit attempted to fix a build issue by adding an
invisible Kconfig option. This is wrong in several ways:
It invents a new Kconfig variable when CONFIG_HASH already
exists for the same purpose.
Second, hash-checksum.c makes use of the hash_progressive_lookup_algo()
symbol, which is only provided with CONFIG_HASH, but this dependency
was not expressed in the reverted patch.
It feels like Kconfig is turning into a listing of all available
source files, and a buffet to 'select' which ones to compile. The
purpose of this revert is to enable the next change to make use of
CONFIG_HASH instead of adding to Kconfig.
This reverts commit 87316da05f.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Acked-by: Masahisa Kojima <masahisa.kojima@linaro.org>
This is preparation for PE/COFF measurement support.
PE/COFF image hash calculation is same in both
UEFI Secure Boot image verification and measurement in
measured boot. PE/COFF image parsing functions are
gathered into efi_image_loader.c, and exposed even if
UEFI Secure Boot is not enabled.
This commit also adds the EFI_SIGNATURE_SUPPORT option
to decide if efi_signature.c shall be compiled.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Build error occurs when CONFIG_EFI_SECURE_BOOT or
CONFIG_EFI_CAPSULE_AUTHENTICATE is enabled,
because hash-checksum.c is not compiled.
Since hash_calculate() implemented in hash-checksum.c can be
commonly used aside from FIT image signature verification,
this commit itroduces HASH_CALCULATE option to decide
if hash-checksum.c shall be compiled.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
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 <michal.simek@xilinx.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Add 'default y'.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Enable building of the crypto helper functions used during capsule
authentication by selecting IMAGE_SIGN_INFO.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
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 <xypron.glpk@gmx.de>
CC: Sughosh Ganu <sughosh.ganu@linaro.org>
CC: AKASHI Takahiro <takahiro.akashi@linaro.org>
CC: Ilias Apalodimas <ilias.apalodimas@linaro.org>
CC: Andre Przywara <andre.przywara@arm.com>
CC: Alexander Graf <agraf@csgraf.de>
CC: nd@arm.com
Signed-off-by: Jose Marinho <jose.marinho@arm.com>
Remove two EFI_CALL() indirections.
Move ESRT GUID in efidebug's list of GUIDs.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
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 <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
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 <xypron.glpk@gmx.de>
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 <xypron.glpk@gmx.de>
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 <xypron.glpk@gmx.de>
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 <xypron.glpk@gmx.de>
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 <sughosh.ganu@linaro.org>
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) <pc@cjr.nz>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Implement a reset function that we can call after ExitBootServices(),
when all driver model devices are gone.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
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 <takahiro.akashi@linaro.org>
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 <takahiro.akashi@linaro.org>
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 <takahiro.akashi@linaro.org>
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 <takahiro.akashi@linaro.org>
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 <takahiro.akashi@linaro.org>
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 <ilias.apalodimas@linaro.org>
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 <xypron.glpk@gmx.de>
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 <ilias.apalodimas@linaro.org>
Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
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 <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
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 <xypron.glpk@gmx.de>
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 <takahiro.akashi@linaro.org>
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 <xypron.glpk@gmx.de>
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 <xypron.glpk@gmx.de>
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 <xypron.glpk@gmx.de>
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 <ilias.apalodimas@linaro.org>
Signed-off-by: Pipat Methavanitpong <pipat1010@gmail.com>
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Enable EFI_RNG_PROTOCOL by default if DM_RNG is set.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Acked-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Remove superfluous 'if DM_RNG'
Reviewed-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>
