July 2020 - OP-TEE - lists.trustedfirmware.org

[PATCH] driver: tee: Handle NULL pointer indication from client

by Jens Wiklander

From: Cedric Neveux <cedric.neveux(a)nxp.com> TEE Client introduce a new capability "TEE_GEN_CAP_MEMREF_NULL" to handle the support of the shared memory buffer with a NULL pointer. This capability depends on TEE Capabilities and driver support. Driver and TEE exchange capabilities at driver initialization. Signed-off-by: Michael Whitfield <michael.whitfield(a)nxp.com> Signed-off-by: Cedric Neveux <cedric.neveux(a)nxp.com> Reviewed-by: Joakim Bech <joakim.bech(a)linaro.org> Tested-by: Joakim Bech <joakim.bech(a)linaro.org> (QEMU) Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org> --- drivers/tee/optee/core.c | 7 +++++ drivers/tee/optee/optee_smc.h | 3 +++ drivers/tee/tee_core.c | 49 ++++++++++++++++++++++------------- include/linux/tee_drv.h | 3 +++ include/uapi/linux/tee.h | 13 ++++++++++ 5 files changed, 57 insertions(+), 18 deletions(-) diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index 99698b8a3a74..8ef66e75b65e 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -215,6 +215,8 @@ static void optee_get_version(struct tee_device *teedev, if (optee->sec_caps & OPTEE_SMC_SEC_CAP_DYNAMIC_SHM) v.gen_caps |= TEE_GEN_CAP_REG_MEM; + if (optee->sec_caps & OPTEE_SMC_SEC_CAP_MEMREF_NULL) + v.gen_caps |= TEE_GEN_CAP_MEMREF_NULL; *vers = v; } @@ -246,6 +248,11 @@ static int optee_open(struct tee_context *ctx) mutex_init(&ctxdata->mutex); INIT_LIST_HEAD(&ctxdata->sess_list); + if (optee->sec_caps & OPTEE_SMC_SEC_CAP_MEMREF_NULL) + ctx->cap_memref_null = true; + else + ctx->cap_memref_null = false; + ctx->data = ctxdata; return 0; } diff --git a/drivers/tee/optee/optee_smc.h b/drivers/tee/optee/optee_smc.h index c72122d9c997..777ad54d4c2c 100644 --- a/drivers/tee/optee/optee_smc.h +++ b/drivers/tee/optee/optee_smc.h @@ -215,6 +215,9 @@ struct optee_smc_get_shm_config_result { */ #define OPTEE_SMC_SEC_CAP_DYNAMIC_SHM BIT(2) +/* Secure world supports Shared Memory with a NULL buffer reference */ +#define OPTEE_SMC_SEC_CAP_MEMREF_NULL BIT(4) + #define OPTEE_SMC_FUNCID_EXCHANGE_CAPABILITIES 9 #define OPTEE_SMC_EXCHANGE_CAPABILITIES \ OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_EXCHANGE_CAPABILITIES) diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index 64637e09a095..ce0f0309b6ac 100644 --- a/drivers/tee/tee_core.c +++ b/drivers/tee/tee_core.c @@ -383,25 +383,38 @@ static int params_from_user(struct tee_context *ctx, struct tee_param *params, case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT: case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT: /* - * If we fail to get a pointer to a shared memory - * object (and increase the ref count) from an - * identifier we return an error. All pointers that - * has been added in params have an increased ref - * count. It's the callers responibility to do - * tee_shm_put() on all resolved pointers. + * If a NULL pointer is passed to a TA in the TEE, + * the ip.c IOCTL parameters is set to TEE_MEMREF_NULL + * indicating a NULL memory reference. */ - shm = tee_shm_get_from_id(ctx, ip.c); - if (IS_ERR(shm)) - return PTR_ERR(shm); - - /* - * Ensure offset + size does not overflow offset - * and does not overflow the size of the referred - * shared memory object. - */ - if ((ip.a + ip.b) < ip.a || - (ip.a + ip.b) > shm->size) { - tee_shm_put(shm); + if (ip.c != TEE_MEMREF_NULL) { + /* + * If we fail to get a pointer to a shared + * memory object (and increase the ref count) + * from an identifier we return an error. All + * pointers that has been added in params have + * an increased ref count. It's the callers + * responibility to do tee_shm_put() on all + * resolved pointers. + */ + shm = tee_shm_get_from_id(ctx, ip.c); + if (IS_ERR(shm)) + return PTR_ERR(shm); + + /* + * Ensure offset + size does not overflow + * offset and does not overflow the size of + * the referred shared memory object. + */ + if ((ip.a + ip.b) < ip.a || + (ip.a + ip.b) > shm->size) { + tee_shm_put(shm); + return -EINVAL; + } + } else if (ctx->cap_memref_null) { + /* Pass NULL pointer to OP-TEE */ + shm = NULL; + } else { return -EINVAL; } diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h index d074302989dd..cdd049a724b1 100644 --- a/include/linux/tee_drv.h +++ b/include/linux/tee_drv.h @@ -47,6 +47,8 @@ struct tee_shm_pool; * and just return with an error code. It is needed for requests * that arises from TEE based kernel drivers that should be * non-blocking in nature. + * @cap_memref_null: flag indicating if the TEE Client support shared + * memory buffer with a NULL pointer. */ struct tee_context { struct tee_device *teedev; @@ -54,6 +56,7 @@ struct tee_context { struct kref refcount; bool releasing; bool supp_nowait; + bool cap_memref_null; }; struct tee_param_memref { diff --git a/include/uapi/linux/tee.h b/include/uapi/linux/tee.h index b619f37ee03e..d67cadf221fc 100644 --- a/include/uapi/linux/tee.h +++ b/include/uapi/linux/tee.h @@ -51,6 +51,9 @@ #define TEE_GEN_CAP_GP (1 << 0)/* GlobalPlatform compliant TEE */ #define TEE_GEN_CAP_PRIVILEGED (1 << 1)/* Privileged device (for supplicant) */ #define TEE_GEN_CAP_REG_MEM (1 << 2)/* Supports registering shared memory */ +#define TEE_GEN_CAP_MEMREF_NULL (1 << 3)/* NULL MemRef support */ + +#define TEE_MEMREF_NULL (__u64)(-1) /* NULL MemRef Buffer */ /* * TEE Implementation ID @@ -200,6 +203,16 @@ struct tee_ioctl_buf_data { * a part of a shared memory by specifying an offset (@a) and size (@b) of * the object. To supply the entire shared memory object set the offset * (@a) to 0 and size (@b) to the previously returned size of the object. + * + * A client may need to present a NULL pointer in the argument + * passed to a trusted application in the TEE. + * This is also a requirement in GlobalPlatform Client API v1.0c + * (section 3.2.5 memory references), which can be found at + * http://www.globalplatform.org/specificationsdevice.asp + * + * If a NULL pointer is passed to a TA in the TEE, the (@c) + * IOCTL parameters value must be set to TEE_MEMREF_NULL indicating a NULL + * memory reference. */ struct tee_ioctl_param { __u64 attr; -- 2.25.1

4 years, 1 month

1
1
0 0

Preparing for OP-TEE 3.10.0

by Jerome Forissier

[BCC all OP-TEE maintainers] Hi OP-TEE maintainers & contributors, It is time again to prepare for a new OP-TEE release (3.10.0). Target is Friday, August 21st which leaves us 3 weeks to finalize the release. Please start testing your favorite platform(s) and report any issue in this pull request [1]. I will create a release candidate tag one week before the release date, at which point we will do some more testing and I will collect Tested-by tags in the same pull request. [1] https://github.com/OP-TEE/optee_os/pull/4008 Thanks! Regards, -- Jerome

4 years, 1 month

2
1
0 0

[PATCHv2 1/2] hwrng: optee: handle unlimited data rates

by Jorge Ramirez-Ortiz

Data rates of MAX_UINT32 will schedule an unnecessary one jiffy timeout on the call to msleep. Avoid this scenario by using 0 as the unlimited data rate. Signed-off-by: Jorge Ramirez-Ortiz <jorge(a)foundries.io> --- drivers/char/hw_random/optee-rng.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/char/hw_random/optee-rng.c b/drivers/char/hw_random/optee-rng.c index 49b2e02537dd..5bc4700c4dae 100644 --- a/drivers/char/hw_random/optee-rng.c +++ b/drivers/char/hw_random/optee-rng.c @@ -128,7 +128,7 @@ static int optee_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait) data += rng_size; read += rng_size; - if (wait) { + if (wait && pvt_data->data_rate) { if (timeout-- == 0) return read; msleep((1000 * (max - read)) / pvt_data->data_rate); -- 2.17.1

4 years, 1 month

3
13
0 0

PSA OP-TEE development

by Miklos Balint

Hi, In parallel with - and based on - the work by Jens to enable PSA FF-A as a transport for the SMC ABI (recently merged to the upstream as PR #3908) there's an effort to provide a fully-functional SPMC component in OP-TEE to manage S-EL0 Secure Partitions, with the goal of providing a similar set of PSA Root of Trust services over OP-TEE as presently supported for M-profile processors, while also providing a standard execution framework and ABI for potential integration of 3rd party partitions, such as StMM. Please note that this work is currently at the prototyping stage and is managed as a fork on trustedfirmware.org, but is planned to be merged with the official OP-TEE stream as it matures. There's an initial set of patches on review to provide * A library for S-EL0 SPs to access FF-A ABI at the SVC call interface: https://review.trustedfirmware.org/c/OP-TEE/optee_os/+/4751 * A change to introduce an SP build system to OP-TEE: https://review.trustedfirmware.org/c/OP-TEE/optee_os/+/4752 * OP-TEE kernel changes to support initialization and context management of SPs and the forwarding of FF-A messages to their designated endpoints: https://review.trustedfirmware.org/c/OP-TEE/optee_os/+/4987 All related open reviews at the moment can be found here: https://review.trustedfirmware.org/q/project:OP-TEE%252Foptee_os+status:open For the S-EL1 SPMC configuration functionality and requirements see the PSA FF-A specification (https://developer.arm.com/documentation/den0077/latest) Work is in progress to showcase the capabilities of the framework using a subset of PSA Crypto API and also to propose a standardized protocol layer for partitions, but as mentioned work is still at the early stages so expect gradual increments in functionality and flexibility. Any questions and feedback are very welcome Cheers, Miklos IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

4 years, 2 months

1
0
0 0

Re: OP-TEE release dates?

by Joakim Bech

Hi Jerome, On Fri, Jul 24, 2020 at 02:57:34PM +0000, Jérôme Forissier via OP-TEE wrote: > Hi, > > Anyone know if the planned dates of OP-TEE releases are publicly available > somewhere? > Still a bit legacy regarding that, i.e., still tracked in the Linaro Jira instance. Even though the "Linaro OP-TEE Contributions" is publicly available, the release schedule seems to be locked down. > Readthedocs [1] documents that we do quarterly releases, but it would help > to have a more precise indication, at least for the next (upcoming) release. > Agree, I can replicate what we have in the Jira instance and put that on the release page you're referring to. > Can we count on 3.10.0 being made available by the end of August? > Yes, so it's about time to initiate the release work for that tag. As maintainers, let's sync up on that separately. Here are the dates for future releases. Version Start date Release date OP-TEE 3.10.0 23/May/20 21/Aug/20 OP-TEE 3.11.0 22/Aug/20 16/Oct/20 OP-TEE 3.12.0 17/Oct/20 15/Jan/21 OP-TEE 3.13.0 16/Jan/21 16/Apr/21 > [1] https://optee.readthedocs.io/en/latest/general/releases.html > > Thanks, > -- > Jerome > -- > OP-TEE mailing list > OP-TEE(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/op-tee -- Regards, Joakim

4 years, 2 months

2
2
0 0

OP-TEE release dates?

by Jérôme Forissier

Hi, Anyone know if the planned dates of OP-TEE releases are publicly available somewhere? Readthedocs [1] documents that we do quarterly releases, but it would help to have a more precise indication, at least for the next (upcoming) release. Can we count on 3.10.0 being made available by the end of August? [1] https://optee.readthedocs.io/en/latest/general/releases.html Thanks, -- Jerome

4 years, 2 months

1
0
0 0

Re: [PATCH] docs: staging/tee.rst: convert into definition list

by Jonathan Corbet

On Sat, 18 Jul 2020 13:50:58 -0300 "Daniel W. S. Almeida" <dwlsalmeida(a)gmail.com> wrote: > TEE bus infrastructure registers following APIs: > -- match(): iterates over the client driver UUID table to find a corresponding > - match for device UUID. If a match is found, then this particular device is > - probed via corresponding probe API registered by the client driver. This > - process happens whenever a device or a client driver is registered with TEE > - bus. > -- uevent(): notifies user-space (udev) whenever a new device is registered on > - TEE bus for auto-loading of modularized client drivers. > + > +match(): > + iterates over the client driver UUID table to find a corresponding > + match for device UUID. If a match is found, then this particular device is > + probed via corresponding probe API registered by the client driver. This > + process happens whenever a device or a client driver is registered with TEE > + bus. > + > +uevent(): > + notifies user-space (udev) whenever a new device is registered on > + TEE bus for auto-loading of modularized client drivers. Just FWIW, this could have been fixed by adding a blank line between the two bulleted entries. This fix is fine too, though, applied, thanks. jon

4 years, 2 months

1
0
0 0

[PATCH 1/2] hwrng: optee: handle unlimited data rates

by Jorge Ramirez-Ortiz

Data rates of MAX_UINT32 will schedule an unnecessary one jiffy timeout on the call to msleep. Avoid this scenario by using 0 as the unlimited data rate. Signed-off-by: Jorge Ramirez-Ortiz <jorge(a)foundries.io> --- drivers/char/hw_random/optee-rng.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/char/hw_random/optee-rng.c b/drivers/char/hw_random/optee-rng.c index 49b2e02537dd..5bc4700c4dae 100644 --- a/drivers/char/hw_random/optee-rng.c +++ b/drivers/char/hw_random/optee-rng.c @@ -128,7 +128,7 @@ static int optee_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait) data += rng_size; read += rng_size; - if (wait) { + if (wait && pvt_data->data_rate) { if (timeout-- == 0) return read; msleep((1000 * (max - read)) / pvt_data->data_rate); -- 2.17.1

4 years, 2 months

1
1
0 0

[GIT PULL] optee bus for v5.9

by Jens Wiklander

Hello arm-soc maintainers, Please pull these patches enabling multi-stage OP-TEE bus enumeration and also adds a TPM driver for a OP-TEE based fTPM Trusted Application. The TPM driver depends on and takes advantage of the multi-stage OP-TEE bus enumeration by indicating that it should be probed after tee-supplicant has been started. Jarkko, one of the TPM maintainers, has been involved in reviewing these patches and agrees that I can include the TPM patch in the pull request. Thanks, Jens The following changes since commit 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162: Linux 5.7 (2020-05-31 16:49:15 -0700) are available in the Git repository at: git://git.linaro.org/people/jens.wiklander/linux-tee.git tags/optee-bus-for-v5.9 for you to fetch changes up to 9f1944c23c8cb1c033b73de80cf6c612a2a80a2b: tpm_ftpm_tee: register driver on TEE bus (2020-07-10 09:41:58 +0200) ---------------------------------------------------------------- Enable multi-stage OP-TEE bus enumeration Probes drivers on the OP-TEE bus in two steps. First for drivers which do not depend on tee-supplicant. After tee-supplicant has been started probe the devices which do depend on tee-supplicant. Also introduces driver which uses an OP-TEE based fTPM Trusted Application depends on tee-supplicant NV RAM implementation based on RPMB secure storage. ---------------------------------------------------------------- Maxim Uvarov (3): optee: use uuid for sysfs driver entry optee: enable support for multi-stage bus enumeration tpm_ftpm_tee: register driver on TEE bus Documentation/ABI/testing/sysfs-bus-optee-devices | 8 +++ MAINTAINERS | 1 + drivers/char/tpm/tpm_ftpm_tee.c | 70 +++++++++++++++++++---- drivers/tee/optee/core.c | 27 ++++++++- drivers/tee/optee/device.c | 38 ++++++------ drivers/tee/optee/optee_private.h | 10 +++- 6 files changed, 119 insertions(+), 35 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-optee-devices

4 years, 2 months

2
1
0 0

Re: OP-TEE Development Guidance

by Jens Wiklander

Hi Saad, On Thu, Jun 18, 2020 at 9:43 AM Muhammad Saad via OP-TEE <op-tee(a)lists.trustedfirmware.org> wrote: > > Hello All, > > First, I hope you are safe and doing fine in the unfortunate COVID-19 situation. I am a Ph.D. student at the University of Central Florida. Currently, I am working on a TEE-based prototype application for a proof-of-concept. Since I am totally new in this domain, so it is taking some effort. I have a few questions and I hope you guys can help me in that. > > At present, I am able to set up OP-TEE on Qemu and run the examples on the normal world and the secure world. Additionally, I tweaked a few parameters (ie., the integer value in the main.c) for the CA and the addition and subtraction sequence in the TA. Upon building it again (cd/build/make all run), it seems to work. However, if I need to pass a normal string to the TA and the TA computes Sha256 of the string and returns the value, what steps do I need to take? In other words, how can I pass a tuple from the TA to the CA and obtain the Hash of the tuple. Additionally, if I am able to do that by tailoring the HelloWorld examples, how can I develop new CA and TA with unique UUID and perform the same procedure. Finally, instead of doing the entire (cd/build/make all run), is there a method by which I can simply build the application and alone and run it on Qemu? You can find an example of doing some hashing at https://github.com/OP-TEE/optee_test/blob/391168ec03980e1cc8fb6d3e3c4b42481… You'll need to look around a little to get the whole picture, but it shouldn't be too hard. If you only change a TA or some client application it's enough to rebuild with: make buildroot and then run it with: make run-only A new UUID can be obtained with the Linux command uuidgen. Cheers, Jens > > I understand that these must be trivial questions, however, I will deeply appreciate if you can help me in figuring them out. > > > Best, > > Saad > -- > OP-TEE mailing list > OP-TEE(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/op-tee

4 years, 2 months

2
2
0 0

2024

2023

2022

2021

2020

OP-TEE July 2020