- OP-TEE - lists.trustedfirmware.org

[GIT PULL] tee subsystem pin_user_pages for v5.10

by Jens Wiklander

Hello arm-soc maintainers, Please pull this small patch converting the tee subsystem to use pin_user_pages() instead of get_user_pages(). Thanks, Jens The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5: Linux 5.9-rc1 (2020-08-16 13:04:57 -0700) are available in the Git repository at: git://git.linaro.org/people/jens.wiklander/linux-tee.git tags/tee-pin-user-pages-for-5.10 for you to fetch changes up to 4300cd6374a5192a2c8122a4a48ed647bdcb0214: tee: convert get_user_pages() --> pin_user_pages() (2020-08-25 11:01:06 +0200) ---------------------------------------------------------------- Converts tee subsystem to use pin_user_pages() instead of get_user_pages() ---------------------------------------------------------------- John Hubbard (1): tee: convert get_user_pages() --> pin_user_pages() drivers/tee/tee_shm.c | 32 +++++++++++++++++++------------- 1 file changed, 19 insertions(+), 13 deletions(-)

3 years, 8 months

1
0
0 0

OP-TEE 3.10.0 has been released

by Jerome Forissier

[BCC all OP-TEE maintainers] Hi, FYI, I have just finalized the OP-TEE 3.10.0 release (changelog [1]). Many thanks to all of you who contributed to this release by submitting or reviewing code, or taking part in release testing [2]. [1] https://github.com/OP-TEE/optee_os/blob/3.10.0/CHANGELOG.md [2] https://github.com/OP-TEE/optee_os/commit/d1c635434c55 Regards, -- Jerome

3 years, 8 months

1
0
0 0

[GIT PULL] tee memref null for v5.10

by Jens Wiklander

Hello arm-soc maintainers, Please pull this patch enabling a TEE client to indicate a NULL pointer instead of a valid buffer when invoking a Trusted Application. Thanks, Jens The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5: Linux 5.9-rc1 (2020-08-16 13:04:57 -0700) are available in the Git repository at: git://git.linaro.org/people/jens.wiklander/linux-tee.git tags/tee-memref-null-for-v5.10 for you to fetch changes up to ba171d3f0850003216fd1a85190d17b1feddb961: driver: tee: Handle NULL pointer indication from client (2020-08-21 08:55:13 +0200) ---------------------------------------------------------------- Handle NULL pointer indication from tee client Adds support to indicate NULL pointers instead of a valid buffer when querying the needed size of a buffer. ---------------------------------------------------------------- Cedric Neveux (1): driver: tee: Handle NULL pointer indication from client 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(-)

3 years, 8 months

1
0
0 0

[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

3 years, 8 months

1
1
0 0

[GIT PULL] optee i2c for v5.10

by Jens Wiklander

Hello arm-soc maintainers, Please pull this patch enabling i2c access from secure world via a trampoline in the OP-TEE driver. Thanks, Jens The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5: Linux 5.9-rc1 (2020-08-16 13:04:57 -0700) are available in the Git repository at: git://git.linaro.org/people/jens.wiklander/linux-tee.git tags/optee-i2c-for-v5.10 for you to fetch changes up to c05210ab975771e161427eb47696b869d820bdaf: drivers: optee: allow op-tee to access devices on the i2c bus (2020-08-21 11:41:45 +0200) ---------------------------------------------------------------- Enable i2c device access from OP-TEE RPC Extends the OP-TEE RPC protocol to enable I2C device access. This allows a driver in secure world to access devices on a normal world I2C bus. ---------------------------------------------------------------- Jorge Ramirez-Ortiz (1): drivers: optee: allow op-tee to access devices on the i2c bus drivers/tee/optee/optee_msg.h | 21 +++++++++ drivers/tee/optee/optee_private.h | 1 + drivers/tee/optee/rpc.c | 95 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 117 insertions(+)

3 years, 8 months

1
0
0 0

[PATCHv3 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> Reviewed-by: Sumit Garg <sumit.garg(a)linaro.org> --- 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

3 years, 8 months

2
2
0 0

Linaro OP-TEE Contributions meeting Aug 2020

by Joakim Bech

Hi, As part of opening up Linaro projects to the general public we plan to have an open monthly meeting where we discuss Linaro's activities around OP-TEE. The way that we've planned to do this is that we send out an email to this email list (https://lists.trustedfirmware.org/mailman/listinfo/op-tee) to gather topics to discuss. If there are no topics, then there is no meeting. Anyone can suggest a topic by replying to this email thread. As a first topic for this first meeting, we want to talk a bit about: - Linaro and the relation to TrustedFirmware.org when it comes to OP-TEE. - Where to find information. - What is on the agenda for the next development cycle. Calendar invitation? I could just send one out here and now, but due to Zoom bombing and that it'd be a logistic exercise inviting people, I've decided to try another approach and that is to provide the connection details in the meeting notes and leave it up to the attendees to add it to their own calendars. To try to limit confusion I've explicitly added the timezone and a link to everytimezone.com so it should be easy to get the information in your own timezone. If this approach doesn't turn out to be good, then we will try something different in the future (I understand that canceling or shifting day/time will become a problem). Meeting details: --------------- Date/time: Thursday Aug 27th(a)16.00 (UTC+2) https://everytimezone.com/s/12a83ab5 Invitation/connection details: In the meeting notes Meeting notes: https://docs.google.com/document/d/15XsqgGktCrRRWiqyaz-erp_cZykwGjkBkhMD2Xt… Regards, Joakim on behalf of the Linaro OP-TEE team

3 years, 8 months

1
0
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

3 years, 9 months

2
1
0 0

[PATCHv3 2/2] hwrng: optee: fix wait use case

by Jorge Ramirez-Ortiz

The current code waits for data to be available before attempting a second read. However the second read would not be executed as the while loop will exit. This fix does not wait if all data has been read (skips the call to msleep(0)) and reads a second time if partial data was retrieved on the first read. Worth noticing that since msleep(0) schedules a one jiffy timeout is better to skip such a call. Signed-off-by: Jorge Ramirez-Ortiz <jorge(a)foundries.io> Reviewed-by: Sumit Garg <sumit.garg(a)linaro.org> --- drivers/char/hw_random/optee-rng.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/char/hw_random/optee-rng.c b/drivers/char/hw_random/optee-rng.c index 5bc4700c4dae..a99d82949981 100644 --- a/drivers/char/hw_random/optee-rng.c +++ b/drivers/char/hw_random/optee-rng.c @@ -122,14 +122,14 @@ static int optee_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait) if (max > MAX_ENTROPY_REQ_SZ) max = MAX_ENTROPY_REQ_SZ; - while (read == 0) { + while (read < max) { rng_size = get_optee_rng_data(pvt_data, data, (max - read)); data += rng_size; read += rng_size; if (wait && pvt_data->data_rate) { - if (timeout-- == 0) + if ((timeout-- == 0) || (read == max)) return read; msleep((1000 * (max - read)) / pvt_data->data_rate); } else { -- 2.17.1

3 years, 9 months

1
0
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

3 years, 9 months

3
13
0 0

2024

2023

2022

2021

2020

OP-TEE