Comments (7)
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 needstd
support we can have our minimallibstd
similar to the Zephyr caseI 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.
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.
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.
I am also leaning towards supporting
no_std
TAs (target:aarch64-unknown-none
) for OP-TEE given there are many crates supportingno_std
features too. We only need heap support and rest APIs are provided by GP internal APIs. I would like to hear fromincubator-teaclave-trustzone-sdk
project maintainers if they are aware of any gaps here.
I have some experience with what need to implement:
- heap support: We Can implement a simple global memory allocator which just call C function malloc,realloc and free
- GP APIs: just use FFI to wrap C GP-APIs
- 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 supportstd
library then it should be a different target.
Yes
from incubator-teaclave-trustzone-sdk.
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 supportingno_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 supportstd
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.
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.
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 needstd
support we can have our minimallibstd
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)
- (Solved) Failed to build example HOT 3
- (Solved) Failed to build repo with optee-3.18.0 HOT 3
- Create a persistent object from an initialized transient object HOT 8
- API doc links broken HOT 3
- Will this library support remote attestation? HOT 1
- Missing mem::forget(b) in TA_InvokeCommand() error path? HOT 3
- rustc version 1.57 or 1.58
- Failed to spread pgdir on small tables
- Signature Verification example using ring crate HOT 2
- Get Public/Private key from generated key in TA HOT 2
- Use openssl/serde in host app HOT 2
- Xargo Version? HOT 1
- ECDH shared secret derivation HOT 6
- Performance issues HOT 1
- ./hello_world-rs not found in shared folder HOT 6
- make optee: fatal error: uuid/uuid.h: No such file or directory HOT 6
- Question: returning data from the TA
- Error: Unresolved import 'self::inner'
- Question: Third party crates HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from incubator-teaclave-trustzone-sdk.