Tee-dev

tee-dev@lists.linaro.org

293 discussions

[PATCH v3 00/11] TEE mediator (and OP-TEE) support in XEN

by Volodymyr Babchuk

From: Volodymyr Babchuk <vlad.babchuk(a)gmail.com> Hello all, Sorry for late submussion. I was busy with other projects. Global changes from v2: - Use domain flags insted of domctl interface to enable optee for guests - Remove patch "libxc: add xc_dom_tee_enable(...) function" because of previous change - Mediator now stores own context in arch part of struct domain, so I removed patch "optee: add domain contexts" Per-patch changes are described in corresponding emails. ==== v2: This is v2 of patch series for OP-TEE mediator support in XEN. Changes from v1: - Added domctl interface, so now xl decides what domain should work with TEE - Removed XSM support due to change described above - Patch with OP-TEE mediator was splited to 7 separate patches - Removed patch with call_smccc() function. Now this series depend on Julien Grall's series "xen/arm: SMCCC fixup and improvement" [3] ===== v1: This is follow for patch series [1]. There was lots of discussions for that series and I tried to address all of them in this new patchset. Currently, I had a working solution for OP-TEE virtualization and it is being upstreamed right now ([2]). So, I think it is a good time to introduce support in XEN as well. This series include generic TEE mediator framework and full-scale OP-TEE mediator which is working with mentioned chages in OP-TEE. So, multiple domains can work simultaneously with OP-TEE. I added XSM support, so now it is possible to control which domains can work with TEEs. Also I changed way how TEE discovery is done. Now it is very generic and should support any platform. [1] https://lists.xenproject.org/archives/html/xen-devel/2017-10/msg01451.html [2] https://github.com/OP-TEE/optee_os/pull/2370 [3] https://lists.xenproject.org/archives/html/xen-devel/2018-08/msg02138.html Volodymyr Babchuk (11): arm: add generic TEE mediator framework arm: add tee_enabled flag to xen_arch_domainconfig arm: tee: add OP-TEE header files optee: add OP-TEE mediator skeleton optee: add fast calls handling optee: add std call handling optee: add support for RPC SHM buffers optee: add support for arbitrary shared memory optee: add support for RPC commands xl: add "tee" option for xl.cfg libxl: arm: create optee firmware node in DT if tee=1 MAINTAINERS | 6 + docs/man/xl.cfg.pod.5.in | 10 + tools/libxl/libxl_arm.c | 31 + tools/libxl/libxl_create.c | 1 + tools/libxl/libxl_types.idl | 1 + tools/xl/xl_parse.c | 1 + xen/arch/arm/Kconfig | 9 + xen/arch/arm/Makefile | 1 + xen/arch/arm/domain.c | 8 + xen/arch/arm/domain_build.c | 4 + xen/arch/arm/domctl.c | 1 + xen/arch/arm/setup.c | 1 + xen/arch/arm/shutdown.c | 1 + xen/arch/arm/tee/Kconfig | 4 + xen/arch/arm/tee/Makefile | 2 + xen/arch/arm/tee/optee.c | 1054 +++++++++++++++++++++++++++ xen/arch/arm/tee/tee.c | 69 ++ xen/arch/arm/vsmc.c | 5 + xen/arch/arm/xen.lds.S | 7 + xen/include/asm-arm/domain.h | 3 + xen/include/asm-arm/tee/optee_msg.h | 444 +++++++++++ xen/include/asm-arm/tee/optee_smc.h | 507 +++++++++++++ xen/include/asm-arm/tee/tee.h | 91 +++ xen/include/public/arch-arm.h | 3 + 24 files changed, 2264 insertions(+) create mode 100644 xen/arch/arm/tee/Kconfig create mode 100644 xen/arch/arm/tee/Makefile create mode 100644 xen/arch/arm/tee/optee.c create mode 100644 xen/arch/arm/tee/tee.c create mode 100644 xen/include/asm-arm/tee/optee_msg.h create mode 100644 xen/include/asm-arm/tee/optee_smc.h create mode 100644 xen/include/asm-arm/tee/tee.h -- 2.20.0

7 years, 1 month

[PATCH v2 1/1] tee: add cancellation support to client interface

by Igor Opaniuk

Add support of cancellation request to the TEE kernel internal client interface. Can be used by software TPM drivers, that leverage TEE under the hood (for instance TPM2.0 mobile profile), for requesting cancellation of time-consuming operations (RSA key-pair generation etc.). Signed-off-by: Igor Opaniuk <igor.opaniuk(a)linaro.org> --- v2: - use tee_ioctl_cancel_arg to provide session and cancel_id - fix tee_client_cancel_req function description header drivers/tee/tee_core.c | 10 ++++++++++ include/linux/tee_drv.h | 12 ++++++++++++ 2 files changed, 22 insertions(+) diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index 7b2bb4c..1148175 100644 --- a/drivers/tee/tee_core.c +++ b/drivers/tee/tee_core.c @@ -1027,6 +1027,16 @@ int tee_client_invoke_func(struct tee_context *ctx, } EXPORT_SYMBOL_GPL(tee_client_invoke_func); +int tee_client_cancel_req(struct tee_context *ctx, + struct tee_ioctl_cancel_arg *arg) +{ + if (!ctx->teedev->desc->ops->cancel_req) + return -EINVAL; + return ctx->teedev->desc->ops->cancel_req(ctx, arg->cancel_id, + arg->session); +} +EXPORT_SYMBOL_GPL(tee_client_cancel_req); + static int __init tee_init(void) { int rc; diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h index 6cfe058..177016e 100644 --- a/include/linux/tee_drv.h +++ b/include/linux/tee_drv.h @@ -526,6 +526,18 @@ int tee_client_invoke_func(struct tee_context *ctx, struct tee_ioctl_invoke_arg *arg, struct tee_param *param); +/** + * tee_client_cancel_req() - Request cancellation of the previous open-session + * or invoke-command operations in a Trusted Application + * @ctx: TEE Context + * @arg: Cancellation arguments, see description of + * struct tee_ioctl_cancel_arg + * + * Returns < 0 on error else 0 if the cancellation was successfully requested. + */ +int tee_client_cancel_req(struct tee_context *ctx, + struct tee_ioctl_cancel_arg *arg); + static inline bool tee_param_is_memref(struct tee_param *param) { switch (param->attr & TEE_IOCTL_PARAM_ATTR_TYPE_MASK) { -- 2.7.4

7 years, 1 month

Re: [Tee-dev] [U-Boot] [RFC] efi_loader: EFI variables

by Sumit Garg

+ tee-dev ML On Tue, 12 Feb 2019 at 17:36, Alexander Graf <agraf(a)suse.de> wrote: > > On 02/12/2019 12:34 PM, Heinrich Schuchardt wrote: > > On 2/12/19 10:49 AM, Alexander Graf wrote: > >> On 02/03/2019 07:32 PM, Heinrich Schuchardt wrote: > >>> Hello Alex, hello Takahiro, > >>> > >>> this morning I met Daniel Thompson of Linaro. He thinks it would be > >>> quite valuable if U-Boot would at least offer read access to EFI > >>> variables at runtime. > >>> > >>> I think what it takes is only a RAM buffer that we put between our > >>> current storage backend (i.e. synchronization with U-Boot variables) > >>> and the API implementation. > >>> > >>> We will need such a buffer anyway for non-permanent variables once we > >>> have a SPI flash storage. > >> I think slowly we need to take a critical design decision: Do we want to > >> be in the business of managing runtime UEFI variables? > >> > >> I don't have a fully cohesive answer to that yet. My gut feeling tells > >> me, that runtime variables would be much better off if they lived in > >> TrustZone. That way we don't have to play relocation tricks, and devices > >> that give you persistency are owned by the secure world anyway, so there > >> is no weird intersection between OS and RTS. > >> > >> So maybe the path forward would be to implement variable services in ATF > >> (or OP-TEE rather I suppose) and just provide shim stubs to communicate > >> with them from runtime services? That would keep all the variable logic > >> platform agnostic, and we would not have to jump through weird hoops > >> with DM. > > U-Boot' major asset are the many boards supported by drivers. Does ATF > > or OP-TEE have drivers for SPI? > > > > Or is your idea that U-Boot would provide a module that is set up as a > > trusted driver or trusted app, cf. > > https://developer.arm.com/-/media/developer/Block%20Diagrams/Architecture-o… > > I think it's perfectly possible to build a special OP-TEE U-Boot target > that can then reuse its drivers, similar to Simon's idea. But we should > probably not try to target RTS with that, but only secure enclaves. > One of OP-TEE design goals [1] being: Small footprint - the TEE should remain small enough to reside in a reasonable amount of on-chip memory as found on Arm based systems. I think this was one of main reason to have tee-supplicant infrastructure in normal world to reuse drivers and keep small footprint of OP-TEE. So if we build a special OP-TEE u-boot target and link it with optee-os as part of secure enclave then I am not sure how it will align with above design goal. [1] https://optee.readthedocs.io/general/about.html -Sumit > > Alex > > _______________________________________________ > U-Boot mailing list > U-Boot(a)lists.denx.de > https://lists.denx.de/listinfo/u-boot

7 years, 1 month

[PATCH v6 0/4] Introduce TEE bus driver framework

by Sumit Garg

This series introduces a generic TEE bus driver concept for TEE based kernel drivers which would like to communicate with TEE based devices/ services. Patch #1 adds TEE bus concept where devices/services are identified via Universally Unique Identifier (UUID) and drivers register a table of device UUIDs which they can support. This concept also allows for device enumeration to be specific to corresponding TEE implementation like OP-TEE etc. Patch #2 adds supp_nowait flag for non-blocking requests arising via TEE internal client interface. Patch #3 adds TEE bus device enumeration support for OP-TEE. OP-TEE provides a pseudo TA to enumerate TAs which can act as devices/services for TEE bus. Patch #4 adds OP-TEE based hwrng driver which act as TEE bus driver. On ARM SoC's with TrustZone enabled, peripherals like entropy sources might not be accessible to normal world (linux in this case) and rather accessible to secure world (OP-TEE in this case) only. So this driver aims to provides a generic interface to OP-TEE based random number generator service. Example case is Developerbox based on Socionext's Synquacer SoC [1] which provides 7 thermal sensors accessible from secure world only which could be used as entropy sources (thermal/measurement noise). [1] https://www.96boards.org/product/developerbox/ Changes in v6: 1. Incorporate some nitpicks in patch #1 and #3. 2. Bundle all statics in a data structure in patch #4 and use dev_* instead of pr_*. 3. Add reviewed-by tags for patch #1, #2 and #3. Changes in v5: 1. Add support in module device table for TEE bus devices. 2. Correct license for optee-rng module. Changes in v4: 1. Use typedef instead of single member tee_client_device_id struct. 2. Incorporate TEE bus nitpicks. Changes in v3: 1. Fixed bus error path in Patch #1. 2. Reversed order of Patch #2 and #3. 3. Fixed miscellaneous syntax comments and memory leak. 4. Added comments in Patch #2 for supp_nowait flag. Changes in v2: Based on review comments, the scope of this series has increased as follows: 1. Added TEE bus driver framework. 2. Added OP-TEE based device enumeration. 3. Register optee-rng driver as TEE bus driver. 4. Removed DT dependency for optee-rng device UUID. 5. Added supp_nowait flag. Sumit Garg (4): tee: add bus driver framework for TEE based devices tee: add supp_nowait flag in tee_context struct tee: optee: add TEE bus device enumeration support hwrng: add OP-TEE based rng driver MAINTAINERS | 5 + drivers/char/hw_random/Kconfig | 15 ++ drivers/char/hw_random/Makefile | 1 + drivers/char/hw_random/optee-rng.c | 298 +++++++++++++++++++++++++++++++++++++ drivers/tee/optee/Makefile | 1 + drivers/tee/optee/core.c | 4 + drivers/tee/optee/device.c | 155 +++++++++++++++++++ drivers/tee/optee/optee_private.h | 3 + drivers/tee/optee/supp.c | 10 +- drivers/tee/tee_core.c | 67 ++++++++- include/linux/mod_devicetable.h | 9 ++ include/linux/tee_drv.h | 38 ++++- scripts/mod/devicetable-offsets.c | 3 + scripts/mod/file2alias.c | 19 +++ 14 files changed, 622 insertions(+), 6 deletions(-) create mode 100644 drivers/char/hw_random/optee-rng.c create mode 100644 drivers/tee/optee/device.c -- 2.7.4

7 years, 1 month

[PATCH 1/1] toolchain: update AArch32/AArch64 toolchain to 8-2-2019.01

by Joakim Bech

Tested with OP-TEE [1] using GCC 8.2 2019.01 for both AArch32 (QEMU Armv7-A, gcc-arm-8.2-2019.01-x86_64-arm-linux-gnueabihf [2]) and with AArch64 (QEMU Armv8-A, gcc-arm-8.2-2019.01-x86_64-aarch64-linux-gnu [2]) which has gotten TUI mode re-enabled [3]. [1] https://github.com/OP-TEE [2] https://developer.arm.com/open-source/gnu-toolchain/gnu-a/downloads [3] https://bugs.linaro.org/show_bug.cgi?id=4130 Signed-off-by: Joakim Bech <joakim.bech(a)linaro.org> --- package/linux-headers/Config.in.host | 4 ++++ toolchain/Config.in | 5 +++++ .../toolchain-external-arm-aarch64/Config.in | 4 ++-- .../toolchain-external/toolchain-external-arm-arm/Config.in | 4 ++-- .../toolchain-external-custom/Config.in.options | 4 ++++ 5 files changed, 17 insertions(+), 4 deletions(-) diff --git a/package/linux-headers/Config.in.host b/package/linux-headers/Config.in.host index a6055e75b9..fd0cef8b21 100644 --- a/package/linux-headers/Config.in.host +++ b/package/linux-headers/Config.in.host @@ -51,6 +51,10 @@ config BR2_KERNEL_HEADERS_4_20 bool "Linux 4.20.x kernel headers" select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_20 +config BR2_KERNEL_HEADERS_5_00 + bool "Linux 5.00.x kernel headers" + select BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_00 + config BR2_KERNEL_HEADERS_VERSION bool "Manually specified Linux version" help diff --git a/toolchain/Config.in b/toolchain/Config.in index baf192c936..fd197f2407 100644 --- a/toolchain/Config.in +++ b/toolchain/Config.in @@ -374,10 +374,15 @@ config BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_20 bool select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_19 +config BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_00 + bool + select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_20 + # This order guarantees that the highest version is set, as kconfig # stops affecting a value on the first matching default. config BR2_TOOLCHAIN_HEADERS_AT_LEAST string + default "5.00" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_00 default "4.20" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_20 default "4.19" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_19 default "4.18" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_18 diff --git a/toolchain/toolchain-external/toolchain-external-arm-aarch64/Config.in b/toolchain/toolchain-external/toolchain-external-arm-aarch64/Config.in index fbb5e025e8..279cb88f31 100644 --- a/toolchain/toolchain-external/toolchain-external-arm-aarch64/Config.in +++ b/toolchain/toolchain-external/toolchain-external-arm-aarch64/Config.in @@ -1,5 +1,5 @@ config BR2_TOOLCHAIN_EXTERNAL_ARM_AARCH64 - bool "Arm AArch64 2018.11" + bool "Arm AArch64 2019.01" depends on BR2_aarch64 depends on BR2_HOSTARCH = "x86_64" depends on !BR2_STATIC_LIBS @@ -7,7 +7,7 @@ config BR2_TOOLCHAIN_EXTERNAL_ARM_AARCH64 select BR2_TOOLCHAIN_HAS_SSP select BR2_INSTALL_LIBSTDCPP select BR2_TOOLCHAIN_HAS_NATIVE_RPC - select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_20 + select BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_00 select BR2_TOOLCHAIN_GCC_AT_LEAST_8 select BR2_TOOLCHAIN_HAS_FORTRAN help diff --git a/toolchain/toolchain-external/toolchain-external-arm-arm/Config.in b/toolchain/toolchain-external/toolchain-external-arm-arm/Config.in index 0449737889..69c2f7425e 100644 --- a/toolchain/toolchain-external/toolchain-external-arm-arm/Config.in +++ b/toolchain/toolchain-external/toolchain-external-arm-arm/Config.in @@ -4,7 +4,7 @@ comment "Arm toolchains available for Cortex-A + EABIhf" depends on !BR2_STATIC_LIBS config BR2_TOOLCHAIN_EXTERNAL_ARM_ARM - bool "Arm ARM 2018.11" + bool "Arm ARM 2019.01" depends on BR2_arm depends on BR2_ARM_CPU_ARMV7A || BR2_ARM_CPU_ARMV8A depends on BR2_HOSTARCH = "x86_64" @@ -14,7 +14,7 @@ config BR2_TOOLCHAIN_EXTERNAL_ARM_ARM select BR2_TOOLCHAIN_HAS_SSP select BR2_TOOLCHAIN_HAS_NATIVE_RPC select BR2_INSTALL_LIBSTDCPP - select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_20 + select BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_00 select BR2_TOOLCHAIN_GCC_AT_LEAST_8 select BR2_TOOLCHAIN_HAS_FORTRAN help diff --git a/toolchain/toolchain-external/toolchain-external-custom/Config.in.options b/toolchain/toolchain-external/toolchain-external-custom/Config.in.options index 08a79ee4d9..48eb1ea080 100644 --- a/toolchain/toolchain-external/toolchain-external-custom/Config.in.options +++ b/toolchain/toolchain-external/toolchain-external-custom/Config.in.options @@ -123,6 +123,10 @@ choice m = ( LINUX_VERSION_CODE >> 8 ) & 0xFF p = ( LINUX_VERSION_CODE >> 0 ) & 0xFF +config BR2_TOOLCHAIN_EXTERNAL_HEADERS_5_00 + bool "5.00.x" + select BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_00 + config BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_20 bool "4.20.x" select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_20 -- 2.17.1

7 years, 1 month

FOSDEM

by Rouven Czerwinski

Hello, are any of the users or core developers which use OP-TEE coming to FOSDEM? Maybe we can organize a meetup. Regards, Rouven Czerwinski

7 years, 1 month

[PATCH v5 0/4] Introduce TEE bus driver framework

by Sumit Garg

This series introduces a generic TEE bus driver concept for TEE based kernel drivers which would like to communicate with TEE based devices/ services. Patch #1 adds TEE bus concept where devices/services are identified via Universally Unique Identifier (UUID) and drivers register a table of device UUIDs which they can support. This concept also allows for device enumeration to be specific to corresponding TEE implementation like OP-TEE etc. Patch #2 adds supp_nowait flag for non-blocking requests arising via TEE internal client interface. Patch #3 adds TEE bus device enumeration support for OP-TEE. OP-TEE provides a pseudo TA to enumerate TAs which can act as devices/services for TEE bus. Patch #4 adds OP-TEE based hwrng driver which act as TEE bus driver. On ARM SoC's with TrustZone enabled, peripherals like entropy sources might not be accessible to normal world (linux in this case) and rather accessible to secure world (OP-TEE in this case) only. So this driver aims to provides a generic interface to OP-TEE based random number generator service. Example case is Developerbox based on Socionext's Synquacer SoC [1] which provides 7 thermal sensors accessible from secure world only which could be used as entropy sources (thermal/measurement noise). [1] https://www.96boards.org/product/developerbox/ Changes in v5: 1. Add support in module device table for TEE bus devices. 2. Correct license for optee-rng module. Changes in v4: 1. Use typedef instead of single member tee_client_device_id struct. 2. Incorporate TEE bus nitpicks. Changes in v3: 1. Fixed bus error path in Patch #1. 2. Reversed order of Patch #2 and #3. 3. Fixed miscellaneous syntax comments and memory leak. 4. Added comments in Patch #2 for supp_nowait flag. Changes in v2: Based on review comments, the scope of this series has increased as follows: 1. Added TEE bus driver framework. 2. Added OP-TEE based device enumeration. 3. Register optee-rng driver as TEE bus driver. 4. Removed DT dependency for optee-rng device UUID. 5. Added supp_nowait flag. Sumit Garg (4): tee: add bus driver framework for TEE based devices tee: add supp_nowait flag in tee_context struct tee: optee: add TEE bus device enumeration support hwrng: add OP-TEE based rng driver MAINTAINERS | 5 + drivers/char/hw_random/Kconfig | 15 ++ drivers/char/hw_random/Makefile | 1 + drivers/char/hw_random/optee-rng.c | 274 +++++++++++++++++++++++++++++++++++++ drivers/tee/optee/Makefile | 1 + drivers/tee/optee/core.c | 4 + drivers/tee/optee/device.c | 153 +++++++++++++++++++++ drivers/tee/optee/optee_private.h | 3 + drivers/tee/optee/supp.c | 10 +- drivers/tee/tee_core.c | 70 +++++++++- include/linux/mod_devicetable.h | 9 ++ include/linux/tee_drv.h | 38 ++++- scripts/mod/devicetable-offsets.c | 3 + scripts/mod/file2alias.c | 19 +++ 14 files changed, 599 insertions(+), 6 deletions(-) create mode 100644 drivers/char/hw_random/optee-rng.c create mode 100644 drivers/tee/optee/device.c -- 2.7.4

7 years, 1 month

OP-TEE 3.4.0 has been released

by Jerome Forissier

Hi all, OP-TEE 3.4.0 is now ready. Thanks to all of you who have contributed to this new version. Links to commits and pull requests incorporated in this release are in the change log [1]. As usual, I have tagged the relevant OP-TEE/* and linaro-swg/* Gits [2] and I have created stable manifests in manifest.git (see branch 3.4.0, which is also tagged 3.4.0 [3]). So, it should be easy for anyone to retrieve and build this release. [1] https://github.com/OP-TEE/optee_os/blob/3.4.0/CHANGELOG.md [2] https://github.com/OP-TEE/optee_os/releases/tag/3.4.0 https://github.com/OP-TEE/optee_client/releases/tag/3.4.0 https://github.com/OP-TEE/optee_test/releases/tag/3.4.0 https://github.com/OP-TEE/build/releases/tag/3.4.0 https://github.com/linaro-swg/optee_examples/releases/tag/3.4.0 https://github.com/linaro-swg/optee_benchmark/releases/tag/3.4.0 [3] https://github.com/OP-TEE/manifest/releases/tag/3.4.0 Thanks, -- Jerome

7 years, 2 months

[PATCH 1/1] tee: add cancellation support to client interface

by Igor Opaniuk

Add support of cancellation request to the TEE kernel internal client interface. Can be used by software TPM drivers, that leverage TEE under the hood (for instance in TPM2.0 mobile profile), for requesting cancellation of time-consuming operations (RSA key-pair generation etc.). Signed-off-by: Igor Opaniuk <igor.opaniuk(a)linaro.org> --- drivers/tee/tee_core.c | 12 ++++++++++++ include/linux/tee_drv.h | 14 ++++++++++++++ 2 files changed, 26 insertions(+) diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index 7b2bb4c..aba71a8 100644 --- a/drivers/tee/tee_core.c +++ b/drivers/tee/tee_core.c @@ -1027,6 +1027,18 @@ int tee_client_invoke_func(struct tee_context *ctx, } EXPORT_SYMBOL_GPL(tee_client_invoke_func); +int tee_client_cancel_req(struct tee_context *ctx, + u32 cancel_id, + u32 session) +{ + + if (!ctx->teedev->desc->ops->cancel_req) + return -EINVAL; + return ctx->teedev->desc->ops->cancel_req(ctx, cancel_id, + session); +} +EXPORT_SYMBOL_GPL(tee_client_cancel_req); + static int __init tee_init(void) { int rc; diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h index 6cfe058..62a0b56 100644 --- a/include/linux/tee_drv.h +++ b/include/linux/tee_drv.h @@ -526,6 +526,20 @@ int tee_client_invoke_func(struct tee_context *ctx, struct tee_ioctl_invoke_arg *arg, struct tee_param *param); +/** + * tee_client_cancel_req() - Request cancellation of the previous open-session + * or invoke-command operations in a Trusted Application + * @ctx: TEE Context + * @arg: Unique cancel request id + * @param: Session id + * + * Returns < 0 on error else see @arg->ret for result. + */ +int tee_client_cancel_req(struct tee_context *ctx, + u32 cancel_id, + u32 session); + + static inline bool tee_param_is_memref(struct tee_param *param) { switch (param->attr & TEE_IOCTL_PARAM_ATTR_TYPE_MASK) { -- 2.7.4

7 years, 2 months

[PATCH v4 0/4] Introduce TEE bus driver framework

by Sumit Garg

This series introduces a generic TEE bus driver concept for TEE based kernel drivers which would like to communicate with TEE based devices/ services. Patch #1 adds TEE bus concept where devices/services are identified via Universally Unique Identifier (UUID) and drivers register a table of device UUIDs which they can support. This concept also allows for device enumeration to be specific to corresponding TEE implementation like OP-TEE etc. Patch #2 adds supp_nowait flag for non-blocking requests arising via TEE internal client interface. Patch #3 adds TEE bus device enumeration support for OP-TEE. OP-TEE provides a pseudo TA to enumerate TAs which can act as devices/services for TEE bus. Patch #4 adds OP-TEE based hwrng driver which act as TEE bus driver. On ARM SoC's with TrustZone enabled, peripherals like entropy sources might not be accessible to normal world (linux in this case) and rather accessible to secure world (OP-TEE in this case) only. So this driver aims to provides a generic interface to OP-TEE based random number generator service. Example case is Developerbox based on Socionext's Synquacer SoC [1] which provides 7 thermal sensors accessible from secure world only which could be used as entropy sources (thermal/measurement noise). [1] https://www.96boards.org/product/developerbox/ Changes in v4: 1. Use typedef instead of single member tee_client_device_id struct. 2. Incorporate TEE bus nitpicks. Changes in v3: 1. Fixed bus error path in Patch #1. 2. Reversed order of Patch #2 and #3. 3. Fixed miscellaneous syntax comments and memory leak. 4. Added comments in Patch #2 for supp_nowait flag. Changes in v2: Based on review comments, the scope of this series has increased as follows: 1. Added TEE bus driver framework. 2. Added OP-TEE based device enumeration. 3. Register optee-rng driver as TEE bus driver. 4. Removed DT dependency for optee-rng device UUID. 5. Added supp_nowait flag. Sumit Garg (4): tee: add bus driver framework for TEE based devices tee: add supp_nowait flag in tee_context struct tee: optee: add TEE bus device enumeration support hwrng: add OP-TEE based rng driver MAINTAINERS | 5 + drivers/char/hw_random/Kconfig | 15 ++ drivers/char/hw_random/Makefile | 1 + drivers/char/hw_random/optee-rng.c | 272 +++++++++++++++++++++++++++++++++++++ drivers/tee/optee/Makefile | 1 + drivers/tee/optee/core.c | 4 + drivers/tee/optee/device.c | 153 +++++++++++++++++++++ drivers/tee/optee/optee_private.h | 3 + drivers/tee/optee/supp.c | 10 +- drivers/tee/tee_core.c | 58 +++++++- include/linux/tee_drv.h | 43 +++++- 11 files changed, 559 insertions(+), 6 deletions(-) create mode 100644 drivers/char/hw_random/optee-rng.c create mode 100644 drivers/tee/optee/device.c -- 2.7.4

7 years, 2 months

← Newer
1
...
14
15
16
17
18
19
20
...
30
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Tee-dev