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
