b49020 commented on issue #113: URL: https://github.com/apache/incubator-teaclave-trustzone-sdk/issues/113#issuecomment-1824164889
> 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] https://github.com/OP-TEE/optee_os/issues/5884 [2] https://optee.readthedocs.io/en/latest/general/about.html#about-op-tee [3] https://github.com/tylerwhall/zephyr-rust -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@teaclave.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@teaclave.apache.org For additional commands, e-mail: dev-h...@teaclave.apache.org
