Trussed memory usage

[arturkow2000]

Hello, we are having an issue where Trussed consumes large amounts of stack. The problem happens when constructing a before calling into Trussed.
To construct a message we need to allocate it on stack, since all types must have size known at compile-time, Trussed defines limits in config.rs. Now, when we want to, let's say we want to hash some data:

trussed::syscall!(trussed.hash_sha256(&[1]));

Internally, hash_sha256 calls the hash() functions which accepts Message instead of &[u8], this causes allocation of MAX_MESSAGE_LENGTH which currently is 1 KiB, just to copy that data into IPC buffer. Usually when optimizations are involved, some functions may be inlined, if hash_sha256 get's inlined, this may worsen the problem, as the stack won't be freed until execution exits from the current function. Now, when we call into Trussed, Trussed copies this data onto stack, doubling stack usage.

Things quickly get worse when limits are increased (we had to increase limits due to lack of support for reading/writing files in parts).

Ideally, Trussed APIs should be changed in such a way to allow initialization of IPC buffer in-place. Also, the data returned from Trussed shouldn't be explicitly copied onto stack, instead it should be possible to process the response directly from IPC buffer.

[sosthene-nitrokey]

This was discussed when implementing extensions: #70 (comment)

This could be a significant improvement regarding stack usage, but it would also be a breaking change.
I think it would make sense to use references as part of the builder API we discussed in the past: #71 (review)