Tee-dev

tee-dev@lists.linaro.org

1 participants
293 discussions

by Kris Kwiatkowski

Hello, I've recently been involved in producing PoC, which utilizes OP-TEE to produce proof of a secret key possession. That is used during tunnel establishment by OpenVPN. In case someone finds it interesting, for example as kind of "real-world" use case of OP-TEE, then details are described here: https://www.amongbytes.com/post/20210112-optee-openssl-engine/ and code is here: https://github.com/henrydcase/optee_eng The actual PoC used post-quantum schemes integrated into TEE OS and TF-A (secure boot). Those two points are not described really described for brevity (and probably there is low interest anyway). Kind regards, Kris

4 years, 11 months

Optee: out of memory failures in due to tee_shm_free()

by Allen Pais

Hi, I have been seeing out of memory failures due to tee_shm_free() on kexec path. This issue in discussed in length at: link: https://github.com/OP-TEE/optee_os/issues/3637 Driver: drivers/firmware/broadcom/tee_bnxt_fw.c I have tried various experiments to try and debug this issue but haven't found a fix. All I have manged is to delay the occurrence of the issue. Any pointers would be helpful. Thanks, - Allen

5 years

[PATCH] smcc: fix sign bit expansion

by Volodymyr Babchuk

Signed ARM_SMCCC_FAST_CALL value is shifted to 31'st bit. Then, it is expanded to 64 bit value, which results in 1s in higher 32 bits. This causes corrupted values in 64-bit SMC IDs and issues in buggy handlers of 32-bit calls. We need to make ARM_SMCCC_FAST_CALL unsigned long, so it would work properly on 32 bit architectures. Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk(a)epam.com> --- include/linux/arm-smccc.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h index 2d1e6cc156..7f2be23394 100644 --- a/include/linux/arm-smccc.h +++ b/include/linux/arm-smccc.h @@ -11,8 +11,8 @@ * http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html */ -#define ARM_SMCCC_STD_CALL 0 -#define ARM_SMCCC_FAST_CALL 1 +#define ARM_SMCCC_STD_CALL 0UL +#define ARM_SMCCC_FAST_CALL 1UL #define ARM_SMCCC_TYPE_SHIFT 31 #define ARM_SMCCC_SMC_32 0 -- 2.29.2

5 years

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

5 years

Persistent filesystem between reboots

by Kris Kwiatkowski

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? Kind regards, Kris

5 years

Re: [Tee-dev] virtio device for OP-TEE

by Achin Gupta

Hi Li Cheng, Let me try and elaborate a bit more. We have done some prototyping internally with the Hafnium hypervisor from Google. It began life as an EL2 Hypervisor but is now being used by the Trusted firmware project as the Hypervisor in S-EL2. In one configuration, Hafnium runs in EL2, TF-A in EL3 and OP-TEE runs in S-EL1.Hafnium and TF-A have no awareness of OP-TEE. This work is based on the FF-A specification [1]. It describes a standard set of SMCs for communication and memory management between the REE and TEE. Typically, a Hypervisor does not do anything TEE specific. It only enables communication with a TEE. So instead of a OP-TEE driver, it includes a FF-A driver so that it can inter-operate with any TEE. OP-TEE uses FF-A SMCs instead of its own for communicating with the Normal world [2]. The OP-TEE driver in Linux uses a prototype FF-A driver to talk to OP-TEE [3]. This is all very much a work in progress. Parts of this work have been up-streamed and others will be in the next 3-4 months e.g. [4]. The intent is that as long as the Hypervisor implements an FF-A driver in EL2, it should be able to talk to any TEE that also uses FF-A. We are working with OP-TEE right now. I hope this clarifies. Cheers, Achin [1] https://developer.arm.com/documentation/den0077/latest [2] https://github.com/OP-TEE/optee_os/commit/1b302ac0981603328c5d1b26300eb9328… [3] https://kernel.googlesource.com/pub/scm/linux/kernel/git/sudeep.holla/linux… [4] https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=376767 From: lchina77 <lchina77(a)163.com> Date: Monday, 23 November 2020 at 12:48 To: Achin Gupta <Achin.Gupta(a)arm.com> Cc: "tee-dev(a)lists.linaro.org" <tee-dev(a)lists.linaro.org> Subject: Re:Re: Re: [Tee-dev] virtio device for OP-TEE Hi Achin, Could you please tell me which hypervisor does your TEE-agnostic driver work on ？ What do you think about a TEE-agnostic and Hypervisor-agnostic solution for the Guest VM to access the OP-TEE? As there are many hypervisors on kinds of platforms, sometimes even close-sourced ones. Maybe the performance is a little poor, but the convenience will be very big gain. Best Regards, Li Cheng At 2020-11-23 18:07:03, "Achin Gupta" <achin.gupta(a)arm.com> wrote: >Hi Li Cheng, > >On Sat, Nov 21, 2020 at 11:25:53PM +0800, lchina77 wrote: >> >> >> >> >> >> Hi， Achin >> >> >> >> >> >> >> >> >> At 2020-11-21 02:32:47, "Achin Gupta" <Achin.Gupta(a)arm.com> wrote: >> >> >> >> >> > Hi Li Cheng, >> >> >> >> > Could you please elaborate the problem you are trying to solve? >> >> >> >> >> > Is the issue that it is difficult to integrate a OP-TEE specific driver into a Hypervisor? You would need that in any case so that the Host VM can access the OP-TEE in Secure wor> ld through the Hypervisor. >> > In the call sequence you have described, it seems that communication between the Guest VM and OP-TEE will now go via the Host VM. Could you please help me understand > how that helps. >> >> In my case, the TEE specific driver in the proprietary hypervisor ONLY supports the Host VM to access the OP-TEE, while the Guest VM cannot. So we propose the virtio solution for the Guest VM to access the OP-TEE. > >Thanks. I get it now. > >> >> > Routing Guest VM to TEE data via the Host seems quite opposite to the direction of travel where there is no trust between the Guest and Host and Hypervisor and Host as far a> s address space isolation >> > goes. The Host now gets dibs on every message between the Guest and TEE. >> >> Yes, but this is not a serious concern for us, because we are the provider of both the Host VM and Guest VM, and all the secret data resides in the OP-TEE. > >Fair enough. > >> >> > Virtio (as it stands) either requires the Guest to make its address space visible to the Host or bounce buffers in the Hypervisor. The former does not fly if address space isolatio> n is the security >> > goal (as above). The latter could run into performance issues but I am not an expert on this. >> >> >> >> > The approach we are working on is to replace a TEE specific driver in the Hypervisor with a driver that is agnostic of the TEE. This is achieved by standardising the role that the > Hypervisor plays >> > in communication between a Guest VM and the TEE. So you write the driver once and it works with all TEEs that follow the standard. >> >> Where does your TEE-agnostic driver run in ? the hypervisor or the Host VM or the Guest VM ? If the Guest VM can access OP-TEE with the help of the TEE-agnostic driver, whether the address space isolation between Host VM and Guest VM is still guaranteed ? > >The TEE-agnostic driver resides in: > >1. The Hypervisor in EL2. Its job is to, > - Enable a Guest VM to share/unshare memory with a TEE > - Forward SMC calls between a Guest VM and the TEE >2. The Guest VM. Its job is to, > - Communicate with the driver in the Hypervisor to enable communication and > memory management with the TEE as stated above > >Address space isolation between the Guest and Host VMs is the Hypervisor's job >anyways. The point of the TEE-agnostic driver is that memory management and >message forwarding can be done in a generic way in the Hypervisor. > >> >> > Hence my original question i.e. is this the problem you are looking to solve? >> >> We need to assure that the Guest VM can access the OP-TEE without the dependency on the TEE driver in the Hypervisor, it seems to be the same goal with your TEE-agnostic driver. > >Our goal is to avoid the need to integrate a TEE specific driver in the >Hypervisor and in TF-A while allowing any VM to access the TEE. > >In your case, it seems that the Hypervisor implements an access control policy >where only the Host VM can talk to the TEE. The TEE-agnostic driver will not >solve this problem as it could be subject to the same access control by the >Hypervisor. > >In any case, a more efficient approach would have been to: > >1. Share memory between the Guest VM and OP-TEE for the data path. > >2. Use the OP-TEE driver in the Host VM to issue SMCs to run OP-TEE > i.e. implement the control path. > >It looks like that is not possible either due to the restrictions imposed by the >Hypervisor. > >cheers, >Achin > >> >> >> >> >> > Cheers, >> >> > Achin >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> From: >> Tee-dev <tee-dev-bounces(a)lists.linaro.org> on behalf of lchina77 <lchina77(a)163.com> >> >> Date: Friday, 20 November 2020 at 12:53 >> >> To: "tee-dev(a)lists.linaro.org" <tee-dev(a)lists.linaro.org> >> >> Subject: [Tee-dev] virtio device for OP-TEE >> >> >> >> >> >> >> >> >> >> >> >> Hi, >> >> >> >> >> I don't know whether this is the right place to discuss, sorry for bothering. >> >> >> >> >> >> >> >> >> >> OP-TEE OS has already support virtualization, but modification to the hypervisor is also necessary. But the proprietary Hypervisors >> are close sourced and some TEE OSes are alos close-sourced, such as QSEE from QualComm. So maybe virtio-tee is an alternative solution for the Guest VM to access the OP-TEE. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> In detail, CA from Guest VM --> libteec.so (GuestVM) --> tee driver(GuestVM) -->optee_do_call_with_arg() --> invoke_fn()--> virtio-tee >> driver --> virtio-tee device(HostVM) --> libteec.so (HostVM) --> tee driver(HostVM) -->optee_do_call_with_arg() -->invoke_fn() --> TEEOS. >> >> >> >> >> >> >> >> >> >> >> >> >> >> I think the virtio-tee device must transfer the RPC to the virtio-tee driver in the GuestVM, then to the tee-supplicant in the GuestVM, >> in order to load the TAs in the GuestVM. >> >> >> >> >> >> >> >> >> >> In the HostVM, the tee-supplicant accesses the tee-driver through /dev/teepriv0, and the virtio-tee device accesses the tee-driver through >> /dev/teepriv1, So I wonder how the HostVM tee driver can dispatch the RPC from OP-TEE to the correct receiver , tee-supplicant or the virtio-tee device? >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Best Regards, >> >> >> >> >> Li Cheng >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 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. >> >> >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. 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, 2 months

virtio device for OP-TEE

by lchina77

Hi, I don't know whether this is the right place to discuss, sorry for bothering. OP-TEE OS has already support virtualization, but modification to the hypervisor is also necessary. But the proprietary Hypervisors are close sourced and some TEE OSes are alos close-sourced, such as QSEE from QualComm. So maybe virtio-tee is an alternative solution for the Guest VM to access the OP-TEE. In detail, CA from Guest VM --> libteec.so (GuestVM) --> tee driver(GuestVM) -->optee_do_call_with_arg() --> invoke_fn()--> virtio-tee driver --> virtio-tee device(HostVM) --> libteec.so (HostVM) --> tee driver(HostVM) -->optee_do_call_with_arg() -->invoke_fn() --> TEEOS. I think the virtio-tee device must transfer the RPC to the virtio-tee driver in the GuestVM, then to the tee-supplicant in the GuestVM, in order to load the TAs in the GuestVM. In the HostVM, the tee-supplicant accesses the tee-driver through /dev/teepriv0, and the virtio-tee device accesses the tee-driver through /dev/teepriv1, So I wonder how the HostVM tee driver can dispatch the RPC from OP-TEE to the correct receiver , tee-supplicant or the virtio-tee device? Best Regards, Li Cheng

5 years, 2 months

[PATCH] arm: optee: don't print warning about "wrong" RPC buffer

by Volodymyr Babchuk

OP-TEE mediator tracks cookie value for a last buffer which was requested by OP-TEE. This tracked value serves one important purpose: if OP-TEE wants to request another buffer, we know that it finished importing previous one and we can free page list associated with it. Also, we had false premise that OP_TEE will free requested buffers in reversed order. So we checked rpc_data_cookie during handling OPTEE_RPC_CMD_SHM_FREE call and printed warning if cookie of buffer which is requested to be freed differs from last allocated one. During testing RPMB FS services I discovered, that RPMB code frees request and response buffers in the same order is it allocated them. And this is perfectly fine, actually. So, we are removing mentioned warning message in Xen, as it is perfectly normal to free buffers in arbitrary order. Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk(a)epam.com> --- xen/arch/arm/tee/optee.c | 20 +------------------- 1 file changed, 1 insertion(+), 19 deletions(-) diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c index 8a39fe33b0..ee85359742 100644 --- a/xen/arch/arm/tee/optee.c +++ b/xen/arch/arm/tee/optee.c @@ -1127,25 +1127,7 @@ static int handle_rpc_return(struct optee_domain *ctx, */ if ( shm_rpc->xen_arg->cmd == OPTEE_RPC_CMD_SHM_FREE ) { - uint64_t cookie = shm_rpc->xen_arg->params[0].u.value.b; - - free_optee_shm_buf(ctx, cookie); - - /* - * OP-TEE asks to free the buffer, but this is not the same - * buffer we previously allocated for it. While nothing - * prevents OP-TEE from asking this, it is the strange - * situation. This may or may not be caused by a bug in - * OP-TEE or mediator. But is better to print warning. - */ - if ( call->rpc_data_cookie && call->rpc_data_cookie != cookie ) - { - gprintk(XENLOG_ERR, - "Saved RPC cookie does not corresponds to OP-TEE's (%"PRIx64" != %"PRIx64")\n", - call->rpc_data_cookie, cookie); - - WARN(); - } + free_optee_shm_buf(ctx, shm_rpc->xen_arg->params[0].u.value.b); call->rpc_data_cookie = 0; } unmap_domain_page(shm_rpc->xen_arg); -- 2.27.0

5 years, 3 months

(no subject)

by Pierre Peiffer

5 years, 3 months

[PATCH v1] tee: optee: Use UUID API for exporting the UUID

by Andy Shevchenko

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. Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> --- drivers/tee/optee/device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tee/optee/device.c b/drivers/tee/optee/device.c index e3a148521ec1d..2ecc6993f48bb 100644 --- a/drivers/tee/optee/device.c +++ b/drivers/tee/optee/device.c @@ -107,7 +107,7 @@ int optee_enumerate_devices(void) return -ENODEV; /* Open session with device enumeration pseudo TA */ - memcpy(sess_arg.uuid, pta_uuid.b, TEE_IOCTL_UUID_LEN); + export_uuid(sess_arg.uuid, &pta_uuid); sess_arg.clnt_login = TEE_IOCTL_LOGIN_PUBLIC; sess_arg.num_params = 0; -- 2.26.1

5 years, 3 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Tee-dev