- OP-TEE - lists.trustedfirmware.org

Linaro OP-TEE Contributions meeting January 2021

by Joakim Bech

Hi, LOC monthly meeting is planned to take place Thursday January 28th(a)16.00 (UTC+1). This time we have two guest speakers, with two different topics. - Clément Faure (NXP): HW crypto accelerator integration with crypto framework in OP-TEE - Sumit Garg (Linaro): TEE based Trusted Keys This might take the whole meeting, but feel free to suggest topics you'd like to discuss otherwise (by replying to this email or write it directly in the meeting notes). Meeting details: --------------- Date/time: Thursday January 28th(a)16.00 (UTC+1) https://everytimezone.com/s/c43ea835 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

4 years, 4 months

1
0
0 0

[PATCH] drivers: optee: use flexible-array member instead of zero-length array

by Tian Tao

Use flexible-array member introduced in C99 instead of zero-length array. Most of zero-length array was already taken care in previous patch [1]. Now modified few more cases which were not handled earlier. [1]. https://patchwork.kernel.org/patch/11394197/ Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> --- drivers/tee/optee/optee_msg.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h index 7b2d919..b1f1e90 100644 --- a/drivers/tee/optee/optee_msg.h +++ b/drivers/tee/optee/optee_msg.h @@ -199,7 +199,7 @@ struct optee_msg_arg { u32 num_params; /* num_params tells the actual number of element in params */ - struct optee_msg_param params[0]; + struct optee_msg_param params[]; }; /** -- 2.7.4

4 years, 4 months

2
1
0 0

Re: [Tee-dev] Persistent filesystem between reboots

by Joakim Bech

On Fri, Jan 15, 2021 at 12:50:27PM +0000, Jens Wiklander via OP-TEE wrote: > 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. > You can also give NFS a try, I tend to use that myself when playing with OP-TEE and Raspberry Pi3. I.e., I basically just untar the rootfs created by our setup into a folder that is exposed via NFS. Then in addition to that I have a couple of helper scripts that copies the files Jens mentioned below into that NFS folder when I need to update with changed files (TA's, OP-TEE libs etc). > 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 -- Regards, Joakim

4 years, 4 months

1
0
0 0

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

4 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

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

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

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

4 years, 5 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.

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

4 years, 5 months

2
1
0 0

2025

2024

2023

2022

2021

2020

OP-TEE