Tee-dev

tee-dev@lists.linaro.org

291 discussions

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.

8 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

8 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.

8 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

8 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

8 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

8 years, 2 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

8 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

8 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

8 years, 4 months

are shared buffers physically contiguous?

by Sören Brinkmann

Hi, I am playing with OP-TEE on ZynqMP and am working on a proof of concept for programming the FPGA from Linux through a TA in OP-TEE. The first questions I had where regarding how to access the necessary HW and I found: https://github.com/OP-TEE/optee_os/issues/404 https://lists.linaro.org/pipermail/tee-dev/2015-August/000160.html I guess a user-TA memory is completely isolated and hence the pointer to use a static TA? I actually got that part working and added a static TA that takes a temporal memref from the normal world. I.e. the flow is like this: 1. user space app opens bitstream file and does any kind of pre-processing that may be required 2. user-space application mmaps the bitstream file 3. user-space app populates a TEEC_Operation struct with a TEEC_TEMP_INPUT argument that holds the mmap address and the size of the file 4. user-space invokes TA 5. TA does some sanity checking, ... 6. TA looks up the physical address of the bitstream and flushes the cache 7. TA programs a DMA to transfer the bitstream into the FPGA This process does actually work, but I'm not sure how much luck is involved. The bitstream file for the device I'm working with is ca. 10MB large and for the DMA to work it needs to be present in memory in a physically contiguous address range (it could probably be programmed in chunks, but if not necessary I'd avoid going there). That rose the question: Is the data the TA works with guaranteed to be present in a physically continuous block? And if not, was there an easy way to achieve that? Thanks, Sören

8 years, 4 months

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Tee-dev