summaryrefslogtreecommitdiff
path: root/include/tee.h
AgeCommit message (Collapse)AuthorFilesLines
2021-12-31efi_loader: Don't limit the StMM buffer size explicitlyIlias Apalodimas1-0/+1
Currently we allow and explicitly check a single shared page with StandAloneMM. This is dictated by OP-TEE which runs the application. However there's no way for us dynamically discover the number of pages we are allowed to use. Since writing big EFI signature list variable requires more than a page, OP-TEE has bumped the number of shared pages to four. Let's remove our explicit check and allow the request to reach OP-TEE even if it's bigger than what it supports. There's no need to sanitize the number of pages internally. OP-TEE will fail if we try to write more than it's allowed. The error will just trigger later on, during the StMM access. While at it add an error message to help users figure out what failed. Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org> Signed-off-by: Ilias Apalodimas <apalos@gmail.com>
2021-11-23tee: optee: define TEE error code TEE_ERROR_SHORT_BUFFEREtienne Carriere1-0/+1
Adds TEE_ERROR_SHORT_BUFFER as TEE error code. This error code is commonly used by TEEs to inform caller that the buffer(s) it provided is too small for the desired operation. Cc: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
2021-11-23tee: define session login identifiersEtienne Carriere1-2/+21
Define identifiers for clnt_login field in struct tee_open_session_arg based in GlobalPlatform Device TEE IDs and on the REE_KERNEL identifier extension from OP-TEE OS. Cc: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
2021-10-05tee: add a stub for tee_find_devicePatrick Delaunay1-0/+11
Add stub for tee_find_device function when CONFIG_TEE is not activated to simplify the caller code. This patch allows to remove the CONFIG_IS_ENABLED(OPTEE) tests for stm32 platform. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Acked-by: Etienne Carriere <etienne.carriere@inaro.org> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
2021-07-23tee: optee: sync cache on pre-reloc OP-TEE invocationEtienne Carriere1-0/+6
This change ensures both U-Boot and OP-TEE see the same content from shared memory when OP-TEE is invoked prior U-Boot relocation. This change is required since U-Boot may execute with data cache off while OP-TEE always enables cache on memory shared with U-Boot. Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2021-02-02common: Drop asm/global_data.h from common headerSimon Glass1-0/+2
Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
2020-05-19common: Drop linux/bitops.h from common headerSimon Glass1-0/+1
Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
2019-04-27avb: add support for named persistent valuesIgor Opaniuk1-0/+2
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 <sjg@chromium.org> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Igor Opaniuk <igor.opaniuk@gmail.com>
2018-12-15tee: change return code for REE FS supplicant cmdIgor Opaniuk1-0/+1
If OP-TEE core is compiled with support of REE FS and RPMB at the same time (CFG_RPMB_FS ?= y; CFG_RPMB_FS ?= y), and persistent storage API is used with TEE_STORAGE_PRIVATE storage id, it will lead to TA panic. E/TC:? 0 TA panicked with code 0xffff0009 ..... E/TC:? 0 Call stack: E/TC:? 0 0x000000004002f2f8 TEE_OpenPersistentObject at lib/libutee/tee_api_objects.c:422 In this particular case TEE_ERROR_STORAGE_NOT_AVAILABLE is more suitable than TEE_ERROR_NOT_IMPLEMENTED, as it provides to a TA a possibility to handle this error code [1]. >From GPD TEE Internal Core specification [2]: TEE_ERROR_STORAGE_NOT_AVAILABLE - if the persistent object is stored in a storage area which is currently inaccessible. It may be associated with the device but unplugged, busy, or inaccessible for some other reason. [1]: https://github.com/OP-TEE/optee_os/blob/94db01ef448d1e552161c2d861d57a5f8bda0cc0/lib/libutee/tee_api_objects.c#L419 [2]: https://globalplatform.org/wp-content/uploads/2018/06/GPD_TEE_Internal_Core_API_Specification_v1.1.2.50_PublicReview.pdf Signed-off-by: Igor Opaniuk <igor.opaniuk@linaro.org> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
2018-10-07tee: optee: support AVB trusted applicationJens Wiklander1-0/+38
Adds configuration option OPTEE_TA_AVB and a header file describing the interface to the Android Verified Boot 2.0 (AVB) trusted application provided by OP-TEE. Tested-by: Igor Opaniuk <igor.opaniuk@linaro.org> Reviewed-by: Igor Opaniuk <igor.opaniuk@linaro.org> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-10-07Add UCLASS_TEE for Trusted Execution EnvironmentJens Wiklander1-0/+336
Adds a uclass to interface with a TEE (Trusted Execution Environment). A TEE driver is a driver that interfaces with a trusted OS running in some secure environment, for example, TrustZone on ARM cpus, or a separate secure co-processor etc. The TEE subsystem can serve a TEE driver for a Global Platform compliant TEE, but it's not limited to only Global Platform TEEs. The over all design is based on the TEE subsystem in the Linux kernel, tailored for U-Boot. Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Igor Opaniuk <igor.opaniuk@linaro.org> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>