tpm2_protocol

[Jarkko Sakkinen <jarkko@kernel.org>]

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