Upstream status for rustc aarch64-unknown-optee-trustzone target?

[b49020]

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

[Sword-Destiny]

I'm one of the main developers of teeos. There are many compatible interfaces between teeos and op-tee. It will be very nice if target 'aarch64-unknown-optee-trustzone' merged into the official rust toolchains. But we still have one MR waiting to be merged (std library support). TEE support for the Rust standard library is challenging, for there is no disk,network...... in trustzone. Maybe it would be more reasonable to only support no_std TAs.
I think most of the target 'aarch64-unknown-teeos' and 'aarch64-unknown-optee-trustzone' are the same. But op-tee may want a more specific name.

[b49020]

Thanks for your comments.

TEE support for the Rust standard library is challenging, for there is no disk,network...... in trustzone. Maybe it would be more reasonable to only support no_std TAs.

I am also leaning towards supporting no_std TAs (target: aarch64-unknown-none) for OP-TEE given there are many crates supporting no_std features too. We only need heap support and rest APIs are provided by GP internal APIs. I would like to hear from incubator-teaclave-trustzone-sdk project maintainers if they are aware of any gaps here.

I think most of the target 'aarch64-unknown-teeos' and 'aarch64-unknown-optee-trustzone' are the same. But op-tee may want a more specific name.

One of the difference I saw with aarch64-unknown-teeos is the threading support in TAs which isn't supported for OP-TEE based TAs. So if we really need to support std library then it should be a different target.

[Sword-Destiny]

I am also leaning towards supporting no_std TAs (target: aarch64-unknown-none) for OP-TEE given there are many crates supporting no_std features too. We only need heap support and rest APIs are provided by GP internal APIs. I would like to hear from incubator-teaclave-trustzone-sdk project maintainers if they are aware of any gaps here.

I have some experience with what need to implement:

1. heap support: We Can implement a simple global memory allocator which just call C function malloc,realloc and free
2. GP APIs: just use FFI to wrap C GP-APIs
3. panic handler: Can implement a simple panic handler which just call panic functions provided by OP-TEE (like TEE_Panic)

One of the difference I saw with aarch64-unknown-teeos is the threading support in TAs which isn't supported for OP-TEE based TAs. So if we really need to support std library then it should be a different target.

Yes

[DemesneGH]

Thanks for sharing valuable insights!

I am also leaning towards supporting no_std TAs (target: aarch64-unknown-none) for OP-TEE given there are many crates supporting no_std features too.

I agree that there are many crates supporting no_std features, but supporting std is necessary for other crates, such as Rustls (a widely used TLS crate). Porting std expands the range of crates available, would be more friendly for developers.

Are there any plans to make it an official target upstream?

To streamline maintenance efforts, we've chosen to pin the Rust version and port the std library. Adding the target to Rust upstream is a reasonable and aligns with future plans.

I think most of the target 'aarch64-unknown-teeos' and 'aarch64-unknown-optee-trustzone' are the same. But op-tee may want a more specific name.
So if we really need to support std library then it should be a different target.

Agree. If the target is eventually added to the upstream, I would prefer to maintain the name aarch64-unknown-optee-trustzone for consistency.

I have some experience with what need to implement

Thanks for sharing the experience of upstreamaarch64-unknown-teeos, it will be good reference for us.

[b49020]

I agree that there are many crates supporting no_std features, but supporting std is necessary for other crates, such as Rustls (a widely used TLS crate). Porting std expands the range of crates available, would be more friendly for developers.

Have you tried porting TLS crate within a TA? It is something similar when people ask about OpenSSL support in TA [1]. We should understand that OP-TEE environment is constrained:

• Limited TA memory resources (upto few megabytes)
• No user-space threading support
• Limited networking support (GP TEE sockets interface)
• No direct filesystem storage
• Limited secure storage (GP TEE secure storage interface)

The other thing to take care here is one of the OP-TEE design goals: Small footprint [2]. We should only try to port security sensitive portions of a normal world application to a TA. Otherwise if you port your entire application as TA then the real isolation benefit is somewhat lost.

So what if you try to integrate a crate which will build due to std availability but fails at runtime due to unsupported features mentioned above. It is a similar scenario we have on the C counterpart side. We don't support the fully fledged libc as glibc but our own minimal implementation libutils which is sufficient for TA requirements.

IMO, we should also follow similar approach with rust. Start with no_std first and then if there are real use-cases that pops up and need std support we can have our minimal libstd similar to the Zephyr case [3].

[1] OP-TEE/optee_os#5884
[2] https://optee.readthedocs.io/en/latest/general/about.html#about-op-tee
[3] https://github.com/tylerwhall/zephyr-rust

[DemesneGH]

We should only try to port security sensitive portions of a normal world application to a TA. Otherwise if you port your entire application as TA then the real isolation benefit is somewhat lost.

Start with no_std first and then if there are real use-cases that pops up and need std support we can have our minimal libstd similar to the Zephyr case

I understand your perspective. BTW I think it will also help to reduce the memory cost of Rust TAs.
If you're interested in collaborating on this, any contribution will be appreciated. Thanks!

[Sword-Destiny]

We should only try to port security sensitive portions of a normal world application to a TA. Otherwise if you port your entire application as TA then the real isolation benefit is somewhat lost.

Start with no_std first and then if there are real use-cases that pops up and need std support we can have our minimal libstd similar to the Zephyr case

I understand your perspective. BTW I think it will also help to reduce the memory cost of Rust TAs. If you're interested in collaborating on this, any contribution will be appreciated. Thanks!

The most effective way to reduce the size of TA is no_std and strip. There are other ways, such as:

[profile.release]
panic = "abort"
opt-level = "z"
lto = "fat"
debug = false
strip = "symbols"
codegen-units = 1