ivila commented on issue #273:
URL:
https://github.com/apache/teaclave-trustzone-sdk/issues/273#issuecomment-5403777193
I agree that my previous as_slice / as_mut_slice design does not properly
model REE-controlled MEMREFs. Since the backing memory may be modified outside
the TEE, exposing it as a normal Rust &[u8] / &mut [u8] imposes reference
invariants that we cannot reliably uphold.
I think a better API would be to keep the MEMREF opaque and expose only
explicit copy operations corresponding to the parameter direction, for example:
```rust
impl ParameterMemref Input {
pub fn copy_to(&self, dst: &mut [u8]) -> Result<()> {
// REE MEMREF -> TEE-owned buffer
...
}
}
impl ParameterMemref Output {
pub fn copy_from(&self, src: &[u8]) -> Result<()> {
// TEE-owned buffer -> REE MEMREF
...
}
}
impl ParameterMemrefInout {
pub fn copy_to(&self, dst: &mut [u8]) -> Result<()> {
...
}
pub fn copy_from(&self, src: &[u8]) -> Result<()> {
...
}
}
```
With this design, the REE-controlled memory is never exposed as a Rust
reference. The raw MEMREF stays encapsulated inside the parameter object, while
&[u8] / &mut [u8] are only used for TEE-owned buffers.
This also maps naturally to TEE_PARAM_TYPE_MEMREF_INPUT, OUTPUT, and INOUT:
the Rust API exposes only the operations permitted by the parameter direction
rather than pretending the underlying memory is an ordinary Rust slice.
I think this addresses the main soundness issue with the previous API while
keeping the interface reasonably ergonomic. Does this abstraction look closer
to what you had in mind?
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
