u-boot.git/include/tee, branch v2023.01-rc2

treewide: Drop image_header_t typedef

2022-09-29T20:07:57+00:00

This is not needed and we should avoid typedefs. Use the struct instead
and rename it to indicate that it really is a legacy struct.

Signed-off-by: Simon Glass

drivers: tee: optee: discover OP-TEE services

2022-09-14T19:23:03+00:00

This change defines resources for OP-TEE service drivers to register
themselves for being bound to when OP-TEE firmware reports the related
service is supported. OP-TEE services are discovered during optee
driver probe sequence which mandates optee driver is always probe once
bound.

Discovery of optee services and binding to related U-Boot drivers is
embedded upon configuration switch CONFIG_OPTEE_SERVICE_DISCOVERY.

Cc: Jens Wiklander 
Cc: Patrick Delaunay 
Signed-off-by: Etienne Carriere 
Reviewed-by: Patrick Delaunay

lib: optee: Avoid CONFIG_TZDRAM_* in optee_verify_bootm_image()

2021-10-05T12:46:23+00:00

The configs TZDRAM_BASE and TZDRAM_SIZE are expected to describe the
memory allocated to the OPTEE region. according to according to commit
c5a6e8bd00cc ("optee: Add optee_verify_bootm_image()"). The TZDRAM is
with some limitations, described by "/reserved-memory" nodes in the
devicetree.

Consequently TZDRAM_BASE and TZDRAM_SIZE can point to imaginary
regions which have nothing to do with actual DRAM. They are not used
to configure the hardware or set up the Trust Zone Controller (TZC)
for OP-TEE -- the devicetree values are used instead.

When a valid OP-TEE image does not fall within the region described by
these configs, u-boot will refuse to load it. In fact, it mostly
serves to cause "bootm" to reject perfectly good OP-TEE images.

Ironically, someone has to correctly configure the devicetree for
TZDRAM, then go back and enter the same information in Kconfig for
"bootm". To remedy this, do not use TZDRAM_BASE and TZDRAM_SIZE in the
verification of OPTEE images.

Signed-off-by: Alexandru Gagniuc

lib: optee: remove the duplicate CONFIG_OPTEE

2021-10-05T12:44:48+00:00

The configuration CONFIG_OPTEE is defined 2 times:
1- in lib/optee/Kconfig for support of OPTEE images loaded by bootm command
2- in drivers/tee/optee/Kconfig for support of OP-TEE driver.

It is abnormal to have the same CONFIG define for 2 purpose;
and it is difficult to managed correctly their dependencies.

Moreover CONFIG_SPL_OPTEE is defined in common/spl/Kconfig
to manage OPTEE image load in SPL.

This definition causes an issue with the macro CONFIG_IS_ENABLED(OPTEE)
to test the availability of the OP-TEE driver.

This patch cleans the configuration dependency with:
- CONFIG_OPTEE_IMAGE (renamed) => support of OP-TEE image in U-Boot
- CONFIG_SPL_OPTEE_IMAGE (renamed) => support of OP-TEE image in SPL
- CONFIG_OPTEE (same) => support of OP-TEE driver in U-Boot
- CONFIG_OPTEE_LIB (new) => support of OP-TEE library

After this patch, the macro have the correct behavior:
- CONFIG_IS_ENABLED(OPTEE_IMAGE) => Load of OP-TEE image is supported
- CONFIG_IS_ENABLED(OPTEE) => OP-TEE driver is supported

Signed-off-by: Patrick Delaunay

lib: optee: migration optee_copy_fdt_nodes for OF_LIVE support

2021-04-12T18:25:31+00:00

The optee_copy_fdt_nodes is only used to copy op-tee nodes
of U-Boot device tree (from gd->fdt_blob when OF_LIVE is not activated)
to external device tree but it is not compatible with OF_LIVE.

This patch migrates all used function fdt_ functions to read node on
old_blob to ofnode functions, compatible with OF_LIVE and remove this
parameter "old_blob".

The generated "device tree" is checked on stm32mp platform with OF_LIVE
activated.

Signed-off-by: Patrick Delaunay

common: SCP03 control (enable and provision of keys)

2021-03-13T18:14:52+00:00

This Trusted Application allows enabling SCP03 as well as provisioning
the keys on TEE controlled secure element (ie, NXP SE050).

All the information flowing on buses (ie I2C) between the processor
and the secure element must be encrypted. Secure elements are
pre-provisioned with a set of keys known to the user so that the
secure channel protocol (encryption) can be enforced on the first
boot. This situation is however unsafe since the keys are publically
available.

For example, in the case of the NXP SE050, these keys would be
available in the OP-TEE source tree [2] and of course in the
documentation corresponding to the part.

To address that, users are required to rotate/provision those keys
(ie, generate new keys and write them in the secure element's
persistent memory).

For information on SCP03, check the Global Platform HomePage and
google for that term [1]
[1] globalplatform.org
[2] https://github.com/OP-TEE/optee_os/
    check:
    core/drivers/crypto/se050/adaptors/utils/scp_config.c

Signed-off-by: Jorge Ramirez-Ortiz 
Reviewed-by: Simon Glass

drivers: tee: sandbox: add rpc test ta emulation

2021-02-16T16:48:20+00:00

This adds support for RPC test trusted application emulation, which
permits to test reverse RPC calls to TEE supplicant. Currently it covers
requests to the I2C bus from TEE.

Signed-off-by: Igor Opaniuk 
Reviewed-by: Simon Glass 
Reviewed-by: Jens Wiklander 
Acked-by: Etienne Carriere

common: Drop image.h from common header

2020-05-18T21:33:33+00:00

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass

image: fdt: copy possible optee nodes to a loaded devicetree

2019-11-14T13:09:34+00:00

The loading convention for optee or any other tee on arm64 is as bl32
parameter to the trusted-firmware. So TF-A gets invoked with the TEE as
bl32 and main u-boot as bl33. Once it has done its startup TF-A jumps
into the bl32 for the TEE startup, returns to TF-A and then jumps to bl33.

All of them get passed a devicetree as parameter and all components often
get loaded from a FIT image.

OP-TEE will create additional nodes in that devicetree namely a firmware
node and possibly multiple reserved-memory nodes.

While this devicetree is used in main u-boot, in most cases it won't be
the one passed to the actual kernel. Instead most boot commands will load
a new devicetree from somewhere like mass storage of the network, so if
that happens u-boot should transfer the optee nodes to that new devicetree.

To make that happen introduce optee_copy_fdt_nodes() called from the dt
setup function in image-fdt which after checking for the optee presence
in the u-boot dt will make sure a optee node is present in the kernel dt
and transfer any reserved-memory regions it can find.

Signed-off-by: Heiko Stuebner 
Reviewed-by: Jens Wiklander

avb: add support for named persistent values

2019-04-26T22:58:22+00:00

AVB 2.0 spec. revision 1.1 introduces support for named persistent values
that must be tamper evident and allows AVB to store arbitrary key-value
pairs [1].

Introduce implementation of two additional AVB operations
read_persistent_value()/write_persistent_value() for retrieving/storing
named persistent values.

Correspondent pull request in the OP-TEE OS project repo [2].

[1]: https://android.googlesource.com/platform/external/avb/+/android-9.0.0_r22
[2]: https://github.com/OP-TEE/optee_os/pull/2699

Reviewed-by: Simon Glass 
Reviewed-by: Sam Protsenko 
Signed-off-by: Igor Opaniuk