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

In tpm2-protocol 0.11 requirement for requiring a working stack are heavily relaxed.

In the current stable (0.10.x) memory interaction can be broken down as follows:

1. There is no internal buffering, meaning that internal state does not consume stack.
2. The result is stored in stack.

In the next version (0.11.x) the memory semantics reduce into:

1. Like in the previous version no internal buffering.
2. There's neither parsing nor building. The macros generate a set of interfacs and all parts can be observed with a set of macro generated traits. This builds on the foundation of the DSL developed for describing TCG specs.

I.e. absolutely minimum requirements to run it are:

1. ROM
2. CPU or microcontroller with reasonable register space.

The first (unpolished) piece of puzzle in rewriting tpm2-protocol in 0.11 to be 100% zero copy:

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

#linux #kernel #tpm #rust

Extended the documentation for contributions, especially mailing list usage, given some queries:

https://crates.io/crates/tpm2-protocol/0.10.13

#linux #kernel #tpm #rust

this pretty well summarizes all:

https://github.com/tpm-rs/tpm-rs/issues/197

I also described an example application in order to enlight why all this makes whole a lot of sense.

#linux #kernel #rust #tpm

While tpm2-protocol feels really stable tpm2sh is still somewhat unstable and has bunch of bugs here and there. It is expected, as tpm2sh served only as a dumpster for test code while developing the protocol crate.

Now that I don't do active development on tpm2-protocol, I'm going to make the first actually somewhat stable 0.11.0 release of tpm2sh.

It has quite verbose interface, which will break also easily for that reason. Thus, before pursuing seriously to the possible bugs, I developed MockTPM, a simple TPM emulator that is used as the "TPM end" for subcommand integration tests..,

#linux #kernel #rust #tpm

there's this infosec researcher personality archetype whose only social media activity is to repost shit about random and uninteresting vulnerabilities

tpm2-protocol is the first thing i've done with Rust which would not be existentially possible achieve without some of the Rust features.

With TPM protocol shenanigans people tend to go generation path because writing all data types manually would be ridiculous amount of work.

By creating DSL with macros, "ridiculous" factored down to "huge" but only for the initial pass i.e., to reach the current TCG standard version. And given that I have now efficient DSL, keeping the implementation up to date is almost cost-free. And since none of the compiled code is a generation artifact, it is easy to "shift away" in selected places, and write down traits manually.

https://github.com/puavo-org/himmelblau-dev

I’m working on a bash and Makefile based project called “himmelblau-dev”, which provides low-barrier entry point to start contributing to that upstream project. I have not really contributed to that project much because there is no a meaningful edit-compile-run-cycle and that is what I’m resolving with this project.

I’ve taken a lot of trouble to not use containers, not even in the build, because containers always mean looking for problems when translating a development environment from one machine to another.

[To be completely honest, for any possible project I interpret “I have to use a container” into “my solution is going to be a trainwreck”]

Instead, I do the build with a combination of deboostrap and guestfish tricks. The project has makefile targets for running resulting QCOW2 in QEMU, contains a settings file (parser implemented in bash) and automatic download of OVMF images and logic for managing EFI vars file.

It’s a bit like embedded build system centered around a single upstream project.

Layout right now:

❯ tree
.
├── bootstrap
│   ├── settings.sh
│   └── start.sh
├── config
│   ├── debian.sh
│   ├── himmeblau.sh
│   └── start.sh
├── himmelblau.version
├── Makefile
├── qemu.json
├── README.md
└── vm
    ├── qemu.sh
    ├── start.sh
    └── swtpm.sh

I need to fine-tunet his for a while still before I publish it. It’s all GPL3 license as I see no point of using any other license for this.

qemu.json is just my own ad-hoc VM configuration format:

{
  "args": {
    "enable-kvm": true,
    "machine": "q35,accel=kvm",
    "cpu": "host",
    "memory": "4G",
    "rtc": "base=localtime"
  },
  "networking": {
    "user": [
      { "netdev": "user,id=net0,hostfwd=tcp::10022-:22" },
      { "device": "virtio-net-pci,netdev=net0" }
    ],
    "bridge": [
      { "netdev": "bridge,id=net0,br=br0" },
      { "device": "virtio-net-pci,netdev=net0" }
    ]
  },
  "tpm": {
    "enabled": true,
    "tpmdev": "emulator,id=tpm0,chardev=chrtpm",
    "device": "tpm-tis,tpmdev=tpm0"
  },
  "drives": [
    {
      "if": "pflash",
      "file": "OVMF_CODE.fd",
      "format": "raw",
      "readonly": "on"
    },
    {
      "if": "pflash",
      "file": "OVMF_VARS.fd",
      "format": "raw"
    },
    {
      "file": "himmelblau-demo.qcow2",
      "format": "qcow2"
    }
  ]
}

#azure #intune #himmelblau