- OP-TEE - lists.trustedfirmware.org

Re: Linaro OP-TEE Contributions meeting Aug 2020

by Achin Gupta

Hi Peng, > On 3 Sep 2020, at 10:34, Jens Wiklander via OP-TEE <op-tee(a)lists.trustedfirmware.org> wrote: > > Hi Peng, > > On Fri, Aug 28, 2020 at 9:10 AM Peng Fan via OP-TEE > <op-tee(a)lists.trustedfirmware.org> wrote: >> >> I was not able to join the meeting. Just wonder for S-EL2, is there any platform supporting it? How to test? Just to be sure, you mean support for running OP-TEE under a Hypervisor/SPM in S-EL2? Cheers, Achin > > This is tested and developed using FVP as far as I know. > > Cheers, > Jens > >> >> Thanks, >> Peng. >> >> From: Joakim Bech [mailto:joakim.bech@linaro.org] >> Sent: 2020年8月27日 16:21 >> To: op-tee(a)lists.trustedfirmware.org >> Subject: Re: Linaro OP-TEE Contributions meeting Aug 2020 >> >> Hi, >> >> Just a friendly reminder, that we have the first public "Linaro OP-TEE Contributions" meeting taking place later today. >> 2020-08-27(a)16.00<mailto:2020-08-27@16.00> UTC+2, 1h duration (for other timezones, use this URL https://everytimezone.com/s/12a83ab5<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feverytime…>). Connection details and etc can be found in the email below. >> >> This time I've also included more people on BCC who might not have subscribed to the <op-tee(a)lists.trustedfirmware.org<mailto:op-tee@lists.trustedfirmware.org>> list. >> >> Regards, >> Joakim >> >> On Wed, 19 Aug 2020 at 15:52, Joakim Bech via OP-TEE <op-tee(a)lists.trustedfirmware.org<mailto:op-tee@lists.trustedfirmware.org>> wrote: >> 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<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…>) 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<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Feverytimez…> 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<mailto:27th@16.00> (UTC+2) >> https://everytimezone.com/s/12a83ab5<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feverytime…> >> Invitation/connection details: In the meeting notes >> Meeting notes: >> https://docs.google.com/document/d/15XsqgGktCrRRWiqyaz-erp_cZykwGjkBkhMD2Xt…<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.goog…> >> >> Regards, >> Joakim on behalf of the Linaro OP-TEE team >> -- >> OP-TEE mailing list >> OP-TEE(a)lists.trustedfirmware.org<mailto:OP-TEE@lists.trustedfirmware.org> >> https://lists.trustedfirmware.org/mailman/listinfo/op-tee<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…>

4 years, 1 month

2
4
0 0

Re: Linaro OP-TEE Contributions meeting Aug 2020

by Jens Wiklander

Hi Peng, On Fri, Aug 28, 2020 at 9:10 AM Peng Fan via OP-TEE <op-tee(a)lists.trustedfirmware.org> wrote: > > I was not able to join the meeting. Just wonder for S-EL2, is there any platform supporting it? How to test? This is tested and developed using FVP as far as I know. Cheers, Jens > > Thanks, > Peng. > > From: Joakim Bech [mailto:joakim.bech@linaro.org] > Sent: 2020年8月27日 16:21 > To: op-tee(a)lists.trustedfirmware.org > Subject: Re: Linaro OP-TEE Contributions meeting Aug 2020 > > Hi, > > Just a friendly reminder, that we have the first public "Linaro OP-TEE Contributions" meeting taking place later today. > 2020-08-27(a)16.00<mailto:2020-08-27@16.00> UTC+2, 1h duration (for other timezones, use this URL https://everytimezone.com/s/12a83ab5<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feverytime…>). Connection details and etc can be found in the email below. > > This time I've also included more people on BCC who might not have subscribed to the <op-tee(a)lists.trustedfirmware.org<mailto:op-tee@lists.trustedfirmware.org>> list. > > Regards, > Joakim > > On Wed, 19 Aug 2020 at 15:52, Joakim Bech via OP-TEE <op-tee(a)lists.trustedfirmware.org<mailto:op-tee@lists.trustedfirmware.org>> wrote: > 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<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…>) 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<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Feverytimez…> 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<mailto:27th@16.00> (UTC+2) > https://everytimezone.com/s/12a83ab5<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feverytime…> > Invitation/connection details: In the meeting notes > Meeting notes: > https://docs.google.com/document/d/15XsqgGktCrRRWiqyaz-erp_cZykwGjkBkhMD2Xt…<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.goog…> > > Regards, > Joakim on behalf of the Linaro OP-TEE team > -- > OP-TEE mailing list > OP-TEE(a)lists.trustedfirmware.org<mailto:OP-TEE@lists.trustedfirmware.org> > https://lists.trustedfirmware.org/mailman/listinfo/op-tee<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…>

4 years, 1 month

1
0
0 0

[GIT PULL] optee i2c fix for v5.10

by Jens Wiklander

Hello arm-soc maintainers, Please pull this small patch fixing a build issue in the previous OP-TEE I2C patch. The test IS_REACHABLE(CONFIG_I2C) is used instead of IS_ENABLED(CONFIG_I2C) to see if the I2C functions are available from the OP-TEE driver. If you rather have the patches squashed feel free to do so. Thanks, Jens The following changes since commit c05210ab975771e161427eb47696b869d820bdaf: drivers: optee: allow op-tee to access devices on the i2c bus (2020-08-21 11:41:45 +0200) are available in the Git repository at: git://git.linaro.org:/people/jens.wiklander/linux-tee.git tags/optee-i2c-fix-for-v5.10 for you to fetch changes up to 539f8fc253ece5501fdea1a6aa227d0618374111: drivers: optee: fix i2c build issue (2020-09-01 12:03:16 +0200) ---------------------------------------------------------------- Make sure I2C functions used in OP-TEE are reachable with IS_REACHABLE() ---------------------------------------------------------------- Jorge Ramirez-Ortiz (1): drivers: optee: fix i2c build issue drivers/tee/optee/rpc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

4 years, 1 month

1
0
0 0

Re: Linaro OP-TEE Contributions meeting Aug 2020

by Joakim Bech

Hi, Just a friendly reminder, that we have the first public "Linaro OP-TEE Contributions" meeting taking place later today. 2020-08-27(a)16.00 UTC+2, 1h duration (for other timezones, use this URL https://everytimezone.com/s/12a83ab5). Connection details and etc can be found in the email below. This time I've also included more people on BCC who might not have subscribed to the <op-tee(a)lists.trustedfirmware.org> list. Regards, Joakim On Wed, 19 Aug 2020 at 15:52, Joakim Bech via OP-TEE < op-tee(a)lists.trustedfirmware.org> wrote: > 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 > -- > OP-TEE mailing list > OP-TEE(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/op-tee >

4 years, 1 month

2
1
0 0

[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(-)

4 years, 2 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

4 years, 2 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(-)

4 years, 2 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

4 years, 2 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(+)

4 years, 2 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

4 years, 2 months

2
2
0 0

2024

2023

2022

2021

2020

OP-TEE