tpm2_protocol
Jarkko Sakkinen <[email protected]> Tue, 12 Aug 2025 15:59:25 +0300
| Newsgroups | dev.linux.lists.tpm2,org.kernel.vger.linux-integrity,org.kernel.vger.rust-for-linux |
|---|---|
| Message-ID | <[email protected]> |
I came up with this within 1,5 weeks not much sleep, and thought that
this might be interesting to all of the three lists:
tpm_struct!(
#[derive(Debug, PartialEq, Eq, Clone)]
TpmPcrEventCommand,
TpmCc::PcrEvent,
TpmSt::Sessions,
1,
{
pub event_data: Tpm2b,
}
);
tpm_response!(
#[derive(Debug, Default, PartialEq, Eq, Clone)]
TpmPcrEventResponse,
TpmCc::PcrEvent,
TpmSt::Sessions,
{
pub digests: TpmlDigestValues,
}
);
[tpm_struct is also used for data types, it so just happend that it
equally works for commands, every single type in depth shares the
same core marshalling and unmarshalling infrastructure]
It's a zero deps, no-alloc and no_st crate which unamrshals the full TCG
specification to both directions. I.e. you can build a TPM emulator
alike thing "in a day", and not just interface with a chip. As it runs
also on bare-metal (it's a stack allocated entity), it would scale even
to chip firmware.
I targeted this for Linux kernel, and thus the design choices. I just
thought what would be the part that would trigger me most if someone
submitted a Rust driver, and implemented it myself. Learning from what
I've seen basically :-) I totally support someone making a Rust driver
and I thought this in-depth understanding of the protocol is my best
possible contribution for such effort (binding IO shenanigans not so
much). E.g. you could use this to do a way better /dev/tpmrm0 than what
exists today with high-fidelity filtering and shit.
Obviously I hope to be a co-maintainer if such thing ever happens.
Since it is also independent crate it can be e.g., used to build
interoperability layers and stuff like that.
There's also a cli called simply "tpm2". I'll probably make it alll
available today or tomorrow.
BR, Jarkko