summaryrefslogtreecommitdiff
path: root/drivers/tee
AgeCommit message (Collapse)Author
2020-07-29drivers: tee: broadcom: add optee based bnxt fw load driverVikas Gupta
Add optee based bnxt fw load driver. bnxt is Broadcom NetXtreme controller Ethernet card. This driver is used to load bnxt firmware binary using OpTEE. Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-05-18common: Drop log.h from common headerSimon Glass
Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-04-17tee: optee: use dev_info in print_os_revisionPatrick Delaunay
Display TEE version at information level; this patch replaces debug() call to dev_info() in print_os_revision() function. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
2020-02-05dm: core: Create a new header file for 'compat' featuresSimon Glass
At present dm/device.h includes the linux-compatible features. This requires including linux/compat.h which in turn includes a lot of headers. One of these is malloc.h which we thus end up including in every file in U-Boot. Apart from the inefficiency of this, it is problematic for sandbox which needs to use the system malloc() in some files. Move the compatibility features into a separate header file. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-02-05dm: core: Require users of devres to include the headerSimon Glass
At present devres.h is included in all files that include dm.h but few make use of it. Also this pulls in linux/compat which adds several more headers. Drop the automatic inclusion and require files to include devres themselves. This provides a good indication of which files use devres. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de>
2019-12-05drivers: optee: rpmb: fix returning CID to TEEJorge Ramirez-Ortiz
The mmc CID value is one of the input parameters used to provision the RPMB key. The trusted execution environment expects this value to be specified in big endian format. Before this fix, on little endian systems, the value returned by the linux kernel mmc driver differed from the one returned by u-boot. This meant that if linux provisioned the RPMB key, u-boot would not have access to the partition (and the other way around). Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
2019-08-11env: Drop the ACTION typedefSimon Glass
Avoid using a typedef here which is unnecessary. Add an 'env_' prefix to both the enum and its members to make it clear that these are related to the environment. Add an ENV prefix to these two flags so that it is clear what they relate to. Also move them to env.h since they are part of the public API. Use an enum rather than a #define to tie them together. Signed-off-by: Simon Glass <sjg@chromium.org>
2019-08-11env: Drop the ENTRY typedefSimon Glass
U-Boot is not supposed to use typedef for structs anymore. Also this name is the same as the ENTRY() macro used in assembler files, and 'entry' itself is widely used in U-Boot (>8k matches). Drop the typedef and rename the struct to env_entry to reduce confusion. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2019-05-09test/py: avb: fix test_avb_persistent_values failIgor Opaniuk
Fix test_avb_persistent_values() pytest, which was failing because of wrong size value provided from tee sandbox driver. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Igor Opaniuk <igor.opaniuk@gmail.com>
2019-04-26avb: add support for named persistent valuesIgor Opaniuk
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 Opaniuk
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: add sandbox driverJens Wiklander
Adds a sandbox tee driver which emulates a generic TEE with the OP-TEE AVB TA. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Fix printf warnings in ta_avb_invoke_func, slots is uint] Signed-off-by: Tom Rini <trini@konsulko.com>
2018-10-07tee: optee: support AVB trusted applicationJens Wiklander
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-07optee: support routing of rpmb data frames to mmcJens Wiklander
Adds support in optee supplicant to route signed (MACed) RPMB frames from OP-TEE Secure OS to MMC and vice versa to manipulate the RPMB partition. Tested-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-07tee: add OP-TEE driverJens Wiklander
Adds a OP-TEE driver. * Targets ARM and ARM64 * Supports using any U-Boot memory as shared memory * Probes OP-TEE version using SMCs * Uses OPTEE message protocol version 2 to communicate with secure world Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Igor Opaniuk <igor.opaniuk@linaro.org> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
2018-10-07Add UCLASS_TEE for Trusted Execution EnvironmentJens Wiklander
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>