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
