Tee-dev November 2016

tee-dev@lists.linaro.org

11 participants
8 discussions

by Ajith Kumar Kumsi

Hi, I am new to OP-TEE. I would like to compile and port OP-Tee to a new platform which has armv7-a (Cortex-a5) I am using "arm-none-eabi-" tool chain for cross compiling. Please guide me on how to build OP-Tee to the new platform. Please suggest me the steps to be followed for porting OP-Tee on armv7-a Regards, Ajith

9 years

OP-TEE supports only SMP system ?

by Sandeep Tripathy

Hi, I see explicit checks for OPTEE_SMC_NSEC_CAP_UNIPROCESSOR. What is the limitation with uniprocessor system. Thanks Sandeep

9 years, 1 month

Reworking MM in OP-TEE

by Volodymyr Babchuk

Hello, There was discussion that started on github (https://github.com/OP-TEE/optee_os/issues/1019) and then continued in this mailing list. We discussed how OP-TEE can interact with virtualization and came to conclusion that one of tasks is to rework shared memory mechanism. So I want to discuss my vision on this topic. Currently shared buffer is carved out from RAM by some higher powers and presented to OP-TEE. OP-TEE informs Normal World about its location. And then OP-TEE uses Normal World's allocator to allocate buffers for various needs. This approach has two drawbacks: shared region size is limited and it is wastes memory space when it is not used. On most platforms it have size of 1 megabyte which is not enough to run GP tests (according to comments in board files). We have agreed that we don't need this shared carveout at all. This region is unsecure by definition, so Normal World can allocate in anywhere it wishes and then just pass PAs to OP-TEE. I already did most of the work on kernel side. You can check it there: https://github.com/lorc/linux/tree/optee-new-shm This code still needs to be tidied up, possibly some caching should be added. I also hacked OP-TEE core to make it work. So I want to discuss proper changes to OP-TEE memory management subsystem. Main requirements are: - MM should be dynamic: we can add and remove mappings in runtime. - There can be arbitrary number of maps. - Every map should be associated with guest virtual machine, so we can clean up easily when one of Normal Worlds dies. - Preserve existing APIs if possible. I don't want to rework all MM API calls and you probably don't want to review this :) Here is how I see this: there will be two types of mappings: static and dynamic. Most of the areas will be left static, but the area for shared memory and probably the area for device IO will be made dynamic. Actually I borrowed this idea from Linux's vmalloc.c. Lets take SHM as an example: There will be region in virtual address space for SHM. But it will not be backed by any physical memory at the start. When OP-TEE needs shared buffer it issues RPC call to Normal World, Normal World provides physical page(s). OP-TEE then allocates part of SHM virtual space and maps there pages provided by Normal World. When Normal World allocates SHM on its own, it calls Secure World with `OPTEE_SMC_ADD_SHM_BUFFER` where it provides list of pages. OP-TEE then maps pages in the same way as in previous case. There will be complementary functions and SMC calls to unmap shared buffer and free allocated VA space. We will need some some allocator to track areas in SHM VA space. I plan to use rb-tree allocator like it is used in vmalloc.c. Probably we will need second rb-tree with PA's to speed up `phys_to_virt` lookups. For every allocated area in VA space we will hold virtual machine id, so we can free this region when virtual machine dies. APIs in core_memprot.h will be preserved. There just will be another handling for SHM region cases. Also corresponding changes to MMU drivers should be done. We need to be able to map/unmap individual pages. The same mechanism can be used for memory mapped peripherals, so device drivers can use plain old `ioremap` to gain access to device registers. I hope this is not overengineered :) I will appreciate any comments on this, especially if I missed something. -- WBR Volodymyr Babchuk aka lorc [+380976646013] mailto: vlad.babchuk(a)gmail.com

9 years, 1 month

Re: [Tee-dev] Newbie questions about OP-TEE

by Patrick Doyle

On Mon, Nov 21, 2016 at 4:50 AM, Jens Wiklander <jens.wiklander(a)linaro.org> wrote: > plat-sunxi is lagging behind the rest. The new way is > generic_entry_a32.S and generic_entry_a64.S. ...and I keep forgetting to ask... Is the HiKey board still the recommended starting point for jumping into op-tee? What if I wanted to look at an ARMv7 board -- is there a recommended starting point for a good ARMv7 board that best implements the "new way" of doing things in op-tee? --wpd

9 years, 2 months

Newbie questions about OP-TEE

by Patrick Doyle

I am trying to learn about optee. What is the best way to get started? Can I run an example system in QEMU? If so, how would I start? I have heard references on videos and see in README.md a reference to a shell script based setup. Do I follow these directions given at optee_os/README.md: $ cd $HOME $ mkdir devel $ cd devel $ git clone https://github.com/OP-TEE/optee_os.git or these: $ mkdir -p $HOME/devel/optee $ cd $HOME/devel/optee $ repo init -u https://github.com/OP-TEE/manifest.git -m ${TARGET}.xml [-b ${BRANCH}] $ repo sync I see an entry.S in plat-sunxi, but not in any of the other platforms. Is this the new way of doing things or is it the old way. (The exception table seems to be defined in generic_entry_a32.S and generic_entry_a64.S. For the ARMv7-A architectures, it seems that bootstrap code is included. Is that correct? Does the bootstrap code also launch the Linux kernel? How is flash access mediated? I was expecting to find that TrustZone was used to isolate, e.g. the SDIO controller from the normal world and that the TEE would mediate access to the nonvolatile storage. But that would require changes to the Linux kernel, which I don't see. Instead, I see support for secure storage in the normal world. It seems that the following architectures are supported: cortex-a7 cortex-a9 cortex-a15 cortex-a53 cortex-a57 I prefer to ask these questions on a public mailing list. They seem a little too involved for IRC, and I'm sure there are others besides I who would benefit from the answers. Thank you for your time. --wpd

9 years, 2 months

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, 2 months

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, 2 months

[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, 2 months

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Tee-dev November 2016