| Age | Commit message (Collapse) | Author |
|---|
|
Add a function to write a SPI descriptor to the generated ACPI code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
Add a function to write a GPIO descriptor to the generated ACPI code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
Some devices use interrupts but some use GPIOs. Since these are fully
specified in the device tree we can automatically produce the correct ACPI
descriptor for a device.
Add a function to handle this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
Add a function to write a GPIO descriptor to the generated ACPI code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: Drop comment about the type always being ACPI_GPIO_TYPE_IO]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
|
|
Add support for output of strings and streams of bytes.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
Add a function to write an interrupt descriptor to the generated ACPI
code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
Add a new file to handle generating ACPI code programatically. This is
used when information must be dynamically added to the tables, e.g. the
SSDT.
Initial support is just for writing simple values. Also add a 'base' value
so that the table can be freed. This likely doesn't happen in normal code,
but is nice to do in tests.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
At present U-Boot does not support the different ACPI status values, but
it is best to put this logic in a central place. Add a function to get the
device status.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
Add a function to build up the ACPI path for a device and another for its
scope.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
The current get_timer_us() uses 64-bit arithmetic on 32-bit machines.
When implementing microsecond-level timeouts, 32-bits is plenty. Add a
new function that uses an unsigned long. On 64-bit machines this is
still 64-bit, but this doesn't introduce a penalty. On 32-bit machines
it is more efficient.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
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>
|
|
To determine if a varible is on the of the authentication variables
PK, KEK, db, dbx we have to check both the name and the GUID.
Provide a function converting the variable-name/guid pair to an enum and
use it consistently.
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>
|
|
Update the UEFI secure state when variable 'PK' is updated in the TEE
variables implementation.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
When using secure boot functions needed both for file and TEE based UEFI
variables have to be moved to the common code module efi_var_common.c.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
A previous commit adds support for displaying variables RO flag.
Let's add it on the TEE backed variable storage as well.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
As variable services are available at runtime we have to expect EFI_SUCCESS
when calling the services.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
Enable UEFI variables at runtime.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
Saving UEFI variable as encoded U-Boot environment variables does not allow
implement run-time support.
Use a memory buffer for storing UEFI variables.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
Saving UEFI variable as encoded U-Boot environment variables does not allow
support at runtime.
Provide functions to manage a memory buffer with UEFI variables.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
Provide a memcpy() function that we can use at UEFI runtime.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
If the EFI_OPTIONAL_PTR is set in DebugDisposition, a NULL pointer does not
constitute an invalid parameter.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
We need ConvertPointer() to adjust pointers when implementing runtime
services within U-Boot.
After ExitBootServices() gd is not available anymore. So we should not use
EFI_ENTRY() and EFI_EXIT().
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 audit mode the UEFI variable SecureBoot is set to zero but the
efi_secure_boot flag is set to true.
The efi_secure_boot flag should match the UEFIvariable SecureBoot.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
Set the read only property of the UEFI variables AuditMode and DeployedMode
conforming to the UEFI specification.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
According to the UEFI specification the variable VendorKeys is 1 if the
"system is configured to use only vendor-provided keys".
As we do not supply any vendor keys yet the variable VendorKeys must be
zero.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
Do not change the value of parameter attributes in function
efi_set_variable_int(). This allows to use it later.
Do not use variable attr for different purposes but declare separate
variables (attr and old_attr).
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
Simplify the implementation of the UEFI boot manager:
* avoid EFI_CALL for SetVariable() and GetVariable()
* remove unnecessary type conversions
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
UEFI variables OsIndicationsSupported, PlatformLangCodes should be read
only.
Avoid EFI_CALL() for SetVariable().
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
Separate the remaining UEFI variable API functions GetNextVariableName and
QueryVariableInfo() from internal functions implementing them.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
We currently have two implementations of UEFI variables:
* variables provided via an OP-TEE module
* variables stored in the U-Boot environment
Read only variables are up to now only implemented in the U-Boot
environment implementation.
Provide a common interface for both implementations that allows handling
read-only variables.
As variable access is limited to very few source files put variable
related definitions into new include efi_variable.h instead of efi_loader.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
Avoid a possible NULL pointer dereference in efi_convert_pointer().
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
Don't call calloc(0, ..).
Consider return value of efi_get_child_controllers().
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
Commit 1b6c08548c85 ("efi_loader: image_loader: replace debug to
EFI_PRINT") leads to a build warning on 32bit systems:
lib/efi_loader/efi_image_loader.c: In function ‘efi_image_parse’:
include/efi_loader.h:123:8: warning: format ‘%lu’ expects argument
of type ‘long unsigned int’, but argument 8 has
type ‘size_t’ {aka ‘unsigned int’} [-Wformat=]
Use %zu for printing size_t.
Fixes: 1b6c08548c85 ("efi_loader: image_loader: replace debug to
EFI_PRINT")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
There's 2 variables in efi_get_next_variable_name() checking the size of
the variable name. Let's get rid of the reduntant definition and
simplitfy the code a bit.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
This function will be used to implement public_key_verify_signature()
in a later patch. rsa_verify() is not suitable here because calculation
of message digest is not necessary.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
In case that a type of certificate in "db" or "dbx" is
EFI_CERT_X509_SHA256_GUID, it is actually not a certificate which contains
a public key for RSA decryption, but a digest of image to be loaded.
If the value matches to a value calculated from a given binary image, it is
granted for loading.
With this patch, common digest check code, which used to be used for
unsigned image verification, will be extracted from
efi_signature_verify_with_sigdb() into efi_signature_lookup_digest(), and
extra step for digest check will be added to efi_image_authenticate().
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
|
A signed image may have multiple signatures in
- each WIN_CERTIFICATE in authenticode, and/or
- each SignerInfo in pkcs7 SignedData (of WIN_CERTIFICATE)
In the initial implementation of efi_image_authenticate(), the criteria
of verification check for multiple signatures case is a bit ambiguous
and it may cause inconsistent result.
With this patch, we will make sure that verification check in
efi_image_authenticate() should pass against all the signatures.
The only exception would be
- the case where a digest algorithm used in signature is not supported by
U-Boot, or
- the case where parsing some portion of authenticode has failed
In those cases, we don't know how the signature be handled and should
just ignore them.
Please note that, due to this change, efi_signature_verify_with_sigdb()'s
function prototype will be modified, taking "dbx" as well as "db"
instead of outputing a "certificate." If "dbx" is null, the behavior would
be the exact same as before.
The function's name will be changed to efi_signature_verify() once
current efi_signature_verify() has gone due to further improvement
in intermediate certificates support.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
|
There are a couple of occurrences of hash calculations in which a new
efi_hash_regions will be commonly used.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
|
Since the size check against an entry in efi_search_siglist() is
incorrect, this function will never find out a to-be-matched certificate
and its associated revocation time in the signature list.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
|
Since the certificate table, which is indexed by
IMAGE_DIRECTORY_ENTRY_SECURITY and contains authenticode in PE image,
doesn't always exist, we should make sure that we will retrieve its pointer
only if it exists.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
|
UEFI specification requires that we shall support three type of
certificates of authenticode in PE image:
WIN_CERT_TYPE_EFI_GUID with the guid, EFI_CERT_TYPE_PCKS7_GUID
WIN_CERT_TYPE_PKCS_SIGNED_DATA
WIN_CERT_TYPE_EFI_PKCS1_15
As EDK2 does, we will support the first two that are pkcs7 SignedData.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
|
Move ADDR_MAP related config options from include/configs/*.h to the
proper place in lib/Kconfig. This has been done using
./tools/moveconfig.py and manual inspection of the generated changes.
This is a preparation to use ADDR_MAP helper on ARM 32bit Raspberry Pi4
board for mapping the PCIe XHCI MMIO, which is above the 4GiB identity
mapping limit.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
rsa_verify() expects a memory region and wants to do the hashing itself,
but there may be cases where the hashing is done via other means,
like hashing a squashfs rootfs.
So add rsa_verify_hash() to allow verifiying a signature against
an existing hash. As this entails the same verification routines
we can just move the relevant code over from rsa_verify() and also
call rsa_verify_hash() from there.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
|
|
This is defined only when __lp64__ is defined. That means that ulong is
64 bits long. Therefore we don't need to use a separate u64 type on those
architectures.
Fix up the code to take advantage of that, removing the preprocessor
conditions.
Also include the missing header file that defines MEM_SUPPORT_64BIT_DATA
Fixes: 09140113108 ("command: Remove the cmd_tbl_t typedef")
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Define this macro always so we don't need the preprocessor to check it.
Convert the users to #if instead of #ifdef.
Note that '#if MEM_SUPPORT_64BIT_DATA' does not give an error if the
macro is not define. It just assumes zero.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>
|
|
padding_pss_verify only works with the default pss salt setting of -2
(length to be automatically determined based on the PSS block structure)
not -1 (salt length set to the maximum permissible value), which makes
verifications of signatures with that saltlen fail.
Until this gets implemented at least document this behaviour.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
n, rr and rrtmp are used for internal calculations, but in the end
the results are copied into separately allocated elements of the
actual key_prop, so the n, rr and rrtmp elements are not used anymore
when returning from the function and should of course be freed.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
When calculating rrtmp/rr rsa_gen_key_prop() tries to make
(((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and
(((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[]
with rlen being num_bits * 2
On a 4096bit key this comes down to to 257 uint32_t elements
in rr and 256 elements in rrtmp but with the current allocation
rr and rrtmp only have 129 uint32_t elements.
On 2048bit keys this works by chance as the defined max_rsa_size=4096
allocates a suitable number of elements, but with an actual 4096bit key
this results in other memory parts getting overwritten.
So as suggested by Heinrich Schuchardt just use the actual bit-size
of the key as base for the size calculation, in turn making the code
compatible to any future keysizes.
Suggested-by: Heinrich Schuchardt <xypron.debian@gmx.de>
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
