- OP-TEE - lists.trustedfirmware.org

by Rijo Thomas

AMD-TEE driver keeps track of shared memory buffers and their corresponding buffer id's in a global linked list. These buffers are used to share data between x86 and AMD Secure Processor. This patchset fixes issues related to maintaining mapped buffers in a shared linked list. Rijo Thomas (2): tee: amdtee: fix memory leak due to reset of global shm list tee: amdtee: synchronize access to shm list drivers/tee/amdtee/amdtee_private.h | 8 ++++---- drivers/tee/amdtee/core.c | 26 +++++++++++++++++++------- 2 files changed, 23 insertions(+), 11 deletions(-) -- 2.17.1

5 years, 7 months

2
3
0 0

Mbed TLS Virtual Workshop Tomorrow

by Shebu Varghese Kuriakose

Hi All, Gentle reminder about the Mbed TLS workshop tomorrow (Tuesday, November 3rd) from 2 to 6pm GMT. See agenda and zoom link here - https://www.trustedfirmware.org/meetings/mbed-tls-workshop/ Thanks, Shebu -----Original Appointment----- From: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com> Sent: Friday, October 23, 2020 12:32 AM To: Trusted Firmware Public Meetings; Shebu Varghese Kuriakose; mbed-tls(a)lists.trustedfirmware.org; Don Harbin; psa-crypto(a)lists.trustedfirmware.org; Dave Rodgman Subject: Mbed TLS Virtual Workshop When: Tuesday, November 3, 2020 2:00 PM-6:00 PM (UTC+00:00) Dublin, Edinburgh, Lisbon, London. Where: Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… You have been invited to the following event. Mbed TLS Virtual Workshop When Tue Nov 3, 2020 7am – 11am Mountain Standard Time - Phoenix Where Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… (map<https://www.google.com/maps/search/Zoom:+https:%2F%2Flinaro-org.zoom.us%2Fj…>) Calendar shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> Who • Don Harbin - creator • shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> • mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> • psa-crypto(a)lists.trustedfirmware.org<mailto:psa-crypto@lists.trustedfirmware.org> • dave.rodgman(a)arm.com<mailto:dave.rodgman@arm.com> more details »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…> Hi, Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop. The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss * The future direction of the project and * Ways to improve community collaboration Here is the agenda for the workshop. Topic Time (in GMT) Welcome 2.00 - 2.10pm Constant-time code 2.10 – 2.30pm Processes - how does work get scheduled? 2.30 – 2.50pm PSA Crypto APIs 2.50 – 3.20pm PSA Crypto for Silicon Labs Wireless MCUs - Why, What, Where and When 3.20 – 3.50pm Break Roadmap, TLS1.3 Update 4.10 – 4.30pm Mbed TLS 3.0 Plans, Scope 4.30 – 5.00pm How do I contribute my first review and be an effective Mbed TLS reviewer 5.00 – 5.30pm Regards, Don Harbin Trusted Firmware Community Manager ==============Zoom details below:==================== Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: Mbed TLS Virtual Workshop Time: Nov 3, 2020 02:00 PM Greenwich Mean Time Join Zoom Meeting https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9531520…> Meeting ID: 953 1520 0315 Passcode: 143755 One tap mobile +16699009128,,95315200315# US (San Jose) +12532158782,,95315200315# US (Tacoma) Dial by your location +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 646 558 8656 US (New York) +1 301 715 8592 US (Germantown) +1 312 626 6799 US (Chicago) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 953 1520 0315 Find your local number: https://linaro-org.zoom.us/u/apL3hgti4<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fu%2FapL3hgt…> Going (shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>)? Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More<https://support.google.com/calendar/answer/37135#forwarding>.

5 years, 7 months

1
0
0 0

[GIT PULL] OP-TEE use UUID API for v5.10

by Jens Wiklander

Hello arm-soc maintainers, Please pull this small patch which allows to hide uuit_t internals from the OP-TEE driver. I know it's a bit late for v5.10, if it's too late please queue it for v5.11 instead. 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-use-uuid-api-for-v5.10 for you to fetch changes up to 57222a1be27e06ecb81cc2f945e897814d5f461c: tee: optee: Use UUID API for exporting the UUID (2020-10-13 08:03:18 +0200) ---------------------------------------------------------------- Use UUID API to export the UUID Uses export_uuid() to export and uuid_t to an u8 array instead of depending on the internals of uuid_t. ---------------------------------------------------------------- Andy Shevchenko (1): tee: optee: Use UUID API for exporting the UUID drivers/tee/optee/device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

5 years, 8 months

2
1
0 0

[PATCH] tee: optee: Set a flag to avoid memory leaks

by Wang, Xiaolei

When an rpc message to release memory is not received, a memory leak will occur, which should be released unreferenced object 0xffff00006871b580 (size 128): comm "swapper/0", pid 1, jiffies 4294892673 (age 428.192s) hex dump (first 32 bytes): 80 b3 71 68 00 00 ff ff 00 e0 71 a8 00 00 00 00 ..qh......q..... 00 e0 71 68 00 00 ff ff 00 10 00 00 00 00 00 00 ..qh............ backtrace: [<00000000f0425299>] slab_post_alloc_hook+0x6c/0x338 [<000000004705f905>] kmem_cache_alloc+0x1d4/0x328 [<00000000773c66a0>] tee_shm_alloc+0x84/0x268 [<00000000ca052f98>] optee_handle_rpc+0x144/0x5a0 [<0000000015a8eebe>] optee_do_call_with_arg+0x14c/0x168 [<00000000d51ef0fd>] optee_open_session+0x12c/0x200 [<000000007146f51d>] tee_client_open_session+0x24/0x38 [<00000000ea2b35e7>] optee_enumerate_devices+0xa0/0x2c0 [<0000000068088775>] optee_probe+0x560/0x690 [<00000000ad1d997a>] platform_drv_probe+0x54/0xa8 [<00000000e11592d4>] really_probe+0x118/0x3e0 [<00000000dacd3142>] driver_probe_device+0x5c/0xc0 [<0000000077c13842>] device_driver_attach+0x74/0x80 [<00000000106ccc62>] __driver_attach+0x8c/0xd8 [<00000000e120c345>] bus_for_each_dev+0x7c/0xd8 [<00000000b79335f5>] driver_attach+0x24/0x30 Signed-off-by: Xiaolei Wang <xiaolei.wang(a)windriver.com<mailto:xiaolei.wang@windriver.com>> --- drivers/tee/optee/call.c | 7 ++++++- drivers/tee/optee/optee_private.h | 2 +- drivers/tee/optee/rpc.c | 4 +++- 3 files changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c index 20b6fd7383c5..522c133b9d95 100644 --- a/drivers/tee/optee/call.c +++ b/drivers/tee/optee/call.c @@ -129,6 +129,7 @@ u32 optee_do_call_with_arg(struct tee_context *ctx, phys_addr_t parg) struct optee_rpc_param param = { }; struct optee_call_ctx call_ctx = { }; u32 ret; + unsigned int flags = 0; param.a0 = OPTEE_SMC_CALL_WITH_ARG; reg_pair_from_64(&param.a1, &param.a2, parg); @@ -153,9 +154,13 @@ u32 optee_do_call_with_arg(struct tee_context *ctx, phys_addr_t parg) param.a1 = res.a1; param.a2 = res.a2; param.a3 = res.a3; - optee_handle_rpc(ctx, &param, &call_ctx); + optee_handle_rpc(ctx, &param, &call_ctx, &flags); } else { ret = res.a0; + if (flags != 0x0) { + param.a0 = 2; + optee_handle_rpc(ctx, &param, &call_ctx, &flags); + } break; } } diff --git a/drivers/tee/optee/optee_private.h b/drivers/tee/optee/optee_private.h index 8b71839a357e..1c1d62e21141 100644 --- a/drivers/tee/optee/optee_private.h +++ b/drivers/tee/optee/optee_private.h @@ -127,7 +127,7 @@ struct optee_call_ctx { }; void optee_handle_rpc(struct tee_context *ctx, struct optee_rpc_param *param, - struct optee_call_ctx *call_ctx); + struct optee_call_ctx *call_ctx, unsigned int *flags); void optee_rpc_finalize_call(struct optee_call_ctx *call_ctx); void optee_wait_queue_init(struct optee_wait_queue *wq); diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c index b4ade54d1f28..4e76c87b61f4 100644 --- a/drivers/tee/optee/rpc.c +++ b/drivers/tee/optee/rpc.c @@ -396,7 +396,7 @@ static void handle_rpc_func_cmd(struct tee_context *ctx, struct optee *optee, * Result of RPC is written back into @param. */ void optee_handle_rpc(struct tee_context *ctx, struct optee_rpc_param *param, - struct optee_call_ctx *call_ctx) + struct optee_call_ctx *call_ctx, unsigned int *flags) { struct tee_device *teedev = ctx->teedev; struct optee *optee = tee_get_drvdata(teedev); @@ -410,6 +410,7 @@ void optee_handle_rpc(struct tee_context *ctx, struct optee_rpc_param *param, reg_pair_from_64(&param->a1, &param->a2, pa); reg_pair_from_64(&param->a4, &param->a5, (unsigned long)shm); + *flags = 0x1; } else { param->a1 = 0; param->a2 = 0; @@ -420,6 +421,7 @@ void optee_handle_rpc(struct tee_context *ctx, struct optee_rpc_param *param, case OPTEE_SMC_RPC_FUNC_FREE: shm = reg_pair_to_ptr(param->a1, param->a2); tee_shm_free(shm); + *flags = 0x0; break; case OPTEE_SMC_RPC_FUNC_FOREIGN_INTR: /* -- 2.25.1

5 years, 8 months

2
1
0 0

[PATCH v7 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 v7: 1. Added a trusted.source module parameter in order to enforce user's choice in case a particular platform posses both TPM and TEE. 2. Refine commit description for patch #1. 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 | 47 +++ 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 | 334 +++++++++++++++++++++ security/keys/trusted-keys/trusted_tee.c | 278 ++++++++++++++++++ security/keys/trusted-keys/trusted_tpm1.c | 336 ++++------------------ 9 files changed, 953 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

5 years, 8 months

4
18
0 0

OP-TEE 3.11.0 has been released

by Jerome Forissier

[BCC all OP-TEE maintainers] Hi, FYI, I have just finalized the OP-TEE 3.11.0 release (changelog [1]). Once again, 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.11.0/CHANGELOG.md [2] https://github.com/OP-TEE/optee_os/commit/c4def2a8262a Regards, -- Jerome

5 years, 8 months

1
0
0 0

[GIT PULL] TEE fix for v5.10

by Jens Wiklander

Hello arm-soc maintainers, Please pull this small fix which reenables the kernel login method in the kernel internal TEE client API. This fixes a problem introduced in v5.8. 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-fix-for-v5.10 for you to fetch changes up to 722939528a37aa0cb22d441e2045c0cf53e78fb0: tee: client UUID: Skip REE kernel login method as well (2020-10-13 08:42:11 +0200) ---------------------------------------------------------------- Reenable kernel login method for kernel TEE client API The kernel TEE login method was accidentally disabled previously when enabling a few other login methods, so fix that here. ---------------------------------------------------------------- Sumit Garg (1): tee: client UUID: Skip REE kernel login method as well drivers/tee/tee_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

5 years, 8 months

1
0
0 0

Re: [PATCH v1] firmware: tee_bnxt: Use UUID API for exporting the UUID

by Andy Shevchenko

On Thu, Jun 18, 2020 at 01:56:48PM +0300, Andy Shevchenko wrote: > On Wed, Apr 22, 2020 at 04:00:21PM +0300, Andy Shevchenko wrote: > > There is export_uuid() function which exports uuid_t to the u8 array. > > Use it instead of open coding variant. > > > > This allows to hide the uuid_t internals. > > Any comment on this? Guys, who is going to pick this up? > > Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> > > --- > > drivers/firmware/broadcom/tee_bnxt_fw.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/firmware/broadcom/tee_bnxt_fw.c b/drivers/firmware/broadcom/tee_bnxt_fw.c > > index ed10da5313e86..4cf0c2576037d 100644 > > --- a/drivers/firmware/broadcom/tee_bnxt_fw.c > > +++ b/drivers/firmware/broadcom/tee_bnxt_fw.c > > @@ -197,7 +197,7 @@ static int tee_bnxt_fw_probe(struct device *dev) > > return -ENODEV; > > > > /* Open session with Bnxt load Trusted App */ > > - memcpy(sess_arg.uuid, bnxt_device->id.uuid.b, TEE_IOCTL_UUID_LEN); > > + export_uuid(sess_arg.uuid, &bnxt_device->id.uuid); > > sess_arg.clnt_login = TEE_IOCTL_LOGIN_PUBLIC; > > sess_arg.num_params = 0; > > -- With Best Regards, Andy Shevchenko

5 years, 8 months

1
0
0 0

Mbed TLS Virtual Workshop on Nov. 3rd

by Shebu Varghese Kuriakose

Hi All, Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop on November 3rd (Tuesday) from 2pm to 6pm GMT. The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss * The future direction of the project and * Ways to improve community collaboration The workshop will be hosted in Zoom open to all. The invitation with the zoom link will be send in the Mbed TLS, PSA Crypto* mailing lists in the coming days. Here are some of the proposed agenda topics. Please reply if there is anything else you would like us or you to present during the workshop that will be interesting to the community * Constant-time code * How to be an effective Mbed TLS reviewer * Processes - how does work get scheduled? * Roadmap, Mbed TLS3.0 * PSA Crypto APIs * How Do I contribute my first review. Thanks, Shebu (TrustedFirmware.org Co-Chair, Mbed TLS Technology Manager) * https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls https://lists.trustedfirmware.org/mailman/listinfo/psa-crypto

5 years, 8 months

1
0
0 0

Preparing for OP-TEE 3.11.0

by Jerome Forissier

[BCC all OP-TEE maintainers] Hi OP-TEE maintainers & contributors, OP-TEE 3.11.0 is scheduled to be released on Friday, October 16th. So, now is a good time to start testing the master branch on the various platforms and report/fix any bugs. The GitHub pull request for collecting Tested-by tags or any other comment is https://github.com/OP-TEE/optee_os/pull/4101. As usual, I will create a release candidate tag one week before the release date for final testing. Thanks! Regards, -- Jerome

5 years, 8 months

2
1
0 0

[PATCH v3] tee: add support for application-based session login methods

by Elvira Khabirova

GP TEE Client API in addition to login methods already supported in the kernel also defines several application-based methods: TEEC_LOGIN_APPLICATION, TEEC_LOGIN_USER_APPLICATION, and TEEC_LOGIN_GROUP_APPLICATION. It specifies credentials generated for TEEC_LOGIN_APPLICATION as only depending on the identity of the program, being persistent within one implementation, across multiple invocations of the application and across power cycles, enabling them to be used to disambiguate persistent storage. The exact nature is REE-specific. As the exact method of generating application identifier strings may vary between vendors, setups and installations, add two suggested methods and an exact framework for vendors to extend upon. Signed-off-by: Elvira Khabirova <e.khabirova(a)omprussia.ru> --- Jens, do you have any advice on finding more reviewers for this? Changes in v3: - Remove free_app_id() and replace it with calls to kfree(). Changes in v2: - Rename some functions and variables to make them shorter. - Include linux/security.h unconditionally. - Restructure error handling in tee_session_calc_client_uuid(). drivers/tee/Kconfig | 29 ++++++++++ drivers/tee/tee_core.c | 126 ++++++++++++++++++++++++++++++++++++++--- 2 files changed, 147 insertions(+), 8 deletions(-) diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig index e99d840c2511..4cd6e0d2aad5 100644 --- a/drivers/tee/Kconfig +++ b/drivers/tee/Kconfig @@ -11,6 +11,35 @@ config TEE This implements a generic interface towards a Trusted Execution Environment (TEE). +choice + prompt "Application ID for client UUID" + depends on TEE + default TEE_APPID_PATH + help + This option allows to choose which method will be used to generate + application identifiers for client UUID generation when login methods + TEE_LOGIN_APPLICATION, TEE_LOGIN_USER_APPLICATION + and TEE_LOGIN_GROUP_APPLICATION are used. + Please be mindful of the security of each method in your particular + installation. + + config TEE_APPID_PATH + bool "Path-based application ID" + help + Use the executable's path as an application ID. + + config TEE_APPID_SECURITY + bool "Security extended attribute based application ID" + help + Use the executable's security extended attribute as an application ID. +endchoice + +config TEE_APPID_SECURITY_XATTR + string "Security extended attribute to use for application ID" + depends on TEE_APPID_SECURITY + help + Attribute to be used as an application ID (with the security prefix removed). + if TEE menu "TEE drivers" diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index 64637e09a095..3626ce0d9bd7 100644 --- a/drivers/tee/tee_core.c +++ b/drivers/tee/tee_core.c @@ -7,9 +7,12 @@ #include <linux/cdev.h> #include <linux/cred.h> +#include <linux/file.h> #include <linux/fs.h> #include <linux/idr.h> +#include <linux/mm.h> #include <linux/module.h> +#include <linux/security.h> #include <linux/slab.h> #include <linux/tee_drv.h> #include <linux/uaccess.h> @@ -21,7 +24,7 @@ #define TEE_IOCTL_PARAM_SIZE(x) (sizeof(struct tee_param) * (x)) -#define TEE_UUID_NS_NAME_SIZE 128 +#define TEE_UUID_NS_NAME_SIZE PATH_MAX /* * TEE Client UUID name space identifier (UUIDv4) @@ -125,6 +128,65 @@ static int tee_release(struct inode *inode, struct file *filp) return 0; } +#ifdef CONFIG_TEE_APPID_SECURITY +static const char *get_app_id(void **data) +{ + struct file *exe_file; + const char *name = CONFIG_TEE_APPID_SECURITY_XATTR; + int len; + + exe_file = get_mm_exe_file(current->mm); + if (!exe_file) + return ERR_PTR(-ENOENT); + + if (!exe_file->f_inode) { + fput(exe_file); + return ERR_PTR(-ENOENT); + } + + /* + * An identifier string for the binary. Depends on the implementation. + * Could be, for example, a string containing the application vendor ID, + * or the binary's signature, or its hash and a timestamp. + */ + len = security_inode_getsecurity(exe_file->f_inode, name, data, true); + if (len < 0) + return ERR_PTR(len); + + fput(exe_file); + + return *data; +} +#endif /* CONFIG_TEE_APPID_SECURITY */ + +#ifdef CONFIG_TEE_APPID_PATH +static const char *get_app_id(void **data) +{ + struct file *exe_file; + char *path; + + *data = kzalloc(TEE_UUID_NS_NAME_SIZE, GFP_KERNEL); + if (!*data) + return ERR_PTR(-ENOMEM); + + exe_file = get_mm_exe_file(current->mm); + if (!exe_file) { + kfree(*data); + return ERR_PTR(-ENOENT); + } + + path = file_path(exe_file, *data, TEE_UUID_NS_NAME_SIZE); + if (IS_ERR(path)) { + kfree(*data); + return path; + } + + fput(exe_file); + + return path; +} +#endif /* CONFIG_TEE_APPID_PATH */ + /** * uuid_v5() - Calculate UUIDv5 * @uuid: Resulting UUID @@ -197,6 +259,8 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, gid_t ns_grp = (gid_t)-1; kgid_t grp = INVALID_GID; char *name = NULL; + void *app_id_data = NULL; + const char *app_id = NULL; int name_len; int rc; @@ -217,6 +281,14 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, * For TEEC_LOGIN_GROUP: * gid=<gid> * + * For TEEC_LOGIN_APPLICATION: + * app=<application id> + * + * For TEEC_LOGIN_USER_APPLICATION: + * uid=<uid>:app=<application id> + * + * For TEEC_LOGIN_GROUP_APPLICATION: + * gid=<gid>:app=<application id> */ name = kzalloc(TEE_UUID_NS_NAME_SIZE, GFP_KERNEL); @@ -227,10 +299,6 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, case TEE_IOCTL_LOGIN_USER: name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "uid=%x", current_euid().val); - if (name_len >= TEE_UUID_NS_NAME_SIZE) { - rc = -E2BIG; - goto out_free_name; - } break; case TEE_IOCTL_LOGIN_GROUP: @@ -243,10 +311,49 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "gid=%x", grp.val); - if (name_len >= TEE_UUID_NS_NAME_SIZE) { - rc = -E2BIG; + break; + + case TEE_IOCTL_LOGIN_APPLICATION: + app_id = get_app_id(&app_id_data); + if (IS_ERR(app_id)) { + rc = PTR_ERR(app_id); + goto out_free_name; + } + + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "app=%s", + app_id); + kfree(app_id_data); + break; + + case TEE_IOCTL_LOGIN_USER_APPLICATION: + app_id = get_app_id(&app_id_data); + if (IS_ERR(app_id)) { + rc = PTR_ERR(app_id); goto out_free_name; } + + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "uid=%x:app=%s", + current_euid().val, app_id); + kfree(app_id_data); + break; + + case TEE_IOCTL_LOGIN_GROUP_APPLICATION: + memcpy(&ns_grp, connection_data, sizeof(gid_t)); + grp = make_kgid(current_user_ns(), ns_grp); + if (!gid_valid(grp) || !in_egroup_p(grp)) { + rc = -EPERM; + goto out_free_name; + } + + app_id = get_app_id(&app_id_data); + if (IS_ERR(app_id)) { + rc = PTR_ERR(app_id); + goto out_free_name; + } + + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "gid=%x:app=%s", + grp.val, app_id); + kfree(app_id_data); break; default: @@ -254,7 +361,10 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, goto out_free_name; } - rc = uuid_v5(uuid, &tee_client_uuid_ns, name, name_len); + if (name_len < TEE_UUID_NS_NAME_SIZE) + rc = uuid_v5(uuid, &tee_client_uuid_ns, name, name_len); + else + rc = -E2BIG; out_free_name: kfree(name); -- 2.28.0

5 years, 8 months

1
0
0 0

[PATCH] tee: optee: replace might_sleep with cond_resched

by Rouven Czerwinski

On Kernels with CONFIG_PREEMPT_NONE might_sleep() is not enough to force rescheduling, replace it with a resched check and cond_resched. Fixes the following stall: [ 572.945146] rcu: INFO: rcu_sched self-detected stall on CPU [ 572.949275] rcu: 0-....: (2099 ticks this GP) idle=572/1/0x40000002 softirq=7412/7412 fqs=974 [ 572.957964] (t=2100 jiffies g=10393 q=21) [ 572.962054] NMI backtrace for cpu 0 [ 572.965540] CPU: 0 PID: 165 Comm: xtest Not tainted 5.8.7 #1 [ 572.971188] Hardware name: STM32 (Device Tree Support) [ 572.976354] [<c011163c>] (unwind_backtrace) from [<c010b7f8>] (show_stack+0x10/0x14) [ 572.984080] [<c010b7f8>] (show_stack) from [<c0511e4c>] (dump_stack+0xc4/0xd8) [ 572.991300] [<c0511e4c>] (dump_stack) from [<c0519abc>] (nmi_cpu_backtrace+0x90/0xc4) [ 572.999130] [<c0519abc>] (nmi_cpu_backtrace) from [<c0519bdc>] (nmi_trigger_cpumask_backtrace+0xec/0x130) [ 573.008706] [<c0519bdc>] (nmi_trigger_cpumask_backtrace) from [<c01a5184>] (rcu_dump_cpu_stacks+0xe8/0x110) [ 573.018453] [<c01a5184>] (rcu_dump_cpu_stacks) from [<c01a4234>] (rcu_sched_clock_irq+0x7fc/0xa88) [ 573.027416] [<c01a4234>] (rcu_sched_clock_irq) from [<c01acdd0>] (update_process_times+0x30/0x8c) [ 573.036291] [<c01acdd0>] (update_process_times) from [<c01bfb90>] (tick_sched_timer+0x4c/0xa8) [ 573.044905] [<c01bfb90>] (tick_sched_timer) from [<c01adcc8>] (__hrtimer_run_queues+0x174/0x358) [ 573.053696] [<c01adcc8>] (__hrtimer_run_queues) from [<c01aea2c>] (hrtimer_interrupt+0x118/0x2bc) [ 573.062573] [<c01aea2c>] (hrtimer_interrupt) from [<c09ad664>] (arch_timer_handler_virt+0x28/0x30) [ 573.071536] [<c09ad664>] (arch_timer_handler_virt) from [<c0190f50>] (handle_percpu_devid_irq+0x8c/0x240) [ 573.081109] [<c0190f50>] (handle_percpu_devid_irq) from [<c018ab8c>] (generic_handle_irq+0x34/0x44) [ 573.090156] [<c018ab8c>] (generic_handle_irq) from [<c018b194>] (__handle_domain_irq+0x5c/0xb0) [ 573.098857] [<c018b194>] (__handle_domain_irq) from [<c052ac50>] (gic_handle_irq+0x4c/0x90) [ 573.107209] [<c052ac50>] (gic_handle_irq) from [<c0100b0c>] (__irq_svc+0x6c/0x90) [ 573.114682] Exception stack(0xd90dfcf8 to 0xd90dfd40) [ 573.119732] fce0: ffff0004 00000000 [ 573.127917] fd00: 00000000 00000000 00000000 00000000 00000000 00000000 d93493cc ffff0000 [ 573.136098] fd20: d2bc39c0 be926998 d90dfd58 d90dfd48 c09f3384 c01151f0 400d0013 ffffffff [ 573.144281] [<c0100b0c>] (__irq_svc) from [<c01151f0>] (__arm_smccc_smc+0x10/0x20) [ 573.151854] [<c01151f0>] (__arm_smccc_smc) from [<c09f3384>] (optee_smccc_smc+0x3c/0x44) [ 573.159948] [<c09f3384>] (optee_smccc_smc) from [<c09f4170>] (optee_do_call_with_arg+0xb8/0x154) [ 573.168735] [<c09f4170>] (optee_do_call_with_arg) from [<c09f4638>] (optee_invoke_func+0x110/0x190) [ 573.177786] [<c09f4638>] (optee_invoke_func) from [<c09f1ebc>] (tee_ioctl+0x10b8/0x11c0) [ 573.185879] [<c09f1ebc>] (tee_ioctl) from [<c029f62c>] (ksys_ioctl+0xe0/0xa4c) [ 573.193101] [<c029f62c>] (ksys_ioctl) from [<c0100060>] (ret_fast_syscall+0x0/0x54) [ 573.200750] Exception stack(0xd90dffa8 to 0xd90dfff0) [ 573.205803] ffa0: be926bf4 be926a78 00000003 8010a403 be926908 004e3cf8 [ 573.213987] ffc0: be926bf4 be926a78 00000000 00000036 be926908 be926918 be9269b0 bffdf0f8 [ 573.222162] ffe0: b6d76fb0 be9268fc b6d66621 b6c7e0d8 seen on STM32 DK2. Signed-off-by: Rouven Czerwinski <r.czerwinski(a)pengutronix.de> --- drivers/tee/optee/call.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c index 20b6fd7383c5..83b73b1d52f0 100644 --- a/drivers/tee/optee/call.c +++ b/drivers/tee/optee/call.c @@ -8,6 +8,7 @@ #include <linux/errno.h> #include <linux/mm.h> #include <linux/slab.h> +#include <linux/sched.h> #include <linux/tee_drv.h> #include <linux/types.h> #include <linux/uaccess.h> @@ -148,7 +149,8 @@ u32 optee_do_call_with_arg(struct tee_context *ctx, phys_addr_t parg) */ optee_cq_wait_for_completion(&optee->call_queue, &w); } else if (OPTEE_SMC_RETURN_IS_RPC(res.a0)) { - might_sleep(); + if(need_resched()) + cond_resched(); param.a0 = res.a0; param.a1 = res.a1; param.a2 = res.a2; -- 2.28.0

5 years, 8 months

3
2
0 0

[PATCH v2] tee: add support for application-based session login methods

by Elvira Khabirova

GP TEE Client API in addition to login methods already supported in the kernel also defines several application-based methods: TEEC_LOGIN_APPLICATION, TEEC_LOGIN_USER_APPLICATION, and TEEC_LOGIN_GROUP_APPLICATION. It specifies credentials generated for TEEC_LOGIN_APPLICATION as only depending on the identity of the program, being persistent within one implementation, across multiple invocations of the application and across power cycles, enabling them to be used to disambiguate persistent storage. The exact nature is REE-specific. As the exact method of generating application identifier strings may vary between vendors, setups and installations, add two suggested methods and an exact framework for vendors to extend upon. Signed-off-by: Elvira Khabirova <e.khabirova(a)omprussia.ru> --- drivers/tee/Kconfig | 29 +++++++++ drivers/tee/tee_core.c | 133 ++++++++++++++++++++++++++++++++++++++--- 2 files changed, 154 insertions(+), 8 deletions(-) diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig index 6488b66d69dd..cd8f02a3d488 100644 --- a/drivers/tee/Kconfig +++ b/drivers/tee/Kconfig @@ -10,6 +10,35 @@ config TEE This implements a generic interface towards a Trusted Execution Environment (TEE). +choice + prompt "Application ID for client UUID" + depends on TEE + default TEE_APPID_PATH + help + This option allows to choose which method will be used to generate + application identifiers for client UUID generation when login methods + TEE_LOGIN_APPLICATION, TEE_LOGIN_USER_APPLICATION + and TEE_LOGIN_GROUP_APPLICATION are used. + Please be mindful of the security of each method in your particular + installation. + + config TEE_APPID_PATH + bool "Path-based application ID" + help + Use the executable's path as an application ID. + + config TEE_APPID_SECURITY + bool "Security extended attribute based application ID" + help + Use the executable's security extended attribute as an application ID. +endchoice + +config TEE_APPID_SECURITY_XATTR + string "Security extended attribute to use for application ID" + depends on TEE_APPID_SECURITY + help + Attribute to be used as an application ID (with the security prefix removed). + if TEE menu "TEE drivers" diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index 67186d00a52f..31fb244b59ed 100644 --- a/drivers/tee/tee_core.c +++ b/drivers/tee/tee_core.c @@ -16,9 +16,12 @@ #include <linux/cdev.h> #include <linux/cred.h> +#include <linux/file.h> #include <linux/fs.h> #include <linux/idr.h> +#include <linux/mm.h> #include <linux/module.h> +#include <linux/security.h> #include <linux/slab.h> #include <linux/tee_drv.h> #include <linux/uaccess.h> @@ -31,7 +34,7 @@ #define TEE_IOCTL_PARAM_SIZE(x) (sizeof(struct tee_param) * (x)) -#define TEE_UUID_NS_NAME_SIZE 128 +#define TEE_UUID_NS_NAME_SIZE PATH_MAX /* * TEE Client UUID name space identifier (UUIDv4) @@ -136,6 +139,72 @@ static int tee_release(struct inode *inode, struct file *filp) return 0; } +#ifdef CONFIG_TEE_APPID_SECURITY +static const char *get_app_id(void **data) +{ + struct file *exe_file; + const char *name = CONFIG_TEE_APPID_SECURITY_XATTR; + int len; + + exe_file = get_mm_exe_file(current->mm); + if (!exe_file) + return ERR_PTR(-ENOENT); + + if (!exe_file->f_inode) { + fput(exe_file); + return ERR_PTR(-ENOENT); + } + + /* + * An identifier string for the binary. Depends on the implementation. + * Could be, for example, a string containing the application vendor ID, + * or the binary's signature, or its hash and a timestamp. + */ + len = security_inode_getsecurity(exe_file->f_inode, name, data, true); + if (len < 0) + return ERR_PTR(len); + + fput(exe_file); + + return *data; +} +#endif /* CONFIG_TEE_APPID_SECURITY */ + +#ifdef CONFIG_TEE_APPID_PATH +static const char *get_app_id(void **data) +{ + struct file *exe_file; + char *path; + + *data = kzalloc(TEE_UUID_NS_NAME_SIZE, GFP_KERNEL); + if (!*data) + return ERR_PTR(-ENOMEM); + + exe_file = get_mm_exe_file(current->mm); + if (!exe_file) { + kfree(*data); + return ERR_PTR(-ENOENT); + } + + path = file_path(exe_file, *data, TEE_UUID_NS_NAME_SIZE); + if (IS_ERR(path)) { + kfree(*data); + return path; + } + + fput(exe_file); + + return path; +} +#endif /* CONFIG_TEE_APPID_PATH */ + +#if defined(CONFIG_TEE_APPID_PATH) || defined(CONFIG_TEE_APPID_SECURITY) +static void free_app_id(void *data) +{ + kfree(data); +} +#endif /* CONFIG_TEE_APPID_PATH || CONFIG_TEE_APPID_SECURITY */ + /** * uuid_v5() - Calculate UUIDv5 * @uuid: Resulting UUID @@ -208,6 +277,8 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, gid_t ns_grp = (gid_t)-1; kgid_t grp = INVALID_GID; char *name = NULL; + void *app_id_data = NULL; + const char *app_id = NULL; int name_len; int rc; @@ -228,6 +299,14 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, * For TEEC_LOGIN_GROUP: * gid=<gid> * + * For TEEC_LOGIN_APPLICATION: + * app=<application id> + * + * For TEEC_LOGIN_USER_APPLICATION: + * uid=<uid>:app=<application id> + * + * For TEEC_LOGIN_GROUP_APPLICATION: + * gid=<gid>:app=<application id> */ name = kzalloc(TEE_UUID_NS_NAME_SIZE, GFP_KERNEL); @@ -238,10 +317,6 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, case TEE_IOCTL_LOGIN_USER: name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "uid=%x", current_euid().val); - if (name_len >= TEE_UUID_NS_NAME_SIZE) { - rc = -E2BIG; - goto out_free_name; - } break; case TEE_IOCTL_LOGIN_GROUP: @@ -254,10 +329,49 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "gid=%x", grp.val); - if (name_len >= TEE_UUID_NS_NAME_SIZE) { - rc = -E2BIG; + break; + + case TEE_IOCTL_LOGIN_APPLICATION: + app_id = get_app_id(&app_id_data); + if (IS_ERR(app_id)) { + rc = PTR_ERR(app_id); + goto out_free_name; + } + + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "app=%s", + app_id); + free_app_id(app_id_data); + break; + + case TEE_IOCTL_LOGIN_USER_APPLICATION: + app_id = get_app_id(&app_id_data); + if (IS_ERR(app_id)) { + rc = PTR_ERR(app_id); + goto out_free_name; + } + + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "uid=%x:app=%s", + current_euid().val, app_id); + free_app_id(app_id_data); + break; + + case TEE_IOCTL_LOGIN_GROUP_APPLICATION: + memcpy(&ns_grp, connection_data, sizeof(gid_t)); + grp = make_kgid(current_user_ns(), ns_grp); + if (!gid_valid(grp) || !in_egroup_p(grp)) { + rc = -EPERM; + goto out_free_name; + } + + app_id = get_app_id(&app_id_data); + if (IS_ERR(app_id)) { + rc = PTR_ERR(app_id); goto out_free_name; } + + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "gid=%x:app=%s", + grp.val, app_id); + free_app_id(app_id_data); break; default: @@ -265,7 +379,10 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, goto out_free_name; } - rc = uuid_v5(uuid, &tee_client_uuid_ns, name, name_len); + if (name_len < TEE_UUID_NS_NAME_SIZE) + rc = uuid_v5(uuid, &tee_client_uuid_ns, name, name_len); + else + rc = -E2BIG; out_free_name: kfree(name); -- 2.17.1

5 years, 8 months

2
2
0 0

Re: Linaro OP-TEE Contributions meeting Sept 2020

by Jérôme Forissier

Hi Joakim, On Tue, Sep 29, 2020 at 12:00 PM Joakim Bech via OP-TEE < op-tee(a)lists.trustedfirmware.org> wrote: > Hi Jorge, > > On Tue, 29 Sep 2020 at 11:49, Jorge Ramirez <jorge(a)foundries.io> wrote: > > > Hi Joakim > > > > Shall we discuss how we want to extend the criptodriver API were > different > > algorithms can be taken from different ciphers? > > And maybe also how to communicate other than using the github frontend? I > > think this is useful in the case of relatively complex PR. > > > Sounds good to me, I'm adding that to the agenda. This concludes that there > _will_ be a LOC meeting tomorrow Wednesday 30th Sept @ 16.00 (UTC+2). > > Again, connection details etc can be found in the meeting notes document: > http://bit.ly/loc-notes Apologies for not joining, I had a calendar issue (my fault!). Since the date for the next release is confirmed and coming soon, I will create the release PR and send the notification email shortly. Thanks, -- Jerome

5 years, 8 months

1
0
0 0

[RFC PATCH] tee: add support for application-based session login methods

by Elvira Khabirova

GP TEE Client API in addition to login methods already supported in the kernel also defines several application-based methods: TEEC_LOGIN_APPLICATION, TEEC_LOGIN_USER_APPLICATION, and TEEC_LOGIN_GROUP_APPLICATION. It specifies credentials generated for TEEC_LOGIN_APPLICATION as only depending on the identity of the program, being persistent within one implementation, across multiple invocations of the application and across power cycles, enabling them to be used to disambiguate persistent storage. The exact nature is REE-specific. As the exact method of generating application identifier strings may vary between vendors, setups and installations, add two suggested methods and an exact framework for vendors to extend upon. Signed-off-by: Elvira Khabirova <e.khabirova(a)omprussia.ru> --- drivers/tee/Kconfig | 29 +++++++++ drivers/tee/tee_core.c | 136 ++++++++++++++++++++++++++++++++++++++++- 2 files changed, 164 insertions(+), 1 deletion(-) diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig index e99d840c2511..4cd6e0d2aad5 100644 --- a/drivers/tee/Kconfig +++ b/drivers/tee/Kconfig @@ -11,6 +11,35 @@ config TEE This implements a generic interface towards a Trusted Execution Environment (TEE). +choice + prompt "Application ID for client UUID" + depends on TEE + default TEE_APPID_PATH + help + This option allows to choose which method will be used to generate + application identifiers for client UUID generation when login methods + TEE_LOGIN_APPLICATION, TEE_LOGIN_USER_APPLICATION + and TEE_LOGIN_GROUP_APPLICATION are used. + Please be mindful of the security of each method in your particular + installation. + + config TEE_APPID_PATH + bool "Path-based application ID" + help + Use the executable's path as an application ID. + + config TEE_APPID_SECURITY + bool "Security extended attribute based application ID" + help + Use the executable's security extended attribute as an application ID. +endchoice + +config TEE_APPID_SECURITY_XATTR + string "Security extended attribute to use for application ID" + depends on TEE_APPID_SECURITY + help + Attribute to be used as an application ID (with the security prefix removed). + if TEE menu "TEE drivers" diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index 64637e09a095..19c965dd212b 100644 --- a/drivers/tee/tee_core.c +++ b/drivers/tee/tee_core.c @@ -7,8 +7,10 @@ #include <linux/cdev.h> #include <linux/cred.h> +#include <linux/file.h> #include <linux/fs.h> #include <linux/idr.h> +#include <linux/mm.h> #include <linux/module.h> #include <linux/slab.h> #include <linux/tee_drv.h> @@ -17,11 +19,15 @@ #include <crypto/sha.h> #include "tee_private.h" +#ifdef CONFIG_TEE_APPID_SECURITY +#include <linux/security.h> +#endif + #define TEE_NUM_DEVICES 32 #define TEE_IOCTL_PARAM_SIZE(x) (sizeof(struct tee_param) * (x)) -#define TEE_UUID_NS_NAME_SIZE 128 +#define TEE_UUID_NS_NAME_SIZE PATH_MAX /* * TEE Client UUID name space identifier (UUIDv4) @@ -125,6 +131,67 @@ static int tee_release(struct inode *inode, struct file *filp) return 0; } +#ifdef CONFIG_TEE_APPID_SECURITY +static const char *tee_session_get_application_id(void **data) +{ + struct file *exe_file; + const char *name = CONFIG_TEE_APPID_SECURITY_XATTR; + int len; + + exe_file = get_mm_exe_file(current->mm); + if (!exe_file) + return ERR_PTR(-ENOENT); + + if (!exe_file->f_inode) { + fput(exe_file); + return ERR_PTR(-ENOENT); + } + + len = security_inode_getsecurity(exe_file->f_inode, name, data, true); + if (len < 0) + return ERR_PTR(len); + + fput(exe_file); + + return *data; +} +#endif /* CONFIG_TEE_APPID_SECURITY */ + +#ifdef CONFIG_TEE_APPID_PATH +static const char *tee_session_get_application_id(void **data) +{ + struct file *exe_file; + char *path; + + *data = kzalloc(TEE_UUID_NS_NAME_SIZE, GFP_KERNEL); + if (!*data) + return ERR_PTR(-ENOMEM); + + exe_file = get_mm_exe_file(current->mm); + if (!exe_file) { + kfree(*data); + return ERR_PTR(-ENOENT); + } + + path = file_path(exe_file, *data, TEE_UUID_NS_NAME_SIZE); + if (IS_ERR(path)) { + kfree(*data); + return path; + } + + fput(exe_file); + + return path; +} +#endif /* CONFIG_TEE_APPID_PATH */ + +#if defined(CONFIG_TEE_APPID_PATH) || defined(CONFIG_TEE_APPID_SECURITY) +static void tee_session_free_application_id(void *data) +{ + kfree(data); +} +#endif /* CONFIG_TEE_APPID_PATH || CONFIG_TEE_APPID_SECURITY */ + /** * uuid_v5() - Calculate UUIDv5 * @uuid: Resulting UUID @@ -197,6 +264,8 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, gid_t ns_grp = (gid_t)-1; kgid_t grp = INVALID_GID; char *name = NULL; + void *application_id_data = NULL; + const char *application_id = NULL; int name_len; int rc; @@ -217,6 +286,14 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, * For TEEC_LOGIN_GROUP: * gid=<gid> * + * For TEEC_LOGIN_APPLICATION: + * app=<application id> + * + * For TEEC_LOGIN_USER_APPLICATION: + * uid=<uid>:app=<application id> + * + * For TEEC_LOGIN_GROUP_APPLICATION: + * gid=<gid>:app=<application id> */ name = kzalloc(TEE_UUID_NS_NAME_SIZE, GFP_KERNEL); @@ -249,6 +326,63 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, } break; + case TEE_IOCTL_LOGIN_APPLICATION: + application_id = tee_session_get_application_id(&application_id_data); + if (IS_ERR(application_id)) { + rc = PTR_ERR(application_id); + goto out_free_name; + } + + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "app=%s", + application_id); + tee_session_free_application_id(application_id_data); + + if (name_len >= TEE_UUID_NS_NAME_SIZE) { + rc = -E2BIG; + goto out_free_name; + } + break; + + case TEE_IOCTL_LOGIN_USER_APPLICATION: + application_id = tee_session_get_application_id(&application_id_data); + if (IS_ERR(application_id)) { + rc = PTR_ERR(application_id); + goto out_free_name; + } + + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "uid=%x:app=%s", + current_euid().val, application_id); + tee_session_free_application_id(application_id_data); + + if (name_len >= TEE_UUID_NS_NAME_SIZE) { + rc = -E2BIG; + goto out_free_name; + } + break; + + case TEE_IOCTL_LOGIN_GROUP_APPLICATION: + memcpy(&ns_grp, connection_data, sizeof(gid_t)); + grp = make_kgid(current_user_ns(), ns_grp); + if (!gid_valid(grp) || !in_egroup_p(grp)) { + rc = -EPERM; + goto out_free_name; + } + + application_id = tee_session_get_application_id(&application_id_data); + if (IS_ERR(application_id)) { + rc = PTR_ERR(application_id); + goto out_free_name; + } + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "gid=%x:app=%s", + grp.val, application_id); + tee_session_free_application_id(application_id_data); + + if (name_len >= TEE_UUID_NS_NAME_SIZE) { + rc = -E2BIG; + goto out_free_name; + } + break; + default: rc = -EINVAL; goto out_free_name; -- 2.28.0

5 years, 8 months

2
3
0 0

Re: Linaro OP-TEE Contributions meeting Sept 2020

by Jorge Ramirez

Hi Joakim Shall we discuss how we want to extend the criptodriver API were different algorithms can be taken from different ciphers? And maybe also how to communicate other than using the github frontend? I think this is useful in the case of relatively complex PR. thanks Jorge On Mon, Sep 28, 2020 at 1:08 PM Joakim Bech via OP-TEE < op-tee(a)lists.trustedfirmware.org> wrote: > Hi, > > Just a reminder, I have seen no suggestions for topics and if I hear > nothing until noon tomorrow 29/9 (UTC), then I'll cancel the September > meeting. > > Regards, > Joakim > > > On Thu, 17 Sep 2020 at 11:19, Joakim Bech <joakim.bech(a)linaro.org> wrote: > > > Hi, > > > > LOC monthly meeting is planned to take place Sept 30 @ 16.00 (UTC+2). > > Connection details can be found in the meeting notes document (link > below). > > > > This email is a request to gather topics to discuss. If there are no > > suggestions, then there will be no meeting (announced in this email > thread, > > if that's the case). To suggest a topic, either reply to this email > thread > > or add your topic directly into the meeting notes (or do both). > > > > Meeting details: > > --------------- > > Date/time: Wednesday Sept 30th(a)16.00 (UTC+2) > > https://everytimezone.com/s/92bd296e > > Invitation/connection details: In the meeting notes > > Meeting notes: http://bit.ly/loc-notes > > Project page: https://www.linaro.org/projects/#LOC > > > > Regards, > > Joakim on behalf of the Linaro OP-TEE team > > >

5 years, 8 months

2
1
0 0

Linaro OP-TEE Contributions meeting Sept 2020

by Joakim Bech

Hi, LOC monthly meeting is planned to take place Sept 30 @ 16.00 (UTC+2). Connection details can be found in the meeting notes document (link below). This email is a request to gather topics to discuss. If there are no suggestions, then there will be no meeting (announced in this email thread, if that's the case). To suggest a topic, either reply to this email thread or add your topic directly into the meeting notes (or do both). Meeting details: --------------- Date/time: Wednesday Sept 30th(a)16.00 (UTC+2) https://everytimezone.com/s/92bd296e Invitation/connection details: In the meeting notes Meeting notes: http://bit.ly/loc-notes Project page: https://www.linaro.org/projects/#LOC Regards, Joakim on behalf of the Linaro OP-TEE team

5 years, 8 months

1
1
0 0

Re: [RFC PATCH] tee: add support for application-based session login methods

by Elvira Khabirova

Hello, On Thu, 17 Sep 2020 15:46:07 +0000 Elvira Khabirova via OP-TEE <op-tee(a)lists.trustedfirmware.org> wrote: > GP TEE Client API in addition to login methods already supported > in the kernel also defines several application-based methods: > TEEC_LOGIN_APPLICATION, TEEC_LOGIN_USER_APPLICATION, and > TEEC_LOGIN_GROUP_APPLICATION. > > It specifies credentials generated for TEEC_LOGIN_APPLICATION as only > depending on the identity of the program, being persistent within one > implementation, across multiple invocations of the application > and across power cycles, enabling them to be used to disambiguate > persistent storage. The exact nature is REE-specific. > > As the exact method of generating application identifier strings may > vary between vendors, setups and installations, add two suggested > methods and an exact framework for vendors to extend upon. If there are no comments on this, I will resend this and drop [RFC] from the subject. > Signed-off-by: Elvira Khabirova <e.khabirova(a)omprussia.ru> > --- > drivers/tee/Kconfig | 29 +++++++++ > drivers/tee/tee_core.c | 136 ++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 164 insertions(+), 1 deletion(-) > > diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig > index e99d840c2511..4cd6e0d2aad5 100644 > --- a/drivers/tee/Kconfig > +++ b/drivers/tee/Kconfig > @@ -11,6 +11,35 @@ config TEE > This implements a generic interface towards a Trusted Execution > Environment (TEE). > > +choice > + prompt "Application ID for client UUID" > + depends on TEE > + default TEE_APPID_PATH > + help > + This option allows to choose which method will be used to generate > + application identifiers for client UUID generation when login methods > + TEE_LOGIN_APPLICATION, TEE_LOGIN_USER_APPLICATION > + and TEE_LOGIN_GROUP_APPLICATION are used. > + Please be mindful of the security of each method in your particular > + installation. > + > + config TEE_APPID_PATH > + bool "Path-based application ID" > + help > + Use the executable's path as an application ID. > + > + config TEE_APPID_SECURITY > + bool "Security extended attribute based application ID" > + help > + Use the executable's security extended attribute as an application ID. > +endchoice > + > +config TEE_APPID_SECURITY_XATTR > + string "Security extended attribute to use for application ID" > + depends on TEE_APPID_SECURITY > + help > + Attribute to be used as an application ID (with the security prefix removed). > + > if TEE > > menu "TEE drivers" > diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c > index 64637e09a095..19c965dd212b 100644 > --- a/drivers/tee/tee_core.c > +++ b/drivers/tee/tee_core.c > @@ -7,8 +7,10 @@ > > #include <linux/cdev.h> > #include <linux/cred.h> > +#include <linux/file.h> > #include <linux/fs.h> > #include <linux/idr.h> > +#include <linux/mm.h> > #include <linux/module.h> > #include <linux/slab.h> > #include <linux/tee_drv.h> > @@ -17,11 +19,15 @@ > #include <crypto/sha.h> > #include "tee_private.h" > > +#ifdef CONFIG_TEE_APPID_SECURITY > +#include <linux/security.h> > +#endif > + > #define TEE_NUM_DEVICES 32 > > #define TEE_IOCTL_PARAM_SIZE(x) (sizeof(struct tee_param) * (x)) > > -#define TEE_UUID_NS_NAME_SIZE 128 > +#define TEE_UUID_NS_NAME_SIZE PATH_MAX > > /* > * TEE Client UUID name space identifier (UUIDv4) > @@ -125,6 +131,67 @@ static int tee_release(struct inode *inode, struct file *filp) > return 0; > } > > +#ifdef CONFIG_TEE_APPID_SECURITY > +static const char *tee_session_get_application_id(void **data) > +{ > + struct file *exe_file; > + const char *name = CONFIG_TEE_APPID_SECURITY_XATTR; > + int len; > + > + exe_file = get_mm_exe_file(current->mm); > + if (!exe_file) > + return ERR_PTR(-ENOENT); > + > + if (!exe_file->f_inode) { > + fput(exe_file); > + return ERR_PTR(-ENOENT); > + } > + > + len = security_inode_getsecurity(exe_file->f_inode, name, data, true); > + if (len < 0) > + return ERR_PTR(len); > + > + fput(exe_file); > + > + return *data; > +} > +#endif /* CONFIG_TEE_APPID_SECURITY */ > + > +#ifdef CONFIG_TEE_APPID_PATH > +static const char *tee_session_get_application_id(void **data) > +{ > + struct file *exe_file; > + char *path; > + > + *data = kzalloc(TEE_UUID_NS_NAME_SIZE, GFP_KERNEL); > + if (!*data) > + return ERR_PTR(-ENOMEM); > + > + exe_file = get_mm_exe_file(current->mm); > + if (!exe_file) { > + kfree(*data); > + return ERR_PTR(-ENOENT); > + } > + > + path = file_path(exe_file, *data, TEE_UUID_NS_NAME_SIZE); > + if (IS_ERR(path)) { > + kfree(*data); > + return path; > + } > + > + fput(exe_file); > + > + return path; > +} > +#endif /* CONFIG_TEE_APPID_PATH */ > + > +#if defined(CONFIG_TEE_APPID_PATH) || defined(CONFIG_TEE_APPID_SECURITY) > +static void tee_session_free_application_id(void *data) > +{ > + kfree(data); > +} > +#endif /* CONFIG_TEE_APPID_PATH || CONFIG_TEE_APPID_SECURITY */ > + > /** > * uuid_v5() - Calculate UUIDv5 > * @uuid: Resulting UUID > @@ -197,6 +264,8 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, > gid_t ns_grp = (gid_t)-1; > kgid_t grp = INVALID_GID; > char *name = NULL; > + void *application_id_data = NULL; > + const char *application_id = NULL; > int name_len; > int rc; > > @@ -217,6 +286,14 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, > * For TEEC_LOGIN_GROUP: > * gid=<gid> > * > + * For TEEC_LOGIN_APPLICATION: > + * app=<application id> > + * > + * For TEEC_LOGIN_USER_APPLICATION: > + * uid=<uid>:app=<application id> > + * > + * For TEEC_LOGIN_GROUP_APPLICATION: > + * gid=<gid>:app=<application id> > */ > > name = kzalloc(TEE_UUID_NS_NAME_SIZE, GFP_KERNEL); > @@ -249,6 +326,63 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, > } > break; > > + case TEE_IOCTL_LOGIN_APPLICATION: > + application_id = tee_session_get_application_id(&application_id_data); > + if (IS_ERR(application_id)) { > + rc = PTR_ERR(application_id); > + goto out_free_name; > + } > + > + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "app=%s", > + application_id); > + tee_session_free_application_id(application_id_data); > + > + if (name_len >= TEE_UUID_NS_NAME_SIZE) { > + rc = -E2BIG; > + goto out_free_name; > + } > + break; > + > + case TEE_IOCTL_LOGIN_USER_APPLICATION: > + application_id = tee_session_get_application_id(&application_id_data); > + if (IS_ERR(application_id)) { > + rc = PTR_ERR(application_id); > + goto out_free_name; > + } > + > + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "uid=%x:app=%s", > + current_euid().val, application_id); > + tee_session_free_application_id(application_id_data); > + > + if (name_len >= TEE_UUID_NS_NAME_SIZE) { > + rc = -E2BIG; > + goto out_free_name; > + } > + break; > + > + case TEE_IOCTL_LOGIN_GROUP_APPLICATION: > + memcpy(&ns_grp, connection_data, sizeof(gid_t)); > + grp = make_kgid(current_user_ns(), ns_grp); > + if (!gid_valid(grp) || !in_egroup_p(grp)) { > + rc = -EPERM; > + goto out_free_name; > + } > + > + application_id = tee_session_get_application_id(&application_id_data); > + if (IS_ERR(application_id)) { > + rc = PTR_ERR(application_id); > + goto out_free_name; > + } > + name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "gid=%x:app=%s", > + grp.val, application_id); > + tee_session_free_application_id(application_id_data); > + > + if (name_len >= TEE_UUID_NS_NAME_SIZE) { > + rc = -E2BIG; > + goto out_free_name; > + } > + break; > + > default: > rc = -EINVAL; > goto out_free_name;

5 years, 8 months

1
0
0 0

[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

5 years, 9 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 >

5 years, 9 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

5 years, 9 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

5 years, 9 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(-)

5 years, 9 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

5 years, 9 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

5 years, 9 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

5 years, 9 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

5 years, 9 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…>

5 years, 9 months

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…>

5 years, 9 months

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

5 years, 9 months

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 >

5 years, 9 months

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

5 years, 10 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

5 years, 10 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(-)

5 years, 10 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

5 years, 10 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(+)

5 years, 10 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

5 years, 10 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

5 years, 10 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

5 years, 10 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

5 years, 10 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

5 years, 10 months

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.

5 years, 11 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

5 years, 11 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

5 years, 11 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

5 years, 11 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

5 years, 11 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

5 years, 11 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

5 years, 11 months

2
2
0 0

[PATCH v2 0/2] optee: SHM handling fixes

by Volodymyr Babchuk

There are two patches that previously was mailed separatedly. Both patches fix issues found during testing the OP-TEE 3.9 release. Julien and Stefano suggested to include this patches in Xen 4.14 release, because optee support still in the preview state and those patches provide no new functionality, bugfixes only. Volodymyr Babchuk (2): optee: immediately free buffers that are released by OP-TEE optee: allow plain TMEM buffers with NULL address xen/arch/arm/tee/optee.c | 59 +++++++++++++++++++++++++++++++++++----- 1 file changed, 52 insertions(+), 7 deletions(-) -- 2.26.2

5 years, 11 months

4
10
0 0

New TrustedFirmware.org security incident process is now live

by Dan Handley

Hi all The new TrustedFirmware.org security incident process is now live. This process is described here: https://developer.trustedfirmware.org/w/collaboration/security_center/repor… Initially the process will be used for the following projects: TF-A, TF-M, OP-TEE and Mbed TLS. The security documentation for each project will be updated soon to reflect this change. If you are part of an organization that believes it should receive security vulnerability information before it is made public then please ask your relevant colleagues to register as Trusted Stakeholders as described here: https://developer.trustedfirmware.org/w/collaboration/security_center/trust… Note we prefer individuals in each organization to coordinate their registration requests with each other and to provide us with an email alias managed by your organization instead of us managing a long list of individual addresses. Best regards Dan. (on behalf of the TrustedFirmware.org security team)

5 years, 11 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE