apache / incubator-teaclave-trustzone-sdk Goto Github PK

What mk (qemu_v8.mk\qemu.mk\juno,mk\hikey.mk\hikey960.mk etc.) should I use when installing the OP-TEE on physical machine?

Here is the error during build the toolchains:

**make -C /root/incubator-teaclave-trustzone-sdk/optee/build -f hikey960.mk toolchains
make[1]: Entering directory '/root/incubator-teaclave-trustzone-sdk/optee/build'
Building aarch64 toolchain
build/br-ext/scripts/make_def_config.py --br buildroot --out out-aarch64-sdk --br-ext build/br-ext --top-dir /root/incubator-teaclave-trustzone-sdk/optee/build/.. --br-defconfig build/br-ext/configs/sdk-aarch64 --br-defconfig build/br-ext/configs/sdk-common --make-cmd make
make[2]: Entering directory '/root/incubator-teaclave-trustzone-sdk/optee'
make[2]: *** buildroot: No such file or directory.  Stop.**

Hi,

Thanks for the great work! If I understand correctly, the optee used in the skd is 3.4, but we are supposed to test the TAs under optee 3.8 as the instructions specifies. However, after I replaced the optee with optee 3.8 (copied and pasted from optee-qemuv8-3.8.0), I got a translation fault when I test the TA.

We are developing a board adopting optee 3.8. It will be really helpful if you can give us any advice on how to move from optee_os 3.4 to 3.8 so that we can use your scheme.

PS: If I compile TAs with optee_os 3.4 and test TAs with optee 3.8, it works well.

Thanks,
Mingyuan

The error looks like following:

D/TC:? 0 tee_ta_init_pseudo_ta_session:280 Lookup pseudo TA 8aaaf200-2450-11e4-abe2-0002a5d5c51b
D/TC:? 0 load_ldelf:704 ldelf load address 0x40006000
D/LD:  ldelf:134 Loading TA 8aaaf200-2450-11e4-abe2-0002a5d5c51b
D/TC:? 0 tee_ta_init_session_with_context:573 Re-open TA 3a2f8978-5dc0-11e8-9c2d-fa7ae01bbebc
D/TC:? 0 system_open_ta_binary:250 Lookup user TA ELF 8aaaf200-2450-11e4-abe2-0002a5d5c51b (Secure Storage TA)
D/TC:? 0 system_open_ta_binary:253 res=0xffff0008
D/TC:? 0 system_open_ta_binary:250 Lookup user TA ELF 8aaaf200-2450-11e4-abe2-0002a5d5c51b (REE)
D/TC:? 0 system_open_ta_binary:253 res=0x0
D/LD:  load_main:863 Reloading TA 8aaaf200-2450-11e4-abe2-0002a5d5c51b as legacy TA
D/TC:? 0 system_open_ta_binary:250 Lookup user TA ELF 8aaaf200-2450-11e4-abe2-0002a5d5c51b (Secure Storage TA)
D/TC:? 0 system_open_ta_binary:253 res=0xffff0008
D/TC:? 0 system_open_ta_binary:250 Lookup user TA ELF 8aaaf200-2450-11e4-abe2-0002a5d5c51b (REE)
D/TC:? 0 system_open_ta_binary:253 res=0x0
D/LD:  ldelf:169 ELF (8aaaf200-2450-11e4-abe2-0002a5d5c51b) at 0x40012000
D/TC:? 0 tee_ta_close_session:499 csess 0xe178320 id 1
D/TC:? 0 tee_ta_close_session:518 Destroy session
[+] TA create
[+] TA open session
D/TC:0 0 abort_handler:524 [abort] abort in User mode (TA will panic)
E/TC:? 0 
E/TC:? 0 User TA prefetch-abort at address 0x0 (translation fault)
E/TC:? 0  esr 0x82000005  ttbr0 0x200000e18a000   ttbr1 0x00000000   cidr 0x0
E/TC:? 0  cpu #0          cpsr 0x60000100
E/TC:? 0  x0  0000000000000000 x1  0000000000000000
E/TC:? 0  x2  0000000000000040 x3  0000000000000040
E/TC:? 0  x4  0000000000000010 x5  00000000400282c0
E/TC:? 0  x6  0000000000000000 x7  0000000000000000
E/TC:? 0  x8  0000000000000003 x9  0000000000000003
E/TC:? 0  x10 0000000000000003 x11 0000000000000000
E/TC:? 0  x12 0000000000000000 x13 0000000040039f80
E/TC:? 0  x14 0000000000000000 x15 0000000000000000
E/TC:? 0  x16 000000000e11d8b8 x17 0000000000000000
E/TC:? 0  x18 0000000000000000 x19 0000000000000000
E/TC:? 0  x20 0000000000000000 x21 0000000000000000
E/TC:? 0  x22 0000000000000000 x23 0000000000000000
E/TC:? 0  x24 0000000000000000 x25 0000000000000000
E/TC:? 0  x26 0000000000000000 x27 0000000000000000
E/TC:? 0  x28 0000000000000000 x29 0000000000000000
E/TC:? 0  x30 0000000000000000 elr 0000000000000000
E/TC:? 0  sp_el0 0000000040039f80
E/LD:  Status of TA 8aaaf200-2450-11e4-abe2-0002a5d5c51b
E/LD:   arch: aarch64
E/LD:  region  0: va 0x40004000 pa 0x0e300000 size 0x002000 flags rw-s (ldelf)
E/LD:  region  1: va 0x40006000 pa 0x0e302000 size 0x007000 flags r-xs (ldelf)
E/LD:  region  2: va 0x4000d000 pa 0x0e309000 size 0x001000 flags rw-s (ldelf)
E/LD:  region  3: va 0x4000e000 pa 0x0e30a000 size 0x003000 flags rw-s (ldelf)
E/LD:  region  4: va 0x40011000 pa 0x0e30d000 size 0x001000 flags r--s
E/LD:  region  5: va 0x40012000 pa 0x00010000 size 0x01a000 flags r-xs [0]
E/LD:  region  6: va 0x4002c000 pa 0x0002a000 size 0x00d000 flags rw-s [0]
E/LD:  region  7: va 0x40039000 pa 0x0e335000 size 0x001000 flags rw-s (stack)
E/LD:   [0] 8aaaf200-2450-11e4-abe2-0002a5d5c51b @ 0x40012000
E/LD:  Call stack:
E/LD:   0x0000000000000000
D/TC:? 0 user_ta_enter:168 tee_user_ta_enter: TA panicked with code 0xdeadbeef
D/TC:? 0 tee_ta_close_session:499 csess 0xe178b20 id 1
D/TC:? 0 tee_ta_close_session:518 Destroy session
D/TC:? 0 destroy_context:298 Destroy TA ctx (0xe178ac0)
E/TC:? 0 tee_ta_open_session:728 Failed. Return error 0xffff3024

Hey, I have been successful in building on my laptop, but now when i try to build on my personal computer i run into this issue. When running make optee.

The problem is commonly related to not having the uuid-dev package it seems, but I have installed all prerequisites.

Thankful for any help!

Is it possible to lift the rust dependency from nightly-2019-07-08 to a newer version? This is two (!) years old?

error[E0460]: found possibly newer version of crate std which hex depends on
--> /home/chuan/optee/out-br/build/optee_rust_examples_ext-1.0/optee-utee/src/uuid.rs:19:5
|
19 | use hex;
| ^^^
|

after change hex version 0.3 to 0.4:

error[E0460]: found possibly newer version of crate core which uuid depends on
--> /home/chuan/optee/out-br/build/optee_rust_examples_ext-1.0/optee-utee/src/uuid.rs:21:5
|
21 | use uuid as uuid_crate;
| ^^^^
|

in trustzone-sdk directory, run make to compile successfully.
after sync to optee/out-br/build/optee_rust_examples_ext-1.0, failed to compile in directory optee_rust_examples_ext-1.0

您好！是这样的，我们这边用了python写了一堆的算法，引入了各种第三方的依赖库。现在我们想把这个python代码放到tee环境下运行，想法是：将这些python代码打包成动态库.so，然后rust那边链接该动态库执行里面的python代码，然后编译rust项目再normarl world上执行，由于是动态库，（normarlworld？secure world？）需要有python环境并且安装上了python的第三方依赖（如numpy、pandas、sklearn等）。
请问这样做是否妥当呢？（因为我们目前暂不掌握rust语言，并且就算掌握了 需要用rust重写python实现的那些算法逻辑，成本还有时间非常大，故采用rust调python代码的方式）

in normal world terminal

I'm new to OPTEE. I find that every time I need run make run-only to start OPTEE environment(qemu_v8).
But how do I save a new file I created in the OPTEE environment to my host OS device?
Or how can I create a OPTEE snapshots?

您好，我是一名华工学生，主要研究optee上的应用（比如实现wpa3的dragonfly协议），由于GP规范大整数API较为难用，因此对您的项目非常感兴趣，希望能够使用rust更方便实现TA。
现在遇到一个问题，git submodule update --init中optee资源在外网，下载速度过慢。
之前我研究optee时，使用repo init -u https://github.com/OP-TEE/manifest.git -m ${TARGET}.xml [-b ${BRANCH}]进行下载，其中${TARGET}.xml指定的是运行环境，${BRANCH}指定的是选择的版本分支，由于资源在外网缘故，需要在上述命令行添加--repo-url=git://codeaurora.org/tools/repo.git来指定下载url链接。
不知道您这边能否加速git下载，如果不行，我自己去下载optee源码放到相应目录下，是否会有项目兼容性问题？

Hello, I wish to develop a new CA/TA in OPTEE using Rust with QEMUv8. I have been following this guide, and created a shared folder to run these applications in QEMU. I am now trying to see if i can alter hello_world-rs to use a different number than the original example does. But even though it seems that i have succesfully shared the installed examples, I get error: not found.

I found this issue, and I can run hello_world-rs, but that's the original and unaltered example. I want to run my new, altered version.

The file should be executable.

I am very thankful for any help with this!

执行examples/tls_client-rs和examples/tls_server-rs的时候会直接提示如下错误：

Error: System ran out of resources. (error code 0xffff000c)

Hi the community, I saw there are lots of files missing Apache License headers, it's kind of painful to recognize and add missing headers to those files, we created license-eye to help add missing license header for existing files.

License-eye is also able to be run as GitHub Actions, which make it possible to check and verify the license header during PR process, preventing future new files missing headers too.

If you're interested in this tool, I'm glad to help to set it up in this repo, and add headers to existing files.

Thanks

Hi

I am trying to play around with some rust TA examples and I found that the signature_verification-rs example is using the ring module from a specific repo (https://github.com/veracruz-project/ring.git)

My questions are the following:

1. is it safe and secure to use external crate in the TA for cryptographic operations instead of tee api?
2. why use a specific repo for ring and not the official crate? (https://crates.io/crates/ring)
3. are there other crypto crate we could use in TA?

Thanks

change /host/src/main.rs to /host/src/lib.rs?

I observe that aarch64-unknown-optee-trustzone target is maintained here [1]. Are there any plans to make it an official target upstream? I do see another target: aarch64-unknown-teeos became officially supported tier 3 target upstream here [2] [3] [4] [5]. Can we re-purpose that target for OP-TEE? Or we need to add another target upstream?

[1] https://github.com/mesalock-linux/rust/commits/teaclave-trustzone-sdk-1.56.1
[2] https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/aarch64-unknown-teeos.md
[3] rust-lang/rust#113480
[4] rust-lang/libc#3333
[5] rust-lang/rust#116565

when i compile the open source gmsm = "0.1",

the optee returned like this:
package byteorder v1.5.0 cannot be built because it requires rustc 1.60 or newer, while the currently active rustc version is 1.57.0-nightly.

how can i update the rust version?

您们好！我之前也有调研过你们基于intel sgx的teaclave项目，发现里面的rust可信区域代码和python可信区域代码（mesapy）是不能使用第三方库的，就算要使用，也要使用rust-sgx-sdk进行修改调整之后才能用。 那这次的这个trustzone-sdk的ta程序能否直接使用第三方库？比如crates.io里面的

Hello team,
I am new to Rust OP-TEE. I use C/C++, and I haven't learned Rust. I know that TA can execute a third-party lib(crate), and the third-party lib must be a static link lib, right? So if there are some codes in crate that have to invoke system calls (such as read()/open()/write() in Linux), can Rust TA executes this code in secure world?

thanks,
Steph

I/TC: Primary CPU switching to normal world boot
I/TC: Secondary CPU 1 initializing
I/TC: Secondary CPU 1 switching to normal world boot
D/TC:0 tee_entry_exchange_capabilities:100 Asynchronous notifications are disabled
D/TC:0 tee_entry_exchange_capabilities:109 Dynamic shared memory is enabled
E/TC:1 0 core_mmu_xlat_table_alloc:511 8 xlat tables exhausted
E/TC:1 0 Panic 'Failed to spread pgdir on small tables' at core/mm/core_mmu.c:1677 <core_mmu_map_pages>

Hey
I'm trying to add the third party crate chrono to my TA.
After adding chrono = "0.4.22" to my TA Cargo.toml, running "make" inside my example returns this error:

I know it's related to the chrono crate because the example compiles fine when i remove chrono from the toml.
Adding chrono to the CA also compiles fine.

My .toml dependencies looks like this:

[dependencies]
chrono = "0.4.22"
libc = { path = "../../../rust/libc" }
proto = { path = "../proto" }
optee-utee-sys = { path = "../../../optee-utee/optee-utee-sys" }
optee-utee = { path = "../../../optee-utee" }
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"

Any idea what could be the source of this?
Thanks again :)

I've been trying to build OP-TEE with Rust on an aarch64 Linux host. (Mostly Debian Bookworm in a VM on MacBook M1)

I've run into at least three issues so far and made a PR for one of them:

• OP-TEE/build#749, with a fix PR OP-TEE/build#748
• OP-TEE/build#751
• OP-TEE/build#752

751 is not Rust-related, and is easily worked around with WITH_CXX_TESTS=n, but 752 is Rust-related and if anyone has any ideas on how to fix it, I would greatly appreciate hearing them.

I'm having an issue where a TA is running out of heap memory.
I've increased TA_DATA_SIZE, but this appears to have no effect.
Looking through the code, the ta_heap array is allocated in ta_static.rs and placed in bss.
However, I cannot find where ta_heap is being added to the memory pools (or even if the OPTEE memory pool implementation is being used by the rust allocator).
Where in the code is the ta_heap array being used?

Hi, When I execuited the command "sudo make QEMU_VIRTFS_ENABLE=y CFG_TEE_RAM_VA_SIZE=0x00300000 failed" in path "/home/laurencechan/rust-optee-trustzone-sdk/optee-qemuv8-3.4.0/build" , but got this error message.

LINK    aarch64-softmmu/qemu-system-aarch64
make[1]: Leaving directory '/home/laurencechan/rust-optee-trustzone-sdk/optee-qemuv8-3.4.0/qemu'
make -C /home/laurencechan/rust-optee-trustzone-sdk/optee-qemuv8-3.4.0/build/../soc_term
make[1]: Entering directory '/home/laurencechan/rust-optee-trustzone-sdk/optee-qemuv8-3.4.0/soc_term'
gcc -o soc_term soc_term.o
/usr/bin/ld: soc_term.o: Relocations in generic ELF (EM: 183)
/usr/bin/ld: soc_term.o: Relocations in generic ELF (EM: 183)
/usr/bin/ld: soc_term.o: Relocations in generic ELF (EM: 183)
/usr/bin/ld: soc_term.o: Relocations in generic ELF (EM: 183)
/usr/bin/ld: soc_term.o: Relocations in generic ELF (EM: 183)
soc_term.o: error adding symbols: File in wrong format
collect2: error: ld returned 1 exit status
Makefile:9: recipe for target 'soc_term' failed
make[1]: *** [soc_term] Error 1
make[1]: Leaving directory '/home/laurencechan/rust-optee-trustzone-sdk/optee-qemuv8-3.4.0/soc_term'
Makefile:146: recipe for target 'soc-term' failed
make: *** [soc-term] Error 2

Good day!
In the signature_verification-rs example, an altered and Rust OPTEE compatible version of ring is used.
ring = { git = "https://github.com/veracruz-project/ring.git", branch = "veracruz", version = "=0.16.11", features = ["std"] }
I suppose this is done because the official ring crate is non-compatible, atleast ring = "0.16.11" does not compile for me.
I realize this probably means the official ring crate uses system calls.

How can one turn a non-compatible crate into a compatible one?
How much work is this usually?
Also, do you have any tricks to find any already altered and compatible versions of crates online?

Thank you!

I was following this blogpost, but replaced optee with higher version. When executing this command,

make QEMU_VIRTFS_ENABLE=y CFG_TEE_RAM_VA_SIZE=0x00300000

I encountered the following error message:

make[1]: Entering directory '/home/user/optee-qemuv8-3.18.0/qemu'
changing dir to build for make ""...
make[2]: Entering directory '/home/user/optee-qemuv8-3.18.0/qemu/build'
config-host.mak is out-of-date, running configure
bash: line 3: ./config.status: No such file or directory
make[2]: *** No rule to make target 'config-host.mak', needed by 'meson.stamp'.  Stop.
make[2]: Leaving directory '/home/user/optee-qemuv8-3.18.0/qemu/build'
make[1]: *** [GNUmakefile:11: all] Error 2
make[1]: Leaving directory '/home/user/optee-qemuv8-3.18.0/qemu'
make: *** [Makefile:236: qemu] Error 2

optee-3.14.0, which is mentioned in the blogpost, is OK.

Hi

In op-tee it's possible to use TEE API functions such as TEE_GetObjectBufferAttribute to fetch some attributes regarding the generated key however I could not find the function in the rust sdk.

Could you point me to an equivalent solution?

Thanks

The vote has been opened on:
https://lists.apache.org/thread/f3l82o89hb0w43n27nw77oqcpo829qjd

The following links:

• https://teaclave.apache.org/api-docs/trustzone-sdk/optee-teec/
• https://teaclave.apache.org/api-docs/trustzone-sdk/optee-utee/

referenced by both the "Docs" dropdown on the main Teaclave site and by this project's README go to a 404 page. The Internet Archive's last record of them working was on March 21st.

Could not find specification for target "aarch64-unknown-optee-trustzone"

Running <repo>/Makefile fails at aarch64-none-linux-gnu/bin/ld: cannot find -lteec .
I've added the directory which contains libteec.* to LIBRARY_PATH and LD_LIBRARY_PATH.

There is no out dir in project root dir after the previous actions. but only one out folder in /projcet/root/dir/optee_out/


if I force to do as the doc, I encoutered this

$ cp -r /home/laurencechan/bin/optee-qemuv8-3.4.0/*/out/* shared_folder/
$ make run-only QEMU_VIRTFS_ENABLE=y QEMU_VIRTFS_HOST_DIR=$(pwd)/shared_folder
ln -sf /home/laurencechan/bin/optee-qemuv8-3.4.0/build/../out-br/images/rootfs.cpio.gz /home/laurencechan/bin/optee-qemuv8-3.4.0/build/../out/bin/
ln: target '/home/laurencechan/bin/optee-qemuv8-3.4.0/build/../out/bin/' is not a directory: No such file or directory
Makefile:163: recipe for target 'run-only' failed
make: *** [run-only] Error 1

Hi, I've been trying to run the example program as described here but I am confused on what to be done in this step
mkdir shared && mount -t 9p -o trans=virtio host shared

Running it inside the qemu emulator results in error : Unrecognised command
Running it outside results in error : No Permission

Could you pls suggest what I might be doing wrong. Thanks

Hi

I wanted to take only the necessary part/libs to build TA using your SDK however it seems that your environment uses workarounds/patches to get examples building, especially building TAs (building host applications seems reasonable).

Is there a way to simplify the TA build?
I am thinking for example:

• avoid patching rust-lang, compiler-builtins and libc?
• use latest rust toolchains
• use pre-built optee libutee.a/libutils.a and libteec.so libraries (to avoid pull optee os/client)

If you think of a clean/minimal way of doing things, please share suggestions.
Thanks

The QEMU Wiki includes 2 invalid links:

1. the dependencies' instruction should refer to this page now: https://optee.readthedocs.io/en/latest/building/prerequisites.html.

2. The Dockerfile can't be found.

Hi! I make a little project with this rust-optee-trustzone-sdk.
But when I try to use extern crate like crypto or rand in TA, I can build the host and TA but it panic with generic errno, 0xffff0000.

How can I use extern crate in this sdk?
I know dynamic link is not allowed in TA, so I can't use other crate than optee_utee?

Error message in normal world is like this:
Error: Non-specific cause. (error code 0xffff0000)
and message in secure world is like this:

D/TC:? 0 tee_ta_init_pseudo_ta_session:299 Lookup pseudo TA 1234f200-2450-11e4-abe2-0002a5d5c51b
D/TC:? 0 ldelf_load_ldelf:91 ldelf load address 0x104000
D/LD:  ldelf:134 Loading TA 1234f200-2450-11e4-abe2-0002a5d5c51b
D/TC:? 0 ldelf_syscall_open_bin:140 Lookup user TA ELF 1234f200-2450-11e4-abe2-0002a5d5c51b (Secure Storage TA)
D/TC:? 0 ldelf_syscall_open_bin:144 res=0xffff0008
D/TC:? 0 ldelf_syscall_open_bin:140 Lookup user TA ELF 1234f200-2450-11e4-abe2-0002a5d5c51b (REE)
D/TC:? 0 ldelf_syscall_open_bin:144 res=0
D/LD:  load_main:1090 Reloading TA 1234f200-2450-11e4-abe2-0002a5d5c51b as legacy TA
D/TC:? 0 ldelf_syscall_open_bin:140 Lookup user TA ELF 1234f200-2450-11e4-abe2-0002a5d5c51b (Secure Storage TA)
D/TC:? 0 ldelf_syscall_open_bin:144 res=0xffff0008
D/TC:? 0 ldelf_syscall_open_bin:140 Lookup user TA ELF 1234f200-2450-11e4-abe2-0002a5d5c51b (REE)
D/TC:? 0 ldelf_syscall_open_bin:144 res=0
D/TC:0 0 abort_handler:518 [abort] abort in User mode (TA will panic)
E/TC:? 0 
E/TC:? 0 User mode data-abort at address 0x82b64c8 (translation fault)
E/TC:? 0  fsr 0x00000005  ttbr0 0x0e19786a  ttbr1 0x0e19006a  cidr 0x2
E/TC:? 0  cpu #0          cpsr 0x20000130
E/TC:? 0  r0 0x02060fcf      r4 0x0010f088    r8 0x0010f0b4   r12 0x00000000
E/TC:? 0  r1 0x00000000      r5 0x0010ee48    r9 0x00000000    sp 0x00103e80
E/TC:? 0  r2 0x0013258c      r6 0x0010ee44   r10 0x00000000    lr 0x00107d43
E/TC:? 0  r3 0x082b64c8      r7 0x00103e98   r11 0x00000000    pc 0x00107aa8
E/TC:? 0  region  0: va 0x00100000 pa 0x0e100000 size 0x001000 flags ---R-X
E/TC:? 0  region  1: va 0x00102000 pa 0x0e300000 size 0x002000 flags rw-RW-
E/TC:? 0  region  2: va 0x00104000 pa 0x0e302000 size 0x00b000 flags r-x---
E/TC:? 0  region  3: va 0x0010f000 pa 0x0e30d000 size 0x001000 flags rw-RW-
E/TC:? 0  region  4: va 0x00110000 pa 0x0e30e000 size 0x004000 flags rw-RW-
E/TC:? 0  region  5: va 0x00114000 pa 0x0e312000 size 0x001000 flags r--R--
E/TC:? 0  region  6: va 0x00115000 pa 0x0e313000 size 0x01e000 flags r-xR--
E/TC:? 0  region  7: va 0x00133000 pa 0x0e331000 size 0x00b000 flags rw-RW-
E/TC:? 0  region  8: va 0x0013e000 pa 0x0e33c000 size 0x001000 flags rw-RW-
E/TC:? 0 ldelf_init_with_ldelf:122 ldelf panicked
D/TC:? 0 tee_ta_open_session:720 init session failed 0xffff0000
D/TC:0   console_itr_cb:109 cpu 0: got 0x3

Hi

I am building a TA and want to use openssl on normal world side, when I add the following in host/Cargo.toml:

openssl = { version = "0.10", features = ["vendored"] }

I have the following error:

> ~/project/tee-rust » make -C examples/new_one/ && make examples-install 
make: Entering directory '/home/syedelec/project/tee-rust/examples/new_one'
make[1]: Entering directory '/home/syedelec/project/tee-rust/examples/new_one/host'
   Compiling proc-macro2 v1.0.43
   Compiling openssl-sys v0.9.75
   Compiling optee-teec-macros v0.2.0 (/home/syedelec/project/tee-rust/optee-teec/macros)
error[E0658]: use of unstable library feature 'proc_macro_is_available'
  --> /home/syedelec/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-1.0.43/src/detection.rs:28:21
   |
28 |     let available = proc_macro::is_available();
   |                     ^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: see issue #71436 <https://github.com/rust-lang/rust/issues/71436> for more information
   = help: add `#![feature(proc_macro_is_available)]` to the crate attributes to enable

For more information about this error, try `rustc --explain E0658`.
error: could not compile `proc-macro2` due to previous error
warning: build failed, waiting for other jobs to finish...
error: build failed
make[1]: *** [Makefile:39: host] Error 101
make[1]: Leaving directory '/home/syedelec/project/tee-rust/examples/new_one/host'
make: *** [Makefile:19: all] Error 2
make: Leaving directory '/home/syedelec/project/tee-rust/examples/new_one'

The same happens if I add manually serde in host/Cargo.toml. I saw that it's supported in serde-rs example. So in order to work with serde, I need to copy the serde-rs example and starts from there otherwise I have the same error.

Thanks

Hello

I want to create a persistent object from an initialized transient object however it did not seem to work and unfortunately there are no examples, the only examples concern creating a persistent object with initial data.

According to code documentation, this should be possible. Refer to code.

Here is a sample code:

let mut obj_id = [1u8; 1];
let obj_data_flag = DataFlag::ACCESS_READ | DataFlag::ACCESS_WRITE | DataFlag::ACCESS_WRITE_META;

let mut ec_key = TransientObject::allocate(TransientObjectType::EcdsaKeypair, 256).unwrap();
let attr_curve = AttributeValue::from_value(AttributeId::EccCurve, ElementId::EccCurveNistP256 as u32, 0);
ec_key.generate_key(256, &[attr_curve.into()])?;

match PersistentObject::create(
    ObjectStorageConstants::Private,
    &mut obj_id,
    obj_data_flag,
    Some(ec_key), // Do not work. What to put here?
    b"",
) {
    Err(e) => {
        return Err(e);
    }

    Ok(mut object) => {
        trace_println!("success");
    },
}

Thanks for your help.

when use rustc 1.57.0-nightly, can not use some libraries in crates.io:
error[E0658]: use of unstable library feature 'proc_macro_is_available'
--> C:\Users\PC.cargo\registry\src\mirrors.ustc.edu.cn-61ef6e0cd06fb9b8\proc-macro2-1.0.37\src\detection.rs:28:21
|
28 | let available = proc_macro::is_available();
| ^^^^^^^^^^^^^^^^^^^^^^^^
|

when use rustc rustc 1.58.0-nightly:
error[E0433]: failed to resolve: could not find UnsafeArg in fmt
--> /home/chuan/optee/out-br/build/optee_rust_examples_ext-1.0/rust/rust/library/core/src/macros/mod.rs:479:49
|
479 | ($dst:expr, $($arg:tt)) => ($dst.write_fmt($crate::format_args!($($arg))))
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ could not find UnsafeArg in fmt

 Running `/tmp/xargo.XfywwNRhXvRQ/target/release/build/unwind-357b03fc031273ae/build-script-build`

error[E0061]: this function takes 3 arguments but 4 arguments were supplied
--> /home/chuan/optee/out-br/build/optee_rust_examples_ext-1.0/rust/rust/library/core/src/macros/mod.rs:479:49
|
479 | ($dst:expr, $($arg:tt)) => ($dst.write_fmt($crate::format_args!($($arg))))
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| |
| supplied 4 arguments
| expected 3 arguments
|

Hello

I noticed a quite performance difference between TA written in Rust using the SDK and TA written in C

This can be easily reproducible using the simple random example.
In the example, a simple 16 bytes array is generated.

root@stm32mp1-board:~# time random-rs
Invoking TA to generate random UUID...
Invoking done!
Generate random UUID: 7db2031f-a7d1-6294-5ebb33c08f88101f
Success
real	0m 1.01s
user	0m 0.00s
sys	0m 0.99s
root@stm32mp1-board:~# 
root@stm32mp1-board:~# time optee_example_random 
Invoking TA to generate random UUID... 
TA generated UUID value = 0x76ed50d34af98d4b0b089e1921cad
real	0m 0.71s
user	0m 0.00s
sys	0m 0.70s

I tried with a normal world app that does the following:

• Generate Random 32 bytes
• Generate Random 64 bytes
• Hash "test" message with SHA256
• Hash "test" message with SHA384
• Hash "test" message with SHA512

The C TA performed the above in ~1.5sec and the Rust TA in ~6sec
I also tested to write the same normal world app in Rust and C but it gave the same results.

It has been tested on a stm32mp157c-dk2 board using OP-TEE OS 3.16.0

Let me know if you have an idea on the root issue.
Thanks

Hi,

I compile the hello_world example, targeting rpi3, and it pops:

D/TC:3 0 abort_handler:524 [abort] abort in User mode (TA will panic)
E/TC:? 0 User TA data-abort at address 0x481b8dfc (translation fault)

For comparison, there is no problem when I compile the TA in the hello_world example (in C) in optee_example, and then use the host program in the hello_example here (in Rust).

Specifically, by instrumenting the source code, I believe:

• the usafe call raw::TEEC_OpenSession in the new method in Session fail, returning 0xffff0000
• then it traces back to the call ioctl in TEEC_OpenSession in the source code tee_client_api.c contained in the optee_client/libteec dir.

I configure the rpi3, following the guide in optee; specifically, I use version 3.7.0.

Do you have any insight into this problem?

A TEE with remote attestation capability is required for it to function as a server, so I would like to ask if there are any plans for the Teaclave SDK to implement remote attestation capabilities?

I tried to build it with Xargo 0.3.26 and it failed.
I tried it with Xargo 0.3.22 and it works?

With Xargo 0.3.26 it says that aarch64-unknown-optee-trustzone may be not installed

Hello

I noticed that the ECDH shared secret derivation is not supported [TEE_ALG_ECDH_DERIVE_SHARED_SECRET 0x80000042]

Right now only the TEE_ALG_DH_DERIVE_SHARED_SECRET is supported
https://github.com/apache/incubator-teaclave-trustzone-sdk/blob/master/optee-utee/src/crypto_op.rs#L1548-L1549

Same for TEE_ALG_ECDSA_SHAXXX

In the TEE Internal GlobalPlatform API, it's specified if supported, is it related to the reason these are not supported?

My questions are:
What would be the approximate effort to implement these algorithms in the Rust SDK?
Do you plan on supporting these algorithms?

Thanks for your inputs

when execute "cargo install --git https://github.com/mssun/xargo.git --branch mssun/relative-patch-path --force"

I was playing with a TA built with teaclave SDK and got a panic when using the optional session_ctx parameter with a Vec inside of it.

It seems the mem::forget(b) call at https://github.com/apache/incubator-teaclave-trustzone-sdk/blob/master/optee-utee/macros/src/lib.rs#L393 also apply to the Err path and doing so indeed fixes the panic.

I am not sure if my logic is air tight. It would be great if someone could confirm.

Hello.

I am trying to instantiate a struct, App, in the TA and return it to the CA.
I've been using the rust examples as guidance and it seems that accessing data from the TA is done via the Operation parameters. From my understanding these parameters can only be of type ParamTmpRef or ParamValue. So bytes or u32.
Can i then only access values from the TA in the form of bytes or u32?

Is it not possible to return directly from invoke_command? In my approach below invoke_command returns an empty Result<()>.
CA:

TA:

It might be obvious to you that it's my first time working with a TEE, so I can suffer from misconceptions :)

Thankful for any help!

你好，想问一下关于target是optee得时候，工具链得情况

发现此项目得.cargo/config 只用到了链接工具，难道rs文件是不需要编译得吗？还是可以理解为rs文件还是用的rustc做编译，最后使用ld生成目标平台得可执行文件？

如果用ld，那么工程下依赖得库是如何链接进去得呢？

多谢回答

Hello,

I was looking through the code and saw that in the ta_destroy macro definition there's a boolean value that's ignored.

https://github.com/mesalock-linux/rust-optee-trustzone-sdk/blob/master/optee-utee/macros/src/lib.rs#L230

I think the outcome is that you're not checking the return type at compile time.