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

[PATCH -next] tee: optee: fix type warning of sizeof in pool_op_alloc()

by Liu Shixin

sizeof() when applied to a pointer typed expression should gives the size of the pointed data, even if the data is a pointer. Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> --- drivers/tee/optee/shm_pool.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tee/optee/shm_pool.c b/drivers/tee/optee/shm_pool.c index d767eebf30bd..9fdc667b5df0 100644 --- a/drivers/tee/optee/shm_pool.c +++ b/drivers/tee/optee/shm_pool.c @@ -31,7 +31,7 @@ static int pool_op_alloc(struct tee_shm_pool_mgr *poolm, unsigned int nr_pages = 1 << order, i; struct page **pages; - pages = kcalloc(nr_pages, sizeof(pages), GFP_KERNEL); + pages = kcalloc(nr_pages, sizeof(*pages), GFP_KERNEL); if (!pages) return -ENOMEM; -- 2.25.1

4 years, 2 months

2
1
0 0

Re: [PATCH] drivers: optee: i2c: add bus retry configuration

by Jens Wiklander

On Wed, Sep 16, 2020 at 05:27:32PM +0200, Jorge Ramirez-Ortiz wrote: > Allow OP-TEE to specify the number of retries in the adaptor. > > Signed-off-by: Jorge Ramirez-Ortiz <jorge(a)foundries.io> > --- > drivers/tee/optee/rpc.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c > index 1e3614e4798f..2d46a9ecb1de 100644 > --- a/drivers/tee/optee/rpc.c > +++ b/drivers/tee/optee/rpc.c > @@ -58,6 +58,7 @@ static void handle_rpc_func_cmd_i2c_transfer(struct tee_context *ctx, > struct tee_param *params; > size_t i; > int ret = -EOPNOTSUPP; > + int retries = 0; > u8 attr[] = { > TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT, > TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT, > @@ -102,12 +103,17 @@ static void handle_rpc_func_cmd_i2c_transfer(struct tee_context *ctx, > client.addr = params[0].u.value.c; > snprintf(client.name, I2C_NAME_SIZE, "i2c%d", client.adapter->nr); > > + /* cache the current value */ > + retries = client.adapter->retries; > + > switch (params[0].u.value.a) { > case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD: > + client.adapter->retries = params[1].u.value.b; Do we need to take any locks befor this? Cheers, Jens > ret = i2c_master_recv(&client, params[2].u.memref.shm->kaddr, > params[2].u.memref.size); > break; > case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR: > + client.adapter->retries = params[1].u.value.b; > ret = i2c_master_send(&client, params[2].u.memref.shm->kaddr, > params[2].u.memref.size); > break; > @@ -126,6 +132,7 @@ static void handle_rpc_func_cmd_i2c_transfer(struct tee_context *ctx, > arg->ret = TEEC_SUCCESS; > } > > + client.adapter->retries = retries; > i2c_put_adapter(client.adapter); > kfree(params); > return; > -- > 2.17.1 >

4 years, 2 months

2
4
0 0

Re: OP-TEE development

by Joakim Bech

Hi Nikita, On Wed, Sep 23, 2020 at 11:24:23AM +0000, Nikita Snetkov via OP-TEE wrote: > Hello! > > Currently, I became interested in TEE research and development. After small > investigation, I found out your product: OP-TEE. After reading about it, > there is a thing that still bothers me: is it possible to create an > application which uses OP-TEE and distribute in via Google Play? > For OP-TEE you typically create a pair of binaries, one binary running on non-secure side (plain Linux environment) and one binary (Trusted Application) running on the secure side. Google Play hosts applications running in non-secure world, so I'd believe that distributing the non-secure side of your feature using Google Play is something you can do. But for the secure side, it's not that easy, since it's usually the OEM that decide what to install and is allowed to run on the secure side on their devices. > -- > Yours faithfully, > Nikita Snetkov -- Regards, Joakim

4 years, 2 months

1
0
0 0

OP-TEE development

by Nikita Snetkov

Hello! Currently, I became interested in TEE research and development. After small investigation, I found out your product: OP-TEE. After reading about it, there is a thing that still bothers me: is it possible to create an application which uses OP-TEE and distribute in via Google Play? -- Yours faithfully, Nikita Snetkov

4 years, 2 months

1
0
0 0

[GIT PULL] tee dev cleanup for v5.10

by Jens Wiklander

Hello arm-soc maintainers, Please pull this small cleanup in tee driver registration. There are no changes in behaviour, just a reduction in number of lines due to improved usage of the device driver framework. 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-dev-cleanup-for-v5.10 for you to fetch changes up to 8c05f50fe8452f9d3220efad77bef42c7b498193: tee: avoid explicit sysfs_create/delete_group by initialising dev->groups (2020-09-18 10:44:45 +0200) ---------------------------------------------------------------- Simplify tee_device_register() and friends Uses cdev_device_add() instead of the cdev_add() device_add() combination. Initializes dev->groups instead of direct calls to sysfs_create_group() and friends. ---------------------------------------------------------------- Sudeep Holla (2): tee: replace cdev_add + device_add with cdev_device_add tee: avoid explicit sysfs_create/delete_group by initialising dev->groups drivers/tee/tee_core.c | 40 +++++++--------------------------------- 1 file changed, 7 insertions(+), 33 deletions(-)

4 years, 2 months

1
0
0 0

[PATCH 1/2] tee: replace cdev_add + device_add with cdev_device_add

by Sudeep Holla

Commit 233ed09d7fda ("chardev: add helper function to register char devs with a struct device") added a helper function 'cdev_device_add'. Make use of cdev_device_add in tee_device_register to replace cdev_add and device_add. Since cdev_device_add takes care of setting the kobj->parent, drop explicit initialisation in tee_device_alloc. Signed-off-by: Sudeep Holla <sudeep.holla(a)arm.com> --- drivers/tee/tee_core.c | 21 ++++----------------- 1 file changed, 4 insertions(+), 17 deletions(-) diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index 64637e09a095..b4a8b362d78f 100644 --- a/drivers/tee/tee_core.c +++ b/drivers/tee/tee_core.c @@ -917,7 +917,6 @@ struct tee_device *tee_device_alloc(const struct tee_desc *teedesc, cdev_init(&teedev->cdev, &tee_fops); teedev->cdev.owner = teedesc->owner; - teedev->cdev.kobj.parent = &teedev->dev.kobj; dev_set_drvdata(&teedev->dev, driver_data); device_initialize(&teedev->dev); @@ -985,24 +984,15 @@ int tee_device_register(struct tee_device *teedev) return -EINVAL; } - rc = cdev_add(&teedev->cdev, teedev->dev.devt, 1); + rc = cdev_device_add(&teedev->cdev, &teedev->dev); if (rc) { dev_err(&teedev->dev, - "unable to cdev_add() %s, major %d, minor %d, err=%d\n", + "unable to cdev_device_add() %s, major %d, minor %d, err=%d\n", teedev->name, MAJOR(teedev->dev.devt), MINOR(teedev->dev.devt), rc); return rc; } - rc = device_add(&teedev->dev); - if (rc) { - dev_err(&teedev->dev, - "unable to device_add() %s, major %d, minor %d, err=%d\n", - teedev->name, MAJOR(teedev->dev.devt), - MINOR(teedev->dev.devt), rc); - goto err_device_add; - } - rc = sysfs_create_group(&teedev->dev.kobj, &tee_dev_group); if (rc) { dev_err(&teedev->dev, @@ -1014,9 +1004,7 @@ int tee_device_register(struct tee_device *teedev) return 0; err_sysfs_create_group: - device_del(&teedev->dev); -err_device_add: - cdev_del(&teedev->cdev); + cdev_device_del(&teedev->cdev, &teedev->dev); return rc; } EXPORT_SYMBOL_GPL(tee_device_register); @@ -1062,8 +1050,7 @@ void tee_device_unregister(struct tee_device *teedev) if (teedev->flags & TEE_DEVICE_FLAG_REGISTERED) { sysfs_remove_group(&teedev->dev.kobj, &tee_dev_group); - cdev_del(&teedev->cdev); - device_del(&teedev->dev); + cdev_device_del(&teedev->cdev, &teedev->dev); } tee_device_put(teedev); -- 2.17.1

4 years, 2 months

2
2
0 0

[PATCH v6 0/4] Introduce TEE based Trusted Keys support

by Sumit Garg

Add support for TEE based trusted keys where TEE provides the functionality to seal and unseal trusted keys using hardware unique key. Also, this is an alternative in case platform doesn't possess a TPM device. This patch-set has been tested with OP-TEE based early TA which is already merged in upstream [1]. [1] https://github.com/OP-TEE/optee_os/commit/f86ab8e7e0de869dfa25ca05a37ee070d… Changes in v6: 1. Revert back to dynamic detection of trust source. 2. Drop author mention from trusted_core.c and trusted_tpm1.c files. 3. Rebased to latest tpmdd/master. Changes in v5: 1. Drop dynamic detection of trust source and use compile time flags instead. 2. Rename trusted_common.c -> trusted_core.c. 3. Rename callback: cleanup() -> exit(). 4. Drop "tk" acronym. 5. Other misc. comments. 6. Added review tags for patch #3 and #4. Changes in v4: 1. Pushed independent TEE features separately: - Part of recent TEE PR: https://lkml.org/lkml/2020/5/4/1062 2. Updated trusted-encrypted doc with TEE as a new trust source. 3. Rebased onto latest tpmdd/master. Changes in v3: 1. Update patch #2 to support registration of multiple kernel pages. 2. Incoporate dependency patch #4 in this patch-set: https://patchwork.kernel.org/patch/11091435/ Changes in v2: 1. Add reviewed-by tags for patch #1 and #2. 2. Incorporate comments from Jens for patch #3. 3. Switch to use generic trusted keys framework. Sumit Garg (4): KEYS: trusted: Add generic trusted keys framework KEYS: trusted: Introduce TEE based Trusted Keys doc: trusted-encrypted: updates with TEE as a new trust source MAINTAINERS: Add entry for TEE based Trusted Keys Documentation/security/keys/trusted-encrypted.rst | 203 ++++++++++--- MAINTAINERS | 8 + include/keys/trusted-type.h | 42 +++ include/keys/trusted_tee.h | 55 ++++ include/keys/trusted_tpm.h | 17 +- security/keys/trusted-keys/Makefile | 2 + security/keys/trusted-keys/trusted_core.c | 325 +++++++++++++++++++++ security/keys/trusted-keys/trusted_tee.c | 278 ++++++++++++++++++ security/keys/trusted-keys/trusted_tpm1.c | 336 ++++------------------ 9 files changed, 939 insertions(+), 327 deletions(-) create mode 100644 include/keys/trusted_tee.h create mode 100644 security/keys/trusted-keys/trusted_core.c create mode 100644 security/keys/trusted-keys/trusted_tee.c -- 2.7.4

4 years, 2 months

2
7
0 0

[PATCH] tee/tee_shm.c: Fix error handling path

by Souptick Joarder

When shm->num_pages <= 0, we should avoid calling release_registered_pages() in error handling path. Signed-off-by: Souptick Joarder <jrdr.linux(a)gmail.com> Cc: John Hubbard <jhubbard(a)nvidia.com> --- drivers/tee/tee_shm.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c index 00472f5..e517d9f 100644 --- a/drivers/tee/tee_shm.c +++ b/drivers/tee/tee_shm.c @@ -260,8 +260,7 @@ struct tee_shm *tee_shm_register(struct tee_context *ctx, unsigned long addr, rc = get_kernel_pages(kiov, num_pages, 0, shm->pages); kfree(kiov); } - if (rc > 0) - shm->num_pages = rc; + shm->num_pages = rc; if (rc != num_pages) { if (rc >= 0) rc = -ENOMEM; @@ -309,7 +308,9 @@ struct tee_shm *tee_shm_register(struct tee_context *ctx, unsigned long addr, idr_remove(&teedev->idr, shm->id); mutex_unlock(&teedev->mutex); } - release_registered_pages(shm); + if (shm->pages && (shm->num_pages > 0)) + release_registered_pages(shm); + } kfree(shm); teedev_ctx_put(ctx); -- 1.9.1

4 years, 2 months

2
2
0 0

Re: [PATCH] tee/tee_shm.c: Fix error handling path

by Markus Elfring

> When shm->num_pages <= 0, we should avoid calling > release_registered_pages() in error handling path. * Would an imperative wording become helpful for the change description? * I suggest to add the tag “Fixes” to the commit message. Regards, Markus

4 years, 2 months

2
1
0 0

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, 2 months

2
4
0 0

2024

2023

2022

2021

2020

OP-TEE September 2020