tpm2_protocol

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

https://github.com/puavo-org/tpm2_library

Known issues; two tests are failing They work when copy-pasted to cli without any change, when run in a temporary subcommand, Not sure what is going on but looking into over time. And not all subcommands are yet too well tested or polished ;-)

Features, reference and driver for this work is my earlier trial from 2014: https://github.com/ColinIanKing/tpm2-scripts

And partly this cover letter:
https://lore.kernel.org/linux-integrity/[email protected]/

[i was planning to update that patch set but was not happy with the
tools so i decided to make my own.]

With those constraints I learned by trial and error to use macro_rules and this the outcome. I'm looking forward to narrow the delta between static estimate and run time 'len()' over time.

This is designed as unipolar TPM protocol stack i.e. it's designed not only send commands and receive responses, but also send responses and receive commands.

BR, Jarkko

Unipolarity has been my design goal from the get go given that:

1. It enables high granularity filtering i.e. as capable or more capable resource managers in kernel as pre-existing user space resource managers (once the implementation has matured enough ofc but it has the core design principles right I think).
2. Software defined TPM devices e.g., in-kernel TPM emulators and interoperability layers for other crypto devices and confidential computing technologies. I'm not sure if anyone wants anything like this, just plain highilighting the possibilities.

BR, Jarkko