- OP-TEE - lists.trustedfirmware.org

Re: [Tee-dev] Persistent filesystem between reboots

by Jens Wiklander

Hi Kris, On Thu, Jan 14, 2021 at 1:37 PM Kris Kwiatkowski <kris(a)amongbytes.com> wrote: > > Hi, > > I'm using HiKey 960 for my research project. I've noticed that > filesystem is not persistent between reboot. Is there a way > to change it, so that any change to file in the /etc will be > persistent? There's no easy way of doing that with our repo based builds I'm aware of. The purpose of our (OP-TEE team) builds is in principle to be able to execute xtest and other test programs. For this use case it's actually an advantage to start from a clean state each time. In your case I think you need to pick a suitable distribution and update it as needed to support OP-TEE. It could be worth looking at Yocto as there is some OP-TEE support already. Here's a short list of what's needed: 1. TF-A compiled with OP-TEE support (dispatcher in BL31 and load support in bl2) 2. OP-TEE included in the FIP loaded by TF-A 3. OP-TEE nodes in device tree 4. OP-TEE driver enabled in the kernel (recent upstream kernel should work in most cases) 5. tee-supplicant and libteec.so installed in the file system 6. tee-supplicant started With that in place you should be good to go. Cheers, Jens

5 years, 4 months

1
0
0 0

Preparing for OP-TEE 3.12.0

by Joakim Bech

[BCC all OP-TEE maintainers] Hi OP-TEE maintainers & contributors, OP-TEE v3.12.0 is scheduled to be released at 2021-01-15. 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 comments is https://github.com/OP-TEE/optee_os/pull/4291. As usual, we will create a release candidate tag one week before the release date for final testing. In addition to that you can find some additional information related to releases here: https://optee.readthedocs.io/en/latest/general/releases.html Regards, Joakim

5 years, 4 months

1
1
0 0

FYI - Open Source Project Criticality Score

by Jerome Forissier

Hi, I just wanted to share that the Open Source Security Foundation (OSSF, [1]) has recently developed a tool called the Open Source Project Criticality Score (Beta) [2]. As of December 24, 2020, OP-TEE OS is number 39 in the top 200 C language projects on GitHub, ranked by criticality score. Not bad I think. [1] https://openssf.org/ [2] https://github.com/ossf/criticality_score [3] https://commondatastorage.googleapis.com/ossf-criticality-score/index.html (c_top_200.csv) Regards, -- Jerome

5 years, 4 months

1
0
0 0

Re: [PATCH] tee: optee: replace might_sleep with cond_resched

by Sumit Garg

On Fri, 25 Sept 2020 at 12:29, Jens Wiklander via OP-TEE <op-tee(a)lists.trustedfirmware.org> wrote: > > On Fri, Sep 18, 2020 at 7:45 PM Rouven Czerwinski > <r.czerwinski(a)pengutronix.de> wrote: > > > > 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(); > > This looks OK to me. But I'd prefer if someone else could confirm this too. > Tested-by: Sumit Garg <sumit.garg(a)linaro.org> -Sumit > Thanks, > Jens > > > param.a0 = res.a0; > > param.a1 = res.a1; > > param.a2 = res.a2; > > -- > > 2.28.0 > >

5 years, 4 months

2
1
0 0

Re: Mapping an arbitrary SDRAM block outside TZDRAM

by Jens Wiklander

Hi Robert, Comments below. On Mon, Dec 28, 2020 at 7:49 PM Robert Delien via OP-TEE <op-tee(a)lists.trustedfirmware.org> wrote: > > Hi, > > As discussed earlier, our application requires secured display contents and > is using a secure frame buffer. > > Now to transit from U-Boot to Op-tee as smoothly as possible, I would like > to copy the contents from the U-Boot frame buffer into the Optee frame > buffer upon LCD driver initialisation. > > The U-Boot frame buffer address is calculated at run time and I haven't > found a hand-off mechanism, but the physical address can be easily read > from the LCDIF peripheral's registers. Unfortunately, no MMU mapping is > present per default for this physical address outside the TZDRAM area. > > Is it possible to temporarily map this rather arbitrary non-secure physical > DDR address outside TZDRAM, so I can access it through a virtual address? > Preferably in a way that I can also remove this mapping after copying the > frame buffer? Yes, it's actually easier than one might first imagine. I assume you will interact with OP-TEE via a Pseudo TA. This framebuffer is normal non-secure DDR from OP-TEE point of view, so it should be possible to just supply it as a memref parameter when invoking the PTA. Cheers, Jens

5 years, 4 months

1
0
0 0

Mapping an arbitrary SDRAM block outside TZDRAM

by Robert Delien

Hi, As discussed earlier, our application requires secured display contents and is using a secure frame buffer. Now to transit from U-Boot to Op-tee as smoothly as possible, I would like to copy the contents from the U-Boot frame buffer into the Optee frame buffer upon LCD driver initialisation. The U-Boot frame buffer address is calculated at run time and I haven't found a hand-off mechanism, but the physical address can be easily read from the LCDIF peripheral's registers. Unfortunately, no MMU mapping is present per default for this physical address outside the TZDRAM area. Is it possible to temporarily map this rather arbitrary non-secure physical DDR address outside TZDRAM, so I can access it through a virtual address? Preferably in a way that I can also remove this mapping after copying the frame buffer? Thanks in advance; Your help is highly appreciated. With kind regards, Robert. -- DISCLAIMER De informatie, verzonden in of met dit e-mailbericht, is vertrouwelijk en uitsluitend voor de geadresseerde(n) bestemd. Het gebruik van de informatie in dit bericht, de openbaarmaking, vermenigvuldiging, verspreiding en|of verstrekking daarvan aan derden is niet toegestaan. Gebruik van deze informatie door anderen dan geadresseerde(n) is strikt verboden. Aan deze informatie kunnen geen rechten worden ontleend. U wordt verzocht bij onjuiste adressering de afzender direct te informeren door het bericht te retourneren en het bericht uit uw computersysteem te verwijderen.

5 years, 4 months

1
0
0 0

Re: [PATCH] tee: client UUID: Skip REE kernel login method as well

by Elvira Khabirova

On Tue, 22 Dec 2020 08:50:56 +0000 Vesa Jääskeläinen via OP-TEE <op-tee(a)lists.trustedfirmware.org> wrote: > Hi, > > On 2020-10-08 08:53, Jens Wiklander wrote: > > Hi Sumit, > > > > On Wed, Oct 7, 2020 at 11:27 AM Sumit Garg <sumit.garg(a)linaro.org> wrote: > >> > >> Hi Jens, > >> > >> On Thu, 17 Sep 2020 at 19:10, Sumit Garg <sumit.garg(a)linaro.org> wrote: > >>> > >>> Since the addition of session's client UUID generation via commit [1], > >>> login via REE kernel method was disallowed. So fix that via passing > >>> nill UUID in case of TEE_IOCTL_LOGIN_REE_KERNEL method as well. > >>> > >>> Fixes: e33bcbab16d1 ("tee: add support for session's client UUID generation") [1] > >>> Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> > >>> --- > >>> drivers/tee/tee_core.c | 3 ++- > >>> 1 file changed, 2 insertions(+), 1 deletion(-) > >>> > >> > >> Would you like to pick up this fix? > > > > Thanks for the reminder. > > This looks good to me. I'll pick up this unless someone objects. > > Vesa, does this look good to you too? > > > > Cheers, > > Jens > > Sorry I have been away for a while from the mailing list. > > It seems that this is merged -- only thing that came to my mind with > this is that: > > If we have some kernel protected keys or so -- should we have separate > client UUID for kernel operations. > > Like when TEE_IOCTL_LOGIN_REE_KERNEL is given then client UUID would be > generated for "kernel". > > This way we can make sure that kernel owned keys stays for kernel. Nil > UUID is kinda reserved for public login. Isn't this unnecessary? According to the TEE Internal Core API Specification, TEE_Identity, a data type that "defines the full identity of a Client", consists of a UUID *and* one of the TEE_LOGIN_XXX constants. Therefore, TEE_LOGIN_PUBLIC with a nil UUID is a different client than TEE_LOGIN_REE_KERNEL with a nil UUID. > Thanks, > Vesa Jääskeläinen > > > > >> > >> -Sumit > >> > >>> diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c > >>> index 64637e0..2f6199e 100644 > >>> --- a/drivers/tee/tee_core.c > >>> +++ b/drivers/tee/tee_core.c > >>> @@ -200,7 +200,8 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, > >>> int name_len; > >>> int rc; > >>> > >>> - if (connection_method == TEE_IOCTL_LOGIN_PUBLIC) { > >>> + if (connection_method == TEE_IOCTL_LOGIN_PUBLIC || > >>> + connection_method == TEE_IOCTL_LOGIN_REE_KERNEL) { > >>> /* Nil UUID to be passed to TEE environment */ > >>> uuid_copy(uuid, &uuid_null); > >>> return 0; > >>> -- > >>> 2.7.4 > >>> >

5 years, 4 months

2
1
0 0

[PATCH v4] 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> --- Changes in v4: - Fix potential exe_file leaks. 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..a72b8c19253a 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); + fput(exe_file); + + if (len < 0) + return ERR_PTR(len); + + 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); + fput(exe_file); + + if (IS_ERR(path)) { + kfree(*data); + return path; + } + + 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, 4 months

2
1
0 0

[PATCH] tee: client UUID: Skip REE kernel login method as well

by Sumit Garg

Since the addition of session's client UUID generation via commit [1], login via REE kernel method was disallowed. So fix that via passing nill UUID in case of TEE_IOCTL_LOGIN_REE_KERNEL method as well. Fixes: e33bcbab16d1 ("tee: add support for session's client UUID generation") [1] Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> --- drivers/tee/tee_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index 64637e0..2f6199e 100644 --- a/drivers/tee/tee_core.c +++ b/drivers/tee/tee_core.c @@ -200,7 +200,8 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, int name_len; int rc; - if (connection_method == TEE_IOCTL_LOGIN_PUBLIC) { + if (connection_method == TEE_IOCTL_LOGIN_PUBLIC || + connection_method == TEE_IOCTL_LOGIN_REE_KERNEL) { /* Nil UUID to be passed to TEE environment */ uuid_copy(uuid, &uuid_null); return 0; -- 2.7.4

5 years, 4 months

3
3
0 0

Linaro OP-TEE Contributions meeting December 2020

by Joakim Bech

Hi, LOC monthly meeting is planned to take place Monday December 21st(a)16.00 (UTC+1). This time it will just be an open discussion, since we have no planned presentation/talks otherwise. So feel free to suggest topics you'd like to discuss (by replying to this email or write it directly in the meeting notes). The issue we had last time with Zoom ID not valid any longer should have been fixed now. Note that the fix involved generating a new meeting ID, which means that the old connection information is no longer valid. It's also worth mentioning that all upcoming meetings can now be found at the TrustedFirmware calendar (url is below). Meeting details: --------------- Date/time: Monday December 21st(a)16.00 (UTC+1) https://everytimezone.com/s/f5c1ffe4 Connection details: https://www.trustedfirmware.org/meetings/ 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, 5 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE