GithubHelp home page GithubHelp logo

Comments (7)

Sword-Destiny avatar Sword-Destiny commented on July 16, 2024 1

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

from incubator-teaclave-trustzone-sdk.

Sword-Destiny avatar Sword-Destiny commented on July 16, 2024

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.

from incubator-teaclave-trustzone-sdk.

b49020 avatar b49020 commented on July 16, 2024

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.

from incubator-teaclave-trustzone-sdk.

Sword-Destiny avatar Sword-Destiny commented on July 16, 2024

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

from incubator-teaclave-trustzone-sdk.

DemesneGH avatar DemesneGH commented on July 16, 2024

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.

from incubator-teaclave-trustzone-sdk.

b49020 avatar b49020 commented on July 16, 2024

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

from incubator-teaclave-trustzone-sdk.

DemesneGH avatar DemesneGH commented on July 16, 2024

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!

from incubator-teaclave-trustzone-sdk.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.