On Sat, Aug 23, 2025 at 11:38:00AM -0300, Daniel Almeida wrote: > My somewhat limited understanding here is that you’re trying to implement Rust > code that can be called from the rest of the kernel, but that otherwise > doesn’t > depend on it?
OK so please fill me up with rest of the email I'll respond to this uncluttered part. First of all, it's fully TCG spec complete in-stack implementation with no dependencies, does not use allocator, no_std all implementation, which can run even on bare metal and could empower chips. tpm2_protocol generates bidirectional parsers and builders to both directions. It purposely does not share anything with the environment. The gist here is that given the implementations of properties this could be used as shared entity between kernel and TPM-RS project, which would give a single shared project, which would be anyhow "same same" if they had separate implementations. Not being dependent on kernel code would make it also applicable to early boot code because you can put it anywhere, or link against anything. E.g., perhaps Trechnboot could be one of such use case because for that we need to find model where protocol is needed without having TPM driver in the first place. For TPM driver itself it would increase stability because the crate gives guarantees on structural integrity vs looking at just "max length". > > > If so, I did try something similar [0]. Perhaps this is useful to you and is > somewhat applicable to your use case as well? Thanks! I will look into this :-) I'm not like pushing anything this just early querying what are options for the future. I.e is Rust code enforced live its own cage or are there options for doing "hybrid solutions". I'm only starting to learn of the possible integration options. I.e. not even debating of anything, only learning. > > [0]: https://lwn.net/Articles/970565/ > > BR, Jarkko
