I think that encryption process is needed for making secure storage more secure.
I see the Linaro connect document(lcu14-306) about encryption of secure storage.
But I can not find encryption for secure storage at current git.

Hi,
Happy New Year!
I realize optee-os has implemented a feature with open trusted excue environment, which can load dynamic trusted applications in run-time OS. That is great.
In optee-os, I get TA including two parts:one parts is TA_SIGNED_HEADER,another part is TA_BODY which come from trusted application's elf file. TA_SIGNED_HEADER defined at kta_types.h:
typedef struct kta_signed_header {
uint32_t magic;
uint16_t size_of_signed_header;
uint16_t size_of_signature;
uint32_t sign_hash_type; /* see t_hash_type /
uint32_t signature_type; / see t_signature_type /
uint32_t hash_type; / see t_hash_type /
uint32_t payload_type; / see enum kta_payload_type /
uint32_t flags; / reserved /
uint32_t size_of_payload;
uint32_t sw_vers_nbr;
uint32_t load_address;
uint32_t startup_address;
uint32_t spare; / reserved */
} kta_signed_header_t;
I got a question about TA_SIGNED_HEADER:
Is this(struct kta_signed_header ) not a part of Global Platform's standard, and maybe come from STM's TEE project? Since I can't find the definition of the struct's variable in optee-os,such as signature_type,hash_type,payload_type. and there is no public key handle variable in struct kta_signed_header, means only can use default key to verify signed header.
Does this mean we can redefine the TA's format, as a example, define TA_SIGNED_HEADER and TA_BODY in two separate code fragments?
Thanks.

Best regards.
xlyu

Hi everyone,

I got a problem when I initialize the OPTEE and return to normal world. I find that I can't access the address of normal world when execute sm_smc_entry. It seems the MMU is still worked and stopping the program. I want to know have you every see this problem before. Do you have any suggest about that? Thanks.

Best Regards,

Hi,

I was trying to port optee_os to a armv7 board. But here is a problem that what address should I send to main_init. Could I set this the start address of u-boot directly? Thanks.

Best Regards,

Hi,
We're working on an implementation for PSCI and have encountered a limitation in the implementation for this function. The use of the static "l2_offs" prevents more than one L2 allocation. The second call returns NULL which causes a fail later in OP-TEE. The library implementation requires 2 memory regions:

1. Coherent Memory - configured as secure, device, size = 16KB
2. Secure Monitor Stack Memory - configured as secure, normal, cached, size = 16KB
   We have a work around for the limitation but it wastes megabytes of memory (because we need to keep things 1Meg aligned). Is there an existing recommended approach for handling this scenario?
   Thanks,
   Paul.

Q1:OP-TEE designed SE accessed directly in TEE, or indirectly accessed via REE?
Q2:SE's drivers is in TEE, or REE? optee_os whether support for driving development？
Q3:if support, how to developed optee_os drivers? the drivers is added in optee_os/core/drivers just like gic or uart?

Hi,

I has a armv7 board. I want to port this in my board. But I don't know how I can do that. Could you provide some document about that? Thank you very much.

Best Regards

Hello everyone,
I'm sorry to bother you again.I try to embed the libtomcrypt test code that locate in the directory
core/lib/libtomcrypt/test/ to the TA.What my aim is to test the internal API of libtomcrypt in the OP-TEE.But,in the link stage,there is an error listed in the following.
" gcc-linaro-arm-linux-gnueabihf-4.9-2014.05_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.9.1/libgcc.a(_dvmd_lnx.o): In function __aeabi_ldiv0': (.text+0x6): undefined reference toraise' "
I don't know what I use the compiler is correct? Maybe this error is result from other reasons.I can't find the real reasons. So,I'm hope to get you help.Thanks.
Best regards

when I tested optee os with arm trusted firmware V1.1 (I utilized optee os tee.bin as bl32 image) on juno platform, I got an error:
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
NOTICE: Booting Trusted Firmware
NOTICE: BL1: v1.1(debug):
NOTICE: BL1: Built : 13:56:45, Feb 12 2015
INFO: BL1: RAM 0x403a000 - 0x403d000
INFO: Loading file 'bl2.bin' at address 0x4017000
INFO: File 'bl2.bin' loaded: 0x4017000 - 0x401c008
NOTICE: BL1: Booting BL2
INFO: BL1: BL2 address = 0x4017000
INFO: BL1: BL2 spsr = 0x3c5
NOTICE: BL2: v1.1(debug):
NOTICE: BL2: Built : 13:56:45, Feb 12 2015
INFO: BL2: Loading BL3-1
INFO: Loading file 'bl31.bin' at address 0x4023000
INFO: File 'bl31.bin' loaded: 0x4023000 - 0x402c010
INFO: BL2: Loading BL3-2
INFO: Loading file 'bl32.bin' at address 0x6000000
INFO: File 'bl32.bin' loaded: 0x6000000 - 0x605d3e0
INFO: BL2: Loading BL3-3
INFO: Loading file 'bl33.bin' at address 0x88000000
INFO: File 'bl33.bin' loaded: 0x88000000 - 0x88280000
NOTICE: BL1: Booting BL3-1
INFO: BL1: BL3-1 address = 0x4023000
INFO: BL1: BL3-1 spsr = 0x3cd
INFO: BL1: BL3-1 params address = 0x4000200
INFO: BL1: BL3-1 plat params address = 0xf1e2d3c4b5a6978
NOTICE: BL3-1: v1.1(debug):
NOTICE: BL3-1: Built : 13:56:46, Feb 12 2015
INFO: BL3-1: Initializing runtime services
INFO: BL3-1: Initializing BL3-2

stop here.why?

Hello,
I would like to perform the following architecture:
Applicaton <- network (using e.g., socket) -> CA (running on rich OS) <-> TA (running on Secure OS)
The goal is to make the functions of a TA available through a network for test purposese.

I am using opTEE over QEMU so my question is:
Is there a network support for the rich OS or not?

Regards,
MALATTAR

i got that ta timeout value, said TEE_TIMEOUT_INFINITE, from this piece of code:
res = tee_ta_open_session(&res_orig, &s, &tee_open_sessions, &in->uuid,
clnt_id, TEE_TIMEOUT_INFINITE, param);

does this mean ta can infinitely trap into its own code without any timeout mechanism ?

Hi

When I trying to Copy OPTEE to memory and running, I got a issue on get_core_pos. For "ClusterId", it got a "f"(15), for "CoreId" it got a "0". I want to know if you has see this problem before? Thanks.

Best Regard,

Hi,

I has ported the old version optee_os to a ARMv7 board successful. But when I trying to change the version to be the last. It show "DBG TEE-CORE:tee_mmu_kmap_init:619: Failed to init kmap. Trap CPU!". I has see the source code. It seems the malloc_init((void *)a, s) has be removed from the new version. I think this may cause this issue. Do you have any solutions?

Best Regards,
Ruizhi

I have recently upgraded to Ubuntu 14.10, which ships GNU make 4.0 by default. With this version, optee_os rebuilds everything each time make is run:

$ make --version
GNU Make 4.0
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ make -j9 PLATFORM=vexpress-fvp CROSS_COMPILE="ccache arm-linux-gnueabihf-"
  CHK     out/arm32-plat-vexpress/core/include/generated/conf.h
  UPD     out/arm32-plat-vexpress/core/include/generated/conf.h
  CC      out/arm32-plat-vexpress/user_ta-lib/libutee/tee_user_mem.o
  CC      out/arm32-plat-vexpress/user_ta-lib/libutee/abort.o
  CC      out/arm32-plat-vexpress/user_ta-lib/libutee/trace_ext.o
<...>
$ make -j9 PLATFORM=vexpress-fvp CROSS_COMPILE="ccache arm-linux-gnueabihf-"
  CHK     out/arm32-plat-vexpress/core/include/generated/conf.h
  UPD     out/arm32-plat-vexpress/core/include/generated/conf.h
  CC      out/arm32-plat-vexpress/user_ta-lib/libutee/tee_user_mem.o
  CC      out/arm32-plat-vexpress/user_ta-lib/libutee/abort.o
  CC      out/arm32-plat-vexpress/user_ta-lib/libutee/trace_ext.o
<...>

This does not occur with GNU make 3.81, as shown below:

$ make --version
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for x86_64-pc-linux-gnu
$ make -j9 PLATFORM=vexpress-fvp CROSS_COMPILE="ccache arm-linux-gnueabihf-"
  CHK     out/arm32-plat-vexpress/core/include/generated/conf.h
  UPD     out/arm32-plat-vexpress/core/include/generated/conf.h
  CC      out/arm32-plat-vexpress/user_ta-lib/libutee/tee_user_mem.o
  CC      out/arm32-plat-vexpress/user_ta-lib/libutee/abort.o
  CC      out/arm32-plat-vexpress/user_ta-lib/libutee/trace_ext.o
<...>
$ make -j9 PLATFORM=vexpress-fvp CROSS_COMPILE="ccache arm-linux-gnueabihf-"
  CHK     out/arm32-plat-vexpress/core/include/generated/conf.h
$

Hello everyone,
I'm very sorry to bother you again. I had build the optee_os. There are two executable file created. I guess the file "tee.bin" need to run before u-boot. But I don't know how I can do that. Should I change the source file of u-boot? Or I just need to put the tee.bin in to some address of memory? I will very appreciate for you to offer any help about that.
Best Regard,

Do anyone kown if OP_TEE supports Versatile express motherboard with the Cortex A9x4 platform. If any example building environment exsits?
Thanks for jenswi-linaro's help.
jenswi-linaro says:
The short answer is no. It shouldn't be hard to add that support though.

Hello everyone,

I'm confused about your source code again. I can't understand what is canary. It must not be a bird name. The define is wired. Could tell me what the purpose of this. I'm very appreciate for you answer.

Best Regard,
Ruizhi

The crypto services does not always properly check the parameters of type TEE_Attribute. For instance:

TEE_Result tee_svc_cryp_derive_key(uint32_t state, const TEE_Attribute *params,
                                   uint32_t param_count, uint32_t derived_key)
{
}

The memory range [params, params + param_count*sizeof(TEE_Attribute)] needs to be validated with tee_mmu_check_access_rights(). And, any attribute of type 'reference' within those parameters should be validated before access too.

Hi,
I'd like to add some new libraries to the optee, so I can build some trusted app using them. But I don't know how to do this.

README.md has the following license explanation :
"The software is provided under the BSD 2-Clause license. BSD 3-Clause license."

Is it either, or both ?

Hello,

I have been working with Paul (paswan-ms) on RPMB support in OP-TEE. The following is a proposal for RPMB support that builds upon the encrypted FS changes (pull request 231).

Connecting the APIs

The proposal here is to add another tee_file_operations table that can be updated by the platform.
Today, the tee_svc_storage_XX APIs (tee_svc_storage.c) call the lower level APIs using the tee_file_ops function table. This table was changed with the security changes to call the tee_enc_fs_XX APIs. Internally the tee_enc_fs_XX APIs call the lower level tee_common_fs_XX APIs.

This change will add another table that the tee_enc_fs_XX APIs can use to call the lower layer physical storage APIs called tee_phy_file_ops. Thus, instead of tee_enc_fs_XX APIs calling tee_common_fs directly they will call tee_phy_file_ops.XX.

The table will be prototyped in tee_fs.h as follows:

extern struct tee_file_operations tee_phy_file_ops;

The table will be defined in tee_ fs_common.c in the following way:

#if ! defined(CFG_PHY_FS)
struct tee_file_operations tee_phy_file_ops = {
    .open = tee_fs_common_open,
    .close = tee_fs_common_close,
    .read = tee_ fs_common_read,
    .write = tee_ fs_common_write,
    .lseek = tee_ fs_common_lseek,
    .ftruncate = tee_ fs_common_ftruncate,
    .rename = tee_fs_common_rename,
    .unlink = tee_fs_common_unlink,
    .mkdir = tee_fs_common_mkdir,
    .opendir = tee_fs_common_opendir,
    .closedir = tee_fs_common_closedir,
    .readdir = tee_fs_common_readdir,
    .rmdir = tee_fs_common_rmdir,
    .access = tee_fs_common_access,
    .stat = tee_fs_common_stat //needs to be added
};
#endif

And tee_file_ops in tee_enc_fs.c will be changed to:

struct tee_file_operations tee_file_ops = {
    .open = tee_enc_fs_open,
    .close = tee_enc_fs_close,
    .read = tee_enc_fs_read,
    .write = tee_enc_fs_write,
    .lseek = tee_enc_fs_lseek,
    .ftruncate = tee_enc_fs_ftruncate,
    .rename = tee_phy_file_ops.rename,
    .unlink = tee_phy_file_ops.unlink,
    .mkdir = tee_phy_file_ops.mkdir,
    .opendir = tee_phy_file_ops.opendir,
    .closedir = tee_phy_file_ops.closedir,
    .readdir = tee_phy_file_ops.readdir,
    .rmdir = tee_phy_file_ops.rmdir,
    .access = tee_phy_file_ops.access,
    .stat = tee_phy_file_ops.stat
};

The platform can then define CFG_PHY_FS and define the table in platform specific files. In our case the platform will provide another definition for the table pointing to the RPMB APIs. Such as the following:

struct tee_file_operations tee_phy_file_ops = {
    .open = tee_rpmb_fs_open,
    .close = tee_rpmb_fs_close,
    .read = tee_ rpmb_fs_read,
    .write = tee_ rpmb_fs_write,
    .lseek = tee_ rpmb_fs_lseek,
    .ftruncate = tee_ rpmb_fs_ftruncate,
    .rename = tee_ rpmb_fs_rename,
    .unlink = tee_ rpmb_fs_unlink,
    .mkdir = tee_ rpmb_fs_mkdir,
    .opendir = tee_ rpmb_fs_opendir,
    .closedir = tee_ rpmb_fs_closedir,
    .readdir = tee_ rpmb_fs_readdir,
    .rmdir = tee_ rpmb_fs_rmdir,
    .access = tee_ rpmb_fs_access,
    .stat = tee_rpmb_fs_stat
};

RPMB APIs

The current implementation of RPMB implements a FAT like table that stores the file name, location and size in the RPMB block. The FAT table sits in the beginning of the RRMB block.

Directory Support

Directory support is missing from the current RPMB implementation that needs to be added to support calls from the higher level encryption APIs. In OPTEE today there is only a one-level deep directory hierarchy defined as TA_ID/OBJECT_ID. There is a directory for every TA that contains the objects that that TA owns.

Short Term Solution

The quickest short term solution to add “directory” support to the current implementation of RPMB is to store the full path as the name of the file in the FAT table. The FAT table supports a maximum file name of 48 characters. The object ID maximum length is 64 character, plus the size of the UUID for the TA is 16 plus one for the directory divisor character would require us to change the maximum file size to 81 characters or to (sizeof(TEE_UUID) + TEE_OBJECT_ID_MAX_LEN + 1).

With this approach the RPMB APIs that need to be implemented will be as follows:

• Open: This API will look through the FAT for the file with full path in question and return a file descriptor representing the file. A new FAT entry can be created for the file if it does not already exist. This can be the index into the FAT table or can be implemented as a separate file descriptor table.
• Close: Will release any used memory to represent the file.
• Read: tee_rpmb_fs_read, this API will be changed to accept a file handle instead of a name since there must have been a preceding open call. This API does not require any functional changes. Note that the entire file must be read at once in the current implementation. In the short term this is acceptable because the encryption filesystem reads the entire file from the underlying storage on the open call.
• Write: tee_rpmb_fs_write, this API will be changed to accept a file handle instead of a name. This API does not require functional changes. Note that the entire file must be written at once in the current implementation. In the short term this is acceptable because the encryption filesystem writes the entire file to the underlying storage during the close call.
• Lseek: A call to lseek to 0 will return success, everything else will return a failure since the whole file must be written at once. There is a call to lseek to the end in tee_enc_fs.c to get the file length but this can be changed to use stat instead.
• Ftruncate: Anything other than 0 will return an error to delete the whole file. This will need to be implemented. tee_enc_fs.c currently calls to truncate the file to the new encrypted file size in tee_enc_fs_close() and then is followed by a total write of the new file contents. This can be changed to a truncate(0) followed by a write.
• Rename: tee_rpmb_fs_rename currently works. This will just need to be changed to take into account the “directory” portion of the name.
• Unlink: tee_rpmb_fs_rm will work here.
• Mkdir: This will return a failure and should not be called because the current implementation of tee_svc_storage_create_file calls open first with the full path which will succeed skipping the mkdir call.
• Opendir: A call to this API will traverse the FAT table and generate a list of entries. A read index will also be stored.
• Closedir: Will free the generated list of entries.
• Readdir: Will return the tee_fs_dirent at the current index and increment the index.
• Rmdir: Will return success if all files in that “directory” have been unlinked.
• Access: Will return true if that file exits.

Optimizations

One performance issue that arrises from the proposed solution is that the entire FAT needs to be traversed to find a particular UUID/OBJECT_ID file instead of just traversing the directory files. This can be improved by:

1. Creating a hash of the file names to FAT addresses for quick lookup.
2. Longer term solution of adding directory entries to the FAT. In other words having special entries in the FAT that point to files that store the directory entries and their locations.

Currently, the RPMB code generates a tee_mm_pool_t to represent the FAT structure on every write call. This can be done during initialization and stored in memory avoiding the need to traverse the FAT and build the pool on every write call. Also an in memory representation of the FAT will save the need to read the FAT and issue RPC calls to normal world.

Open Questions

i found there is no task scheduling in opee-os, So we cannot run TUI on optee-os ?

when I tested optee os with ARM-TF master V1.1 (I utilized optee os tee.bin as bl32 image) on FVP,
and set Makefile:

Flags to generate the Chain of Trust

GENERATE_COT := 1
CREATE_KEYS := 1

Flags to build TF with Trusted Boot support

TRUSTED_BOARD_BOOT := 1
AUTH_MOD := polarssl

It stopped at "BL3-1: Initializing BL3-2",that's maybe something went wrong when OP-TEE was initializing.
When the ARM-TF which with TRUSTED_BOARD_BOOT can support to load an OP-TEE binary?
Please tell me Which files relates to? and how to analyse and solve this problem?
Too many thanks!

FVP terminal_0 log:
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
NOTICE: Booting Trusted Firmware
NOTICE: BL1: v1.1(debug):
NOTICE: BL1: Built : 17:03:10, Apr 20 2015
INFO: BL1: RAM 0x4038000 - 0x403e000
INFO: Using authentication module 'PolarSSL'
INFO: Loading file 'bl2.crt' at address 0x4007000
INFO: Skip reserving memory: 0x4007000 - 0x4007347
INFO: File 'bl2.crt' loaded: 0x4007000 - 0x4007347
INFO: Loading file 'bl2.bin' at address 0x4007000
INFO: File 'bl2.bin' loaded: 0x4007000 - 0x401b018
NOTICE: BL1: Booting BL2
INFO: BL1: BL2 address = 0x4007000
INFO: BL1: BL2 spsr = 0x3c5
NOTICE: BL2: v1.1(debug):
NOTICE: BL2: Built : 17:03:10, Apr 20 2015
INFO: Using authentication module 'PolarSSL'
INFO: Loading file 'trusted_key.crt' at address 0x4023000
INFO: Skip reserving memory: 0x4023000 - 0x4023597
INFO: File 'trusted_key.crt' loaded: 0x4023000 - 0x4023597
INFO: Loading file 'bl31_key.crt' at address 0x4023000
INFO: Skip reserving memory: 0x4023000 - 0x402345d
INFO: File 'bl31_key.crt' loaded: 0x4023000 - 0x402345d
INFO: Loading file 'bl31.crt' at address 0x4023000
INFO: Skip reserving memory: 0x4023000 - 0x402335b
INFO: File 'bl31.crt' loaded: 0x4023000 - 0x402335b
INFO: Loading file 'bl32_key.crt' at address 0x4023000
INFO: Skip reserving memory: 0x4023000 - 0x402345d
INFO: File 'bl32_key.crt' loaded: 0x4023000 - 0x402345d
INFO: Loading file 'bl32.crt' at address 0x4023000
INFO: Skip reserving memory: 0x4023000 - 0x402335b
INFO: File 'bl32.crt' loaded: 0x4023000 - 0x402335b
INFO: Loading file 'bl33_key.crt' at address 0x4023000
INFO: Skip reserving memory: 0x4023000 - 0x402345d
INFO: File 'bl33_key.crt' loaded: 0x4023000 - 0x402345d
INFO: Loading file 'bl33.crt' at address 0x4023000
INFO: Skip reserving memory: 0x4023000 - 0x402335b
INFO: File 'bl33.crt' loaded: 0x4023000 - 0x402335b
INFO: BL2: Loading BL3-1
INFO: Loading file 'bl31.bin' at address 0x4023000
INFO: File 'bl31.bin' loaded: 0x4023000 - 0x402c010
INFO: BL2: Loading BL3-2
INFO: Loading file 'bl32.bin' at address 0x6000000
INFO: File 'bl32.bin' loaded: 0x6000000 - 0x605d3e0
INFO: BL2: Loading BL3-3
INFO: Loading file 'bl33.bin' at address 0x88000000
INFO: File 'bl33.bin' loaded: 0x88000000 - 0x88280000
NOTICE: BL1: Booting BL3-1
INFO: BL1: BL3-1 address = 0x4023000
INFO: BL1: BL3-1 spsr = 0x3cd
INFO: BL1: BL3-1 params address = 0x4000200
INFO: BL1: BL3-1 plat params address = 0xf1e2d3c4b5a6978
NOTICE: BL3-1: v1.1(debug):
NOTICE: BL3-1: Built : 17:10:05, Apr 20 2015
INFO: BL3-1: Initializing runtime services
INFO: BL3-1: Initializing BL3-2

what confused me is that why optee-os user space use mapping address started from 1M by
TEE_DDR_VLOFFSET to 1 ? why not started from 0 ?

Hi all,
I'm very interesting in your OP-TEE. I think it would be very useful in the future. And I has study it for a long time.But I can't find a example of the Trusted Application. Or I don't know how a Trusted Application should be defined and built. I want to know how I can create a simple Trusted Applications. Sending "Hello tee!" from Trusted Application to Client is enough. I will very appreciate for you do that.
Best Regards,
Ruizhi

Hi,
We're intending to utilize the OpTEE OS on the 32-bit ARM architecture and provide a Trusted Application implementation of PSCI. The ARM PSCI interface is defined at the SMC level and thus does not follow the Global Platform specifications. Therefore, we think we need to do the following:

1. When the OpTEE OS is started automatically self-open a session targeting the PSCI Trusted Application (TA). This session is never closed and is used as the implicit session identification for all PSCI calls. Client originated session open & close targeting the PSCI TA is prohibited (blocked).
2. Adjust the inbound vector handler to filter the PSCI SMC calls and call a conversion dispatch handler to convert the ARM PSCI SMC call into a TEESMC_CMD_INVOKE_COMMAND call utilizing the automatic PSCI TA session created above when the OS was started. The conversion dispatch handler remaps the ARM PSCI call registers and parameter definitions to a compliant TEESMC_CMD_INVOKE_COMMAND call targeting the PSCI TA.
3. On completion of the PSCI TA call perform a similar outbound conversion to convert the TEESMC_CMD_INVOKE_COMMAND completion return parameters to match the ARM PSCI SMC specification.

This would serve as a template for being able have Trusted Applications in OpTEE handle externally specified SMC call API's.

Since we're starting from scratch with OpTEE, we'd be grateful for any insight on if we're heading in the right direction to solve this problem?
Thanks,
Paul.

export CFG_TEE_CORE_LOG_LEVEL=5 in setup_fvp_optee.sh seems to be causing an error while building optee_os?

Should be 1-4?

optee_os/lib/libutils/ext/trace.c

if (CFG_TRACE_LEVEL < TRACE_MIN) || (CFG_TRACE_LEVEL > TRACE_MAX)

error "Invalid value of CFG_TRACE_LEVEL"

endif

Hello everyone,

I got a problem on porting OPTEE. My platform is using u-boot to boot, and it is store in nor flash. When I trying to copy the OPTEE on nor flash as a boot loader before u-boot. I find that it is trying to change the value of nor flash. So it breakdown. I want know should I relocate the OPTEE or I just need to copy the OPTEE to memory and jump to its start address? I'm confused about that. Thanks!

BestRegard,

Hi all,

I'm reading your source code. I'm want know how you install the secure monitor. There is a function called get_core_pos() seems very important. I can't understand what it did.What is CorePos? The prototype is defined in opteeos/core/arch/arm32/kernel/misc.S. I'm very appreciate for you answer.

Best Regard,
Ruizhi

Hello,
I want to load TUI(Trusted User Interface) or other peripheral device dynamicaly at secure OS.
Do you have schedule about loading mechanism of hardware device driver?

Hello,

I am having a little trouble understanding this check in tee_mm_alloc():

if (((entry->offset << pool->shift) - pool->lo) < size)

This is a snippet from the larger:

    if (pool->flags & TEE_MM_POOL_HI_ALLOC) {
        if (((entry->offset << pool->shift) - pool->lo) < size)
            /* out of memory */
            return NULL;
    } else {
        if (((entry->offset << pool->shift) - pool->lo) < size)
            /* out of memory */
            return NULL;
        if ((((entry->offset + entry->size) << pool->shift) + size) >
            (pool->hi - pool->lo))
            /* out of memory */
            return NULL;
    }

Consider the case where TEE_MM_POOL_HI_ALLOC is not set and entry->offset is 0 and pool->lo is also 0 this check will always cause the function to return NULL.

Also, isn't entry->offset an offset from pool->lo and not an absolute address? This would generally mean that entry->offset is much smaller than pool->lo causing it to wrap since this is uint32_t.

Your input is much appreciated.

Regarding secure timer, there is common interface to update time-stamp for TA. But I don't understand why tee_time_unpg.c still remained in core/arch/arm/kernel directory. There is no driver code to register this callback function to interrupt service in OP-TEE and no value for common timer system.

Hi everyone

I got a problem on world switch on porting OPTEE. When I send the entry of normal world to main_init. It is seems doesn't work. I has see all the source code about switch. I could not see any code that put the nsec_ctx->mon_lr which saved the entry of normal world to the top address of sp. So the rfe instruction can't put normal world entry to PC. It is seems the top 2 address of sp is user_lr and user_spsr. But we don't save any thing of the two value when reset. I want to know how can you send the mon_lr to PC, so I can debug if there are something worry on my code. I will very appreciate for you answer my question.

Thanks a lot,

In the current version of TA-dev-kit we have hard-coded flags in ta/mk/ta_dev_kit.mk. In some situation this will be a problem since different platforms have need for different set of flags.

We should instead change TA-dev-kit so that it makes use of the configuration flags coming from the current platform being built.

Hi,
I has run the fvp successful and see the console. But when I modprobe the optee module, the fvp can't work, and show that EER [0x0] TEE-CORE:_assert_log:37: Assertion ‘(read_cpsr() & CPSR_FIA) == CPSR_FIA’ failed at core/arch/arm32/kernel/thread.c:244. I can't find this line in old sourcefile. It is seems added recently. If I comment this line, it is working. So, please check if any issue.
Best Regards,

Hi,
We're aiming to implement a couple of TA's that will utilize storage on the RPMB portion of eMMC and see that there is RPMB functionality in the OpTEE OS with some file system on top. What we weren't able to find was how this is connects to an API surface a TA could use. For example, tee_rpmb_fs_read did not appear to be obviously referenced anywhere. Is there a recommended way that this is intended to be utilized?
Thanks,
Paul.

Hi,
I tried to test opTee using QEMU emulator.
I built the hellow_world example provided by Jens Wiklander (lcu14_optee_hello_world).
I modified gen_rootfs/filelist-tee.txt in order to push the executable and the TA into /bin and /lib/teets repecitvely. Then, I called update_rootfs.sh to regenerate the filesystem.
Eventhough filesystem.cpio.gz (which I think it is the image of the filesystem that it is called when kernel is launched) contains the TA and the hellow-world executable, but the loaded kernel module for OP-TEE does not contain the TA nor the executable !!!
Have you any idea about this problem?

Regards,
MALATTAR

I have been able to get the OP-TEE working on the Juno armv8 board for Linux.
I did build the OP-TEE parts under Android but get the following:
1: Loading kernel drivers goes ok.
2: Running tee_supplicant gives [ 1935.764795] armv7sec armv7sec.0: tee_supp_read: ERROR
Supplicant application NOT ready.
We use the same TFW images including the op-tee as BL32 as we did for Linux.

Does anyone has this working and could give me some hints?

when I tested optee os with arm trusted firmware (I utilized optee os tee.bin as bl32 image) on juno platform, I got an error:
INFO: Using FIP
INFO: Loading file 'bl32.bin' at address 0x4023000
WARNING: Failed to reserve memory: 0x4023000 - 0x407e540
INFO: Trying to load image at address 0x4023000, size = 0x5b540
INFO: Current memory layout:
INFO: total region = [0x4023000, 0x4040000]
INFO: free region = [0x4023000, 0x4040000]
WARNING: Failed to load BL3-2 (-12)

I found that tee.bin is 172K, but the tzram free space for bl32 is 64K (./plat/juno/include/platform_def.h), it's smaller than the requested size.
I tried to modify the size of tzram for bl32, but the atf stop at the beginning of bl2:

VERBOSE: Reserved 12288 bytes (discarded 0 bytes below)
INFO: BL1: 0x4001000 - 0x4004000 [size = 12288] -- hugo -002
NOTICE: Booting Trusted Firmware
NOTICE: BL1: v1.0(debug):bbb59e7
NOTICE: BL1: Built : 16:28:51, Dec 5 2014
INFO: BL1: RAM 0x4001000 - 0x4004000
VERBOSE: FIP header looks OK.
INFO: Using FIP
INFO: Loading file 'bl2.bin' at address 0x4053000
VERBOSE: Reserved 53248 bytes (discarded 32760 bytes above)
INFO: File 'bl2.bin' loaded: 0x4053000 - 0x4058008
VERBOSE: Reserved 12288 bytes (discarded 0 bytes below)
NOTICE: BL1: Booting BL2
INFO: BL1: BL2 address = 0x4053000
INFO: BL1: BL2 spsr = 0x3c5
VERBOSE: BL1: BL2 memory layout address = 0x4004000

Could you please tell me how to solve this problem?

Hi,

I has read the thread part of source code. I find that the thread status almost totally determined by itself. So I find that if I write a infinite loop in TA, all system can't work anymore when running the TA. Because there are no way to stop this TA. I think it would be a serious problem. So I want to know do you have any plan to design some timeout handle for TA? Thanks a lot.

Best Regards,

There is a race condition in the Makefile rules for PLATFORM=sunxi, which can cause build failures such as the ones in Travis build 47950213.

The issue may be reproduced easily by introducing some delay in the check-conf-h recipe, as follows:

$ git diff
diff --git a/mk/checkconf.mk b/mk/checkconf.mk
index 1b6afa7..27bc82b 100644
--- a/mk/checkconf.mk
+++ b/mk/checkconf.mk
@@ -27,6 +27,7 @@ define check-conf-h
                rm -f [email protected];                                   \
        else                                                    \
                echo '  UPD     $@';                            \
+               sleep 2;                                        \
                mv [email protected] $@;                                   \
        fi
 endef

Then make -j fails:

$ PLATFORM=sunxi make -j8
  CHK     out/arm32-plat-sunxi/core/include/generated/conf.h
  UPD     out/arm32-plat-sunxi/core/include/generated/conf.h
  CPP     out/arm32-plat-sunxi/core/kern.ld
  CC      out/arm32-plat-sunxi/user_ta-lib/libutee/tee_api_property.o
  CC      out/arm32-plat-sunxi/user_ta-lib/libutee/tee_user_mem.o
  CC      out/arm32-plat-sunxi/user_ta-lib/libutee/abort.o
  CC      out/arm32-plat-sunxi/user_ta-lib/libutee/trace_ext.o
  CC      out/arm32-plat-sunxi/user_ta-lib/libutee/assert.o
cc1: fatal error: out/arm32-plat-sunxi/core/include/generated/conf.h: No such file or directory
compilation terminated.
core/arch/arm32/plat-sunxi/link.mk:34: recipe for target 'out/arm32-plat-sunxi/core/kern.ld' failed
make: *** [out/arm32-plat-sunxi/core/kern.ld] Error 1
make: *** Waiting for unfinished jobs....
  CC      out/arm32-plat-sunxi/user_ta-lib/libutee/base64.o
$

Is there any watch dog driver implemented in op-tee?
If not, I'm willing to upstream ARM watchdog driver but plz let me know the interface who is kicking dog.

killer@killer-VirtualBox:/fvp$ ./setup_fvp_optee.sh
FVP must be downloaded first, please go to:
http://www.arm.com/products/tools/models/fast-models/foundation-model.php
When done, install it on this path:
/home/killer/devel/fvp_optee/Foundation_Platformpkg
Then open this script (setup_fvp_optee.sh) and change the line from saying:
SRC_FVP= to SRC_FVP=1
killer@killer-VirtualBox:/fvp$

What's happened on my ubuntu14.04，I can't setup FVP,thanks you!

Hi,

I am porting optee_os to a single core cortex-A7 r0p5 soc. When I executing hello_world demo, it hangs at:

    if (map) {
        write_ttbr0(map->ttbr0);  --->ttbr0 is 9c16c46a, i use 0x9c100000 as the entry for optee_os
        isb();
        write_contextidr(map->ctxid);  ---> seems it hangs here in function core_mmu_set_user_map,  When "Load dynamic TA", no LPAE.
    } else {

The tee-supplicant can work, the driver modules in linux also loaded successfully.
Did I miss something when porting optee_os?

Thanks.

Hi everyone,
I want to make optee work on our CA9*4 SoC by referring to the codes for plat-stm.
But I find that some SMC requests sent by the opteeos , such as TEESMC_OPTEED_RETURN_ENTRY_DONE , are not responded to by the opteeos self, but are dealt with in the ATF codes.

To my knowledge , the ATF only work on ARM-v8.
Is it correct?
If yes, how the opteeos work on ARM-v7 without the ATF?
Do we need to write our own monitor codes to respond to the opteeos SMC requests?

Best Regards.

Hello everyone,

I'm thinking about how I can use the optee this day. But I find a real problem. That I can't interact directly with optee_os. Any information must send through client application. I think It is not very security. As I know GlobalPlatform has defined TUI. So I want to know if you have any plan to realize the TUI or other simple human interface. Because I think it is important.

Best Regards,
Ruizhi,

in the openssl branch ,how to add bio pkcs7 x509 module to libopensslcrypto.a

Hi,

I'm compiling OP-TEE, Android flavor for the Juno board and I'm able to run the hello_world example. However when compiling hello_world in 32-bits and using libteec.so 32-bit version the TEE_OPEN_SESSION ioctl fails. I've checked and it seems to be a problem of a 32-bit client talking to a 64-bit driver. Are there any plans on supporting this combination?

Thanks in advance,
Roberto

Hi,

I got a error when I executed TA on my porting board. It is seems caused by multi-core running. Here is the error log.

ERR [0x0] TEE-CORE:tee_pager_print_error_abort:101: data-abort at 0xfc053d6c
FSR 0x1008 PC 0xfc005434 TTBR0 0xFC06804A CONTEXIDR 0x0
CPUID 0x80000f01 DBGPCSR 0x0 CPSR 0x600001d3 (read from SPSR)
ERR [0x0] TEE-CORE:tee_pager_handle_abort:190: Unexpected page fault! Trap CPU
INFO: rcu_sched detected stalls on CPUs/tasks: { 1} (detected by 0, t=2102 jiffies, g=4294967196, c=4294967195, q=18)
Task dump for CPU 1:
hello_world R running 0 720 705 0x00000000

I want to know have you ever see this problem before?

Thanks,
Ruizhi