Re: Using Rust on non-Rust side of kernel

[Jarkko Sakkinen <jarkko@kernel.org>]

On Tue, Aug 26, 2025 at 01:29:59AM +0300, Jarkko Sakkinen wrote:
> I am going to most likely make experiments with kernel and most
> definitely make "tpmtrace" (a tool that hooks to BPF ring buffer and
> pretty prints the protocol in real-time, it's dead easy to do now).
> Finally (as I've said before) it would be quite unproductive to create a
> design that does not upscale to let's say to an attestation server
> (which would use this to parse e.g. quotes) or downscale to a chip.

Considering existing TPM C driver, Linux keyring (from trusted keys
angle and likely in future from imported asymmetric keys angle) and
security stuff overall in kernel, this work really can fuel up both
developer and debuging experience. I.e. my motivation is really 180
degrees opposite than deleting anything :-) [maybe that's why I got a
bit upset]

And doing tools like tpmtrace will quickly level up the feasibility in
production through stress testing in the field. And as I improve tpm2sh
(which I don't yet recommend anyone to use, it's so far just quickly
upgraded to test the protocol changes, I'm now stabilizing it ) we can
better evaluate different choices given better toolkit that will
consequently reduce the number of wrong decisions.

Like in pretty basic kernel testing it's not too feasible to package
something tpm2-tools to an image that you build (I do full rootfs
per kernel patch when testing) but something like tpm2sh and in
future tpmtrace are much more nicer blobs given how rust ELF images
are constructed and linked. Downscaling of the stack  has been 
a QA issue for ages now.

BR, Jarkko