Tee-dev

tee-dev@lists.linaro.org

292 discussions

Re: [Tee-dev] Introduce PSCI for OP-TEE ARM32

by Dan Handley

Hi Peng I've just joined this mailing list after being pointed to this thread. As ARM Trusted Firmware (TF) tech lead, I strongly encourage option 3, assuming you mean using the standalone AArch32 PSCI library provided in the upstream TF code base. If by Option 1 you mean a full port of TF to AArch32, we consider this not feasible due to the architectural limitations that Jens described in his mail earlier. These limitations are also described in the presentation I gave at the last Linaro Connect in Las Vegas. Option 2 is going to be equally challenging. Apart from being very difficult, there would be very tight coupling between U-Boot and OP-TEE, which may not be desirable for OP-TEE. It's true that TF AArch32 support is currently focussed on ARMv8-A AArch32 support, but adding support for ARMv7-A is not a major task. We just need some help from the TF community to implement this. In terms of implementing Option 3, Joakim mentioned looking into this early next year. We too were thinking of looking into this around the same time. I echo his comments around you helping with this if you want. We (ARM) are happy to provide consultancy. In any case, we should agree among ourselves what the plan is before anyone embarks on this work! Regards Dan. On 11 November 2016 at 10:21, Peng Fan <peng.fan at nxp.com<https://lists.linaro.org/mailman/listinfo/tee-dev>> wrote: > Hi, > > > I am trying to implement TEE and support Linux power features. > > > > There are several options to include power features and TEE > > 1. ATFW for ARM32. > > 2. Develop runtime service code in U-Boot like ATFW. > > 3. Integrate PSCI ARM32 in OP-TEE. > > > > Option1, ATFW seems not support ARM32, such as A9/A7. And the AArch32 > support, I think(not sure), is not for legacy ARM32 cores. > > Option2, requires some efforts. And needs some wrap code between uboot > monitor code and TEE and Linux. > > Actually I prefer option3, and secondary cores can be booted up with psci in > OP-TEE. Before I > > put more efforts, I would like to ask whether this is acceptable from OP-TEE > community. > > > > Thanks, > > Peng. > 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.

9 years

Introduce PSCI for OP-TEE ARM32

by Peng Fan

Hi, I am trying to implement TEE and support Linux power features. There are several options to include power features and TEE 1. ATFW for ARM32. 2. Develop runtime service code in U-Boot like ATFW. 3. Integrate PSCI ARM32 in OP-TEE. Option1, ATFW seems not support ARM32, such as A9/A7. And the AArch32 support, I think(not sure), is not for legacy ARM32 cores. Option2, requires some efforts. And needs some wrap code between uboot monitor code and TEE and Linux. Actually I prefer option3, and secondary cores can be booted up with psci in OP-TEE. Before I put more efforts, I would like to ask whether this is acceptable from OP-TEE community. Thanks, Peng.

9 years

[libtomcrypt] Issue and patch in TEE adaptation for clearing big numbers

by Emmanuel MICHEL

Hello all, First time i propose a patch to OP-TEE and i do not know the process. I try this channel. I filled a ticket on github with all the info: https://github.com/OP-TEE/optee_os/issues/1168 Best regards Manu Hello all, It seems there is an issue in the TEE adaptation of the libtomcrypt for clearing big numbers. Issue could be seen in the sequence: TEE_AllocateTransientObject TEE_ResetTransientObject TEE_PopulateTransientObject where TEE_ResetTransientObject clears (and not free) the object. Clear mean zero the data. If this object is a big number, the leaf function is: static void bn_clear(struct bignum *s) { struct mpa_numbase_struct *bn = (struct mpa_numbase_struct *)s; memset(bn, 0, bn->alloc); } corresponding to static struct bignum *bn_allocate(size_t size_bits) { .. bn->alloc = sz - MPA_NUMBASE_METADATA_SIZE_IN_U32 * sizeof(uint32_t); .. } The underlying structure describing struct bignum is in lib/libmpa/include/mpalib.h: typedef struct mpa_numbase_struct { mpa_asize_t alloc; mpa_usize_t size; mpa_word_t d[]; } mpa_num_base; As we can see, memset fills with zero not only the data, but the metadata and the begin of the datas, instead of zero only the whole data. Based on OP-TEE 2.2.0, even with the last commit 36d5a31<https://github.com/OP-TEE/optee_os/commit/36d5a31387f01357077ca74444f3fd5ce…>, a proposed patch: diff --git a/core/lib/libtomcrypt/src/tee_ltc_provider.c b/core/lib/libtomcrypt/src/tee_ltc_provider.c index fda9454..69620c6 100644 --- a/core/lib/libtomcrypt/src/tee_ltc_provider.c +++ b/core/lib/libtomcrypt/src/tee_ltc_provider.c @@ -691,7 +691,7 @@ static void bn_clear(struct bignum *s) { struct mpa_numbase_struct *bn = (struct mpa_numbase_struct *)s; - memset(bn, 0, bn->alloc); + memset(bn->d, 0, bn->alloc); } Note: mpa_numbase_struct.size is never set in this case, but it is not part of this ticket. Best regards Manu

9 years

OPtee Porting.

by Siva Krishna Reddy Yaramala

Hi tee-dev experts, I am trying to port optee to our custom arm platform.I have gone through some documents but i didn't get a clear picture on this. I have some concerns like below to clarify: 1. Is arm-trusted firmware really required in the optee bringup? 2. Can we boot optee directly from u-boot without arm-trusted firmware? 3. Is there any good documentation for optee porting for custom arm soc? 4. Is there any specific hardware requirements to run optee? 5. Can you please share me , if anybody have boot flow of optee? I appreciate your comments. Thanks in advance.

9 years, 1 month

Optee_test suite

by Mohan V

Hi, I am trying to patch/port the GP compliance test suite (v1.8.0) to the latest Optee_test suite (commit-id: ac7e47c73637b0d34c6c45628ee94ff9a62a7e0e) and following the procedure as mentioned in http://www.linaro.org/blog/core-dump/testing-a-trusted-execution-environmen… When I did "make patch", I got errors related to unable to patch the files. I commented some in Makefile as some of the patches were not valid. Then managed to get "xalan" working and was able to generate the xtest host files and TA files. But the generated file xtest_9000.c is not correct. None of the tests have OpenSession call and directly a call to InvokeCommand. *Xalan command used:* 1. XalanTransform TEE_Crypto_API.xml TEE_Crypto_API.xsl xtest_9000.c 2. java -jar ~/xalan.jar -in TEE_Crypto_API.xml -xsl TEE_Crypto_API.xsl -out xtest_9000.c Can you please let me know if the "package" folder in optee_test suite needs update for latest GP test suite? Thanks, Mohan

9 years, 1 month

Re: [Tee-dev] Questions about OP-TEE and Raspberry Pi 3

by Joakim Bech

Hi Christopher, On 8 September 2016 at 17:27, LAMBERT Christopher <christopher.lambert@ mythalesgroup.com> wrote: > Hi Joakim, > > I've seen that the Juno board may be a solution for what I want to do. > Could you confirm that? > Thanks, > Sorry for the delayed reply. Regarding a recommended board(s). It depends on what you are trying to achieve. If you're interested in learning about TEE and how to create TA's, but don't want to spend too much money. Then I'd say, go for HiKey or Raspberry Pi. I haven't tried the Xilinx and Freescale boards myself that are supported [1], but I don't think they are also good alternatives. You can go for Juno also, it's quite a bit more pricey compared to the other development boards. If you are interested in making a secure product for the consumer market, then you're in a much tougher situation, since the "development" boards aren't sufficient. The major issue is that you have no ability to get root of trust and therefore no chain of trust on those devices. I.e, the soc vendor usually don't provide tools and/or documentation how to blow fuses etc. Based on your previous reply it doesn't sound like you are planning to make a secure consumer device. Everything you mention there can be achieved on the HiKey board if you forget about the root of trust. Stub the root key with a self signed key and then you can implement and play with secure boot in the rest of the boot stages. What's been described here [2] (not yet merged) is something you should be able to do on HiKey also (basically any device that uses ARM-TF and OP-TEE or any other TEE for that matter would work). You could probably achieve almost the same with RPi3, but the RPi3 boot with OP-TEE is a bit odd, so I would not recommend that in first place. And you don't have to deal with low level code at all if you don't want too. In fact, if you just would like to learn how to write and run Trusted Applications, play with secure storage etc. Then you don't need any hardware. You can just download QEMU and run everything on your local PC (boot, secure OS, monitor, Linux kernel, client application user space and Trusted Applications ... all that works in QEMU). Setting up QEMU on a Linux machine is roughly typing 6-10 lines in bash, all stated here [4] (don't forget about to apt-get the prerequisites, see section 4) and 45 minutes later (downloading Linux kernel, toolchains is the majority of the time) you have all ready to be used. So, summary: 1. QEMU 2. Hikey 3. Evaluate if the Xilinx or Freescale boards would be good enough (there are email addresses to the maintainers for those here [3] in case you have questions regarding the device they maintain) 4. Juno if you have money to spend 5. RPi3. [1] https://github.com/OP-TEE/optee_os#3-platforms-supported [2] https://github.com/OP-TEE/optee_os/pull/1037 [3] https://github.com/OP-TEE/optee_os/blob/master/MAINTAINERS.md [4] https://github.com/OP-TEE/optee_os#5-repo-manifests Regards, Joakim

9 years, 2 months

Questions about OP-TEE and Raspberry Pi 3

by LAMBERT Christopher

Hello, I'm very interested in OP-TEE for Raspberry Pi 3. I've read https://github.com/OP-TEE/optee_os/blob/master/documentation/rpi3.md, especially the disclaimer part. This part is not really clear to me:"Although the Raspberry Pi3 processor provides ARM TrustZone exception states, the mechanisms and hardware required to implement secure boot, memory, peripherals or other secure functions are not available" What does it mean? Is it possible to have a secure boot with Raspberry Pi 3? Thanks. Best regards, Christopher Lambert

9 years, 3 months

Re: [Tee-dev] [OP-TEE/optee_os] [Discussion] Virtualization and OP-TEE (#1019)

by Jens Wiklander

Hi, On Thu, Aug 25, 2016 at 7:51 PM, Volodymyr Babchuk <notifications(a)github.com > wrote: > Hello. > > I didn't find any mention of optee mailing list, so, perhaps issue tracker > is the best place to discuss the matter. > We have tee-dev(a)lists.linaro.org, I've added it in CC, we can continue the discussion there if you wish. > XEN hypervisor is now ported on ARM and our company is working > <https://www.xenproject.org/component/allvideoshare/video/globallogic-xen-an…> > to provide virtualization solutions to different customers. Some customers > also want to use TEE in theirs projects. > And there arises topic of interaction between hypervisor and OP-TEE > kernel. I have made small PoC > <https://github.com/lorc/xen/commits/staging-4.7> to show that hypervisor > and op-tee can live together. Long things short, I am able to run xtest on > different guest VMs (virtual machines) (but not simulatelly). Also, you can > kill VM during its interaction with secure world and this will be handled > correctly: RPC's will be ended with error, opened sessions will be closed. > All handling is done in hypervisor. I didn't made any changes to any parts > of OP-TEE. > Wow, that's cool! > But it is merely PoC, and there are many questions that need to be > answered: > > - Synchronization. This is the biggest problem at this moment. There > will be different wait queues in different VMs and they just know nothing > about each other. Suppose, that VM1's call should wait on wait queue till > VM2 releases mutex. Currently, there are no way to signal to VM1 that > waiting is finished. VM2 will signal only to its own wait queue. Probably > we need another mechanism for signaling to Normal Word. Can it be software > interrupt for example? > > Yes, we really need a software interrupt for this. Unfortunately all 8 non-secure software interrupts in Linux ARMv7 kernel are taken. The recommendation from ARM is to configure the GIC with 8 non-secure software interrupts so we should probably stick with that. This means that we need to find a way to free one non-secure software interrupt to be able to reassign it for secure world use. As PoC we could of course configure more non-secure SGIs but I'm not sure it will be useful beyond just PoC. > > - High-level Isolation between VM's data. OP-TEE need to track which > shared buffer or session belong to which VM. SMC Call Convention states > that VM ID should be passed in r7. I have seen that optee kernel stores it > in mutex metadata. But currently there are no use for it. Probably we can > tag every session with it. It is not big deal as for me. > > > - TA isolation. Suppose that multiple VMs want to open session to the > same TA. Should we ensure that TA code will not leak any sensitive data > between VMs? For example, we can run multiple instances of the same TA, one > instance for each VM. > > Yes for different VMs, sessions and contexts of TAs should be completely isolated. That means for instance that single instance TAs will be single instance per VM. We'll likely only have static TAs as true single instance TAs. > > - VM termination. VM can die at any moment. Even during RPC. It can > leave opened sessions. My PoC handles this, but in a somewhat crude way. > Should we teach OP-TEE to handle this in a more civilized way? For example, > hypervisor signals that VM is closed and OP-TEE kernel goes through all > opened sessions and terminates them. Also it kills threads assigned to that > VM and then unlocks locked mutexes. > > Yes, OP-TEE should assist here. > > - Shared memory. Currently allocations from SHM are done by Normal > World. But there are only one region. My PoC splits this region into 4 > parts and assign every part to different VM. In this way every VM has > isolated SHM region. But only three VMs are supported (one region is > assigned to hypervisor itself). And every VM can use maximum 1/4 of SHM. > That's not very convenient. Probably, OPTEE (and hypervisor) should > allocate SHM on request. > > The best would be if we could avoid using this SHM pool at all and instead use normal memory allocated with vmalloc() or from user space as shared memory instead. It is a bit complicated to implement as we need to redesign how we handle shared memory objects in OP-TEE, but it would solve this problem and also other problems. Thanks, Jens

9 years, 3 months

Measuring clock frequency

by machiry aravind

Hi all, I want to measure clock frequency in secure world. I am using the function: read_cntfrq (https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/include/arm32.…) to get it. On Hikey, The value I get is: 1.2MHz, is it scaled down or this is the actual frequency? Thank You, Aravind

9 years, 3 months

Question About TEE Session Management

by thomas m zeng

Hi, We have some use cases to evaluate against Gen TEE interface framework. 1. Does a TEE using the Gen TEE interface, say OPTEE, support sessions between NS world and a kernel service in SEL1? -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

9 years, 4 months

← Newer
1
...
23
24
25
26
27
28
29
30
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Tee-dev