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

second patch through list https://lore.kernel.org/tpm-protocol/20250831150145.386502-1-jarkko@kernel.org/T/#u

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

@amackif for this i just read the Rust documentation and for TCG specs I have 11 years familiarity so it's then it was just basically synthesis of those. As the word is defined you need to have a deep understanding of the domain really. From that angle, it is also impossible question to give any correct answer.

@amackif I have no idea tbh.

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

I'm working on a mocked TPM for tpm2sh integration tests (still heavily WiP just had to put the first checkpoint):

https://github.com/puavo-org/tpm2sh/blob/main/src/bin/mock-tpm.rs

Even at this point it still demonstrates how easy it is to get ongoing with previously as complicated task as writing a TPM emulator.

#linux #kernel #tpm #rust

I have ML now: https://lore.kernel.org/tpm-protocol/

Patches and discussion: tpm-protocol@lists.linux.dev

More information: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/tree/README.md

#linux #kernel #tpm #rust

Since GlobalAlloc is not required from the get go it's easy to get from nothing to something with enclaves as stack will do (and obviously data and rodata are cool too, they don't require alloc).

It also means that one can be light on run-time if wanted and compile-time decided memory pool is good enough (placed in .data). This relaxes the SDK requirements quite a lot as with enclaves (for any technology) allocating new pages from untrusted host is super complex and involved process. Static memory size generally tends to also improve both security, privacy and availability properties of ANY piece of software.

This is the gist how you would go on implementing TPM emulator, or vTPM inside confidential computing (SGX, SNP, TDX) enclave:

#linux #kernel #rust #tpm

TBH, it would best for QEMU if it merged swtpm/libtpms code at some point. That would lower the barrier to implement emulation for e.g., fTPM behind ARM FF-A.

Normally software that uses TPM2 creates integration tests by setting up e.g., swtpm.

Once I land the fix for ATM broken tpm2sh import, I'll also add tests/commands.rs, which will demonstrate how you can use tpm2-protocol crate to mock the TPM device.

If you want to take the test to the device level, tpm_vtpm_proxy can be used for this purpose (a driver by Stefan Berger who has also created the awesome swtpm, which is *obviously* the ultimate solution with QEMU) .

#linux #kernel #tpm #rust

zero issues advertising this as i think it really does right things right:

https://github.com/himmelblau-idm/himmelblau/issues/662

buffering and parsing this protocol stream is just one thing i have pretty solid grip off so why not make best of it

the uncrowned king of RS-232 file transfer protocols: https://en.wikipedia.org/wiki/SMODEM

Now I can finally focus on zmodem