Just solved a Rust sudoku for the next version of tpm2-protocol

I think this is quite clever trick to surpass some of the limitation of syntax tree macros:

macro_rules! tpm_integer {
    ($ty:ty) => {
        pub mod $ty {
            #[derive(Clone, Copy, Debug)]
            pub struct TpmView<'a> {
                pub slice: &'a [u8],
            }
        }
    };
}

Further, TpmView implements a trait called TpmView. This circulates around limitation that type cannot be used to name things in syntax tree macros.

Otherwise, unless moving into procedural macros, I’d end up ugly declarations along the lines of:

tpm_integer!(u8, TpmViewU8, Unsigned);
tpm_integer!(i8, TpmViewI8, Signed);
tpm_integer!(u16, TpmViewU16, Unsigned);
tpm_integer!(i32, TpmViewI32, Signed);
tpm_integer!(u32, TpmViewU32, Unsigned);
tpm_integer!(u64, TpmViewU64, Unsigned);

Transparency has been the single biggest blocker in moving forward with zerocopy parser and this sort of “nails it”.

EDIT

I was wrong in that you could type as module name. However, the trick does still resolve the name coflict with the original type and view type. The minor inconvience of having to repeat it twice is totally acceptable vs having to manually name stuff:

tpm_integer!(u8, u8, Unsigned);
tpm_integer!(i8, i8, Signed);
tpm_integer!(u16, u16, Unsigned);
tpm_integer!(i32, i32, Signed);
tpm_integer!(u32, u32, Unsigned);
tpm_integer!(u64, u64, Unsigned);

This is absolutely sustainable for me :-) I.e. second parameter is name of the module.

Here’s a working proof of concept: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?h=zerocopy&id=42f61d9d85e17f784f71c8ac64ee6adbb7171997

#rust #rustlang

zmodem2 0.1.4 release with split subproject "zmodem2-bin" (cargo install zmodem2-bin).

#rust #zmodem #tty #serial

The policy module in tpm2sh is growing enough meaning that I will eventually fully decouple it and introduce 'tpm2-policy' crate.

Just like tpm2-protcol, this is a mailing list project and will be hosted at git.kernel.org.

'tpm2-policy' provides an expressive language for policies and can additionally "open code" input expressions e.g., set actual values for PCRs (if they are unspecified and digest is composed it queries them from TPM).

It can compose digests both via means of TPM2_Policy* command but in addition is capable for software composition (not yet landed tho but coming soon ;-))

The big picture design principle in this crate is, just like in tpm2-protocol, that it scales both to client use, and at the same time software composition engine is capable of empowering TPM emulator or even a real chip.

#linux #rust #tpm

In tpm2-protocol, extended "response round-trip" test to understand crate's error codes with the worst parser ever written:

0176 Success 80010000002000000000800200000010bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
017E TrailingData 800100000038000000000000000100000000000000010020aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaadeadbeef
0144 NotDiscriminant("TpmSt", Unsigned(0xffff)) ffff0000000a00000000
0176 Success 80010000003000000000030000000020ab967bc21b9c90096051d1e0f0dbfb29fc27258b03705fbc0c40aaaac88ed5e5

This also helps to better understand whether the pre-existing error codes make sense, how they should be modified, what should be added/removed etc. in the future versions of this crate.

There's no separate "pcr-read" command anymore in tpm2sh as policy command is robust enough to address that task too:

❯ sudo target/debug/tpm2sh policy "pcr(sha256:0,7)"
pcr(sha256:0,7, 9c367f8c268d51ced151a664d88e37e74fcd84485eff8ff9bc26d22aa9091020)

With --compose flag it creates the policy digest.

The goal in in tpm2sh 0.11 is to repeal and replace the pre-existing uses of tpm2-tools to enable things like PCR sealed hard drive encryption. I'm focusing on smooth and for a sysadmin type of a person common sense type of flow.

It's more like UI problem than a technical problem. A great cli is such that you can put it powerpoint sheet and everyone will get it down to reconfiguring your computers.

#tpm #rust #linux

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?id=f085a5107eb140c1708a0e9ec11e4c3b4aa962ca

Migrated few more tests to data-driven format and renamed the original test tool as 'adhoc.rs' for tests that don't fit to the data-driven framework (yet).

I think this will cage the implementation right way and over time the factor to break it will grow...

A literally WYSIWYG pattern for command-line usage and help where each subcommand has a directory with 'mod.rs', 'usage.txt' and 'help.txt':

- Text files are more readable than code generation (unless you are a compiler).
- Text files has factors better outreach than code generation.
- Text files are non-executable read-only data.
- A bug in a static text file is a typo. Typo is a distraction for sure, but it does not radiate software bugs.
- The factor it simplifies command argument processing is much heavier than some minor redundancy that using text files introduces.
- Text files can be read without building a project.

#rust #clap #lexopt

Zerocopy will be easy to implement now that I’ve found out how it is done by experimenting with basic types.

Memory requirements are relaxed as in:

1. Before (0.10.x): stack is required for the artifact
2. After (0.11.x): a CPU with registers will do for the memory, and read-only address for the input data.

70-80% of code base will be re-usable and remaining 20% is rewriting macros, tweaking a few call sites and creating a few new traits for macro consumption.

Despite 0.10.x having clone semantics, it is the correct traversal that is the hard problem here and it needs to be solved only once that data can be used to inject slice markers to exactly correct locations. This is why also parsing or building process nees no extra memory other than CPU cores registers.

The number lines in implementation will with higher odds go down rather than up. Looking pretty good…

#rust #linux #tpm

Procedural macros: how to get started? How they play with compiler? How can I, or can I use them with rustc w/o cargo?

I'm specifically not interested on "how to program proc macros tutorial". At this point more about "geometry" and how they link and in essence all bin related info.

#rust #cargo #macros

It took a lot of effort but now all parts of running TPM2_Import are fixed in both tpm2sh and TPM2_Import and integration tests runs perfectly.

Last fix: https://github.com/puavo-org/tpm2sh/commit/3627530516fdcc8739b3c7aea6fab6a136201bfa

It's a bidirectional test where both the client and the emulator are based on tpm2-protocol. The other side sends commands and parses responses, and the other side send responses and parses commands.

Given the fair amount of software crypto involved to perform any possible bidirectional handshake it is shows off pretty well how robust the implementation is.

#rust #tpm #linux

now "algorithms" is exact description of the available hardware algorithms:

❯ sudo target/debug/tpm2sh algorithms
ecc:bn-p256:sha256
ecc:nist-p256:sha256
keyedhash:sha256
rsa:2048:sha256

it queries the hardware correctly and for RSA it also runs TPM2_TestParms to verify the bit sizes. it was surprsingly hard to get this right but i'd guess this might be even most accurate tool on doing this task (not because it is great but because available software sucks).

I first used clap in tpm2sh, then switched to lexopt and again back to clap because of too much boilerplate code.

The problem I run every single time with clap is how hard it is to control if you actually want to control in detail.

Now I found the ultimate compromise for my situation:

1. I pre-rendered from clap usage and help to usage.txt and help.txt for each subcommand.
2. I changed my subcommands as directories. E.g., from "create-primary.rs" to "create-primary/mod.rs".
3. I deployed the text files to associated directories.
4. Finally I migrated parsing back lexopt.

Intial commit:

59 files changed, 538 insertions(+), 521 deletions(-)

Not too bad. WIth only parsing is just super complicated tool to do that task, or more complicated than necessary, and lexopt adds visibility to code paths so it is overall much more maintainable :-)

Also few redundant edits every once in a while to two txt files per subcommand is IMHO much more maintainable than adjusting generation from the source code.

After fixing a few bugs where resolution repeats a common pattern I created these

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?id=f5e0e82aaad3135be73c3f7a35aaec08e78cfe7c

I.e. if a command or response acts weird the dump can be put either "response.txt" or "command.txt" and roundtrip parse-build-compare will be peformed when running either "cargo test" or "make test".

https://sources.debian.org/src/dracut/108-3/test/TEST-70-ISCSI/ibft.pl#L180

#saatana #finland #perkele #satan

this was hell to fix and locked me from progressing with my swTPM called MockTPM:

https://lore.kernel.org/tpm-protocol/20250902165455.3680143-1-jarkko@kernel.org/

Fixed in https://crates.io/crates/tpm2-protocol/0.10.21

Once MockTPM is mature enough I use it also as the unprivileged default backed for tpm2sh.

That enabled two useful features:

1. Dry-run TPM operations with tpm2sh against swTPM with support also for e.g. persistence.
2. Windows and macOS support! They just compile out device parameter and use MockTPM unconditionally.

#linux #rust #tpm

I have now a single unified expression language in tpm2sh, which is used in all PCR and policy commands.

You can e.g., express crazy things like or(pcr("sha256:0"), secret(tpm://0x40000001)) with it for instance.

I’ve replaced three separate pest parsers with a single unified nom parser. So much manual control was required anyhow so that diff was pretty much +- 0.

#rust #tpm #linux

I still need to update tests/runner.rs but this bug took quite a long time to address properly and also this commit message really required effort :-)

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?h=queue&id=4efa57b484039b8fa9fb41b647b11b623e60fcde

I actually had to re-learn partly how my own software works but it all looks like fairly sound and logical to me :-) Was a good mental exercise really.

#linux #rust #tpm

That pipeline system is gone in tpm2sh. It's now about tags such as "tpm://80000001", "data://base64,..." etc. and expressive policy language which is used by everything from pcr functionality to policy definitions.

Had to do the cli extremely wrong, unintuive and pain to maintain to discover what would be actually right in this case. No one has really ever though how to make TPM2 nice to use from command-line so this part of the process :-)

LF these days is like the prime definition of corporate crap:

https://bsky.app/profile/linuxfoundation.org/post/3lxu6seyxzc2m