tpm2_protocol / tpm2sh 0.9.0

Hi

0.9.0 is the first "feature complete" version of tpm2_protocol except couple of minor glitches.

Errata:

1. SetCapability due this remark below table 137 in the Structures specification:

"The TPMU_SET_CAPABILITIES Structure may be defined by a TCG Registry."

2. No TPM_CC_MAC defined as its code conflicts with TPM_CC_HMAC reasoned with the most illogical reasoning ever in the end of section 5.2 of Structures specification:

"A TPM can implement either TPM2_HMAC()/TPM2_HMAC_Start() or TPM2_MAC()/TPM2_MAC_Start() but not both, as they have the same command code and there is no way to distinguish them. A TPM that supports TPM2_MAC()/TPM2_MAC_Start() will support any code that was written to use TPM2_HMAC()/TPM2_HMAC_Start(), but a TPM that supports TPM2_HMAC()/TPM2_HMAC_Start() will not support a MAC based on symmetric block ciphers."

I.e. reasoning that tells no reasons for overriding a CC, which here is the problem, not the "xor relationship" between these commands. Neither all other commands work on all TPMs but still they don't share the same magic cookie.

I started this project originally in 2024 then I got quickly stuck. After one year of processing how to do it the result is no_std, zero dependency crate, which does not require memory allocator. It can empower both chips, clients, emulators and operating systems. Even tho most of the code was written in three weeks (11K of 12K for both protocol and client) the ideas have been developing for a long time.

Next steps are of course slimming up and tightening the implementation as there must be extra fat scattered here and there, and fix the bugs. Response handling has a few scoped rough edges that I will look into first. I think also (and have experience on the topic further to back it up) that this after maturizing is the solution also for Linux kernel.

Unlike other TPM2 tools and alike tpm2sh is not designed for human readable output but instead a programming interface for bash and similar (e.g. it could be used to enhance tools like 'pass') but I've developed a human solution i.e. "print-stack" command so it is the demo for this release:

❯ sudo ./target/debug/tpm2sh create-primary --alg rsa:2048:sha256 | sudo ./target/debug/tpm2sh pcr-read "sha256:0" | sudo ./target/debug/tpm2sh print-stack

⠦ Waiting for TPM...
⠏ ✔ TPM operation complete. Type: pcr-values
Update Counter: 86
Bank (sha256):

    PCR 0: b9a5bf5fc2ffbca9b75f75567c84d1f660d4a77d1413f7a4b15de162cd27e6f0
Type: context
  Context:
    Sequence: 0x8b
    Saved Handle: 0x80000000
    Hierarchy: TPM_RH_OWNER

Now it's time to a short break (ignored other life to get this vomitted out) ... :-)

BR, Jarkko

Also tpm2_protocol byte granular precision in its understanding of the protocol.

We don't need to validate anymore just length or trivial metrics like that. The power of Rust here is really that we can structurally say what "is" and what "is not".

It's not just a security property. It increases the overall stability of the system. One particular benefit that it gives for kernel hacking is the ability in some cases to differentiate the stimulus of a bug between kernel, hardware and firmware.

My crate takes byte granularity seriously. E.g. day ago I noticed that spec had enums with signed discriminants, which I hadn't paid attention but compiler reminded me of that by complaining that building and parsing traits were not available for 'i8' :-) (it event has separate building and parsing traits for u8).

BR, Jarkko