tpm2_protocol

tpm2_protocol

[Jarkko Sakkinen]

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

Re: tpm2_protocol

[Jarkko Sakkinen]

On Tue, Aug 12, 2025 at 03:59:25PM +0300, Jarkko Sakkinen wrote:
> 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:

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/20240528210823.28798-1-jarkko@kernel.org/

[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

Re: tpm2_protocol

[Jarkko Sakkinen]

On Wed, Aug 13, 2025 at 03:40:27AM +0300, Jarkko Sakkinen wrote:
> 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.
 
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