tpm2sh 0.12.3 loads and processes multi-level ancestor chains correctly, policy expressions have now a more stable manually implemented custom-built parser.

https://crates.io/crates/tpm2sh/0.12.3

#linux #tpm #rustlang

I discarded mocktpm from tpm2sh but I'm planning to implement a *non-generic* TPM emulator.

I.e. I look at Infineon 96xx capabilities and behavior and limit the features match that chipset, and like have non-optionated CA (either generated or provided) for endorsement keys, and not wholealot configuration.

And yeah, I'll implement ability to bind QEMU.

This is to have something super easy (vs swtpm) to get a fake TPM chip for kernel tests and developing and test stuff like Himmelblau IDM.

#linux #kernel #tpm #himmelblau

cool someone asked me about my unfinished / backlogged patch set [1].

I stopped working on that since I thought nobody cares about the feature. I also stopped working on it because TPM2 user space sucked and it is really hard to experiment whether uapi makes sense for that reason.

Now I have my own user space that exactly has strong external capaiblities, compiles fluently to BuildRoot image, and there's one company/person that wants the feature.

I guess updating this patch set is next in my queue after tpm2sh :-)

[1] https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jarkko@kernel.org/

Noteworthy in this is the implict parent discovery without having to specify parent when loading keys :-) It recursively loads always the whole hierarchy where parent key is discovered either among persistent keys or cache.

#linux #kernel #tpm

I'm so happy that I've made on full usable computer program with Rust now, including backend code (tpm2-protocol).

It does not really matter if it is good or bad but a psychological barrier has definitely been broken. Program #2 will be so much easier and fun than this ;-)

I sometimes wonder Linux Foundation is not involved with Himmelblau IDM, given how important project it is for the Linux ecosystem overall.

https://mytechinsights.wordpress.com/2025/08/06/himmelblau-1-0-released-finally-real-intune-policy-enforcement-on-linux/

#himmelblau #azure #intune @linuxfoundation

Servo 0.0.1

https://servo.org/blog/2025/10/20/servo-0.0.1-release/

Great news for web.

#servo #web

#nom is like the first library in Rust of which I can say that I love it, and not because it is "powered by Rust" but because it is such a great peace of work overall :-) #rustlang

Now that I can actually clean up tpm2sh as I reached "zero known relevant bugs" state couple of days ago, some cool features will spun from that.

E.g., most of the time you don't have to specify parent key, the tool will discover it for you.

I'll also implement virtual persistent handles by retaining in cache TPMKey ASN.1 file in addition to context and that enables to implement fake evict operation to 0x81-range.

And already now management of TPM2 sessions is mostly transparent like it should be, and implicitly created HMAC sessions will gain parameter encryption soon.

In pre-existing TPM2 stacks (e.g., tpm2-tool) having sessions exposed out naked to the user is like having a TLS stack where you would need manually implement session key exchange dance. It's just plain fucking wrong imho :-)

#tpm2sh

breaking: white house being replaced by a white trailer park

For VM/embedded images socat is pretty alternative to curl as it has 50% less dependencies and you can still web e.g.,

printf 'GET / HTTP/1.1\r\nHost: www.iki.fi\r\nConnection: close\r\n\r\n' | socat OPENSSL:www.iki.fi:443 -

I’ve replaced curl with socat in my BuildRoot images for kernel testing because it is less bloated than curl ;-)

Cargo would be better if it had a separate unique and label names for dependencies, and dependency resolution used the former.

Basing immutablity to a label makes crates.io quite unrobust IMHO, and given that not all projects fly that far, otherwise useful labels stay reserved permanently, up until Sun melts.

Such dual-name scheme could be transparent to Cargo.toml: e.g. Cargo.lock could map a label to a name.

I'm not saying that names would need to have expiration time. I'm thinking more like willingly giving name back to circulation from abandoned project.

C++ has bunch of offerings now for cargo alike package managers. In that front, I'd try to find a solution that is smarter than Cargo before there is a dominating solution.

#rustlang #cargo

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2sh.git/tree/src/wildcard.rs?h=main

made a little wildcard parser last night so that I don’t have to implement docker esque “tpm2sh reset” command.

e.g. cache can be reseted now by tpm2sh delete 'vtpm:*'

386.

After starting this work one Sunday on August and ~13000 lines of new Rust code after that, this is the first release where I don't have any catastrophical bugs to resolve, or have personally any immediate needs :-)

https://crates.io/crates/tpm2sh

#linux #rustlang #tpm

tpm2sh policy has now more inituitive infix expressions :-) [learning nom by trial and error]

I’m planning to iteratively make tpm2sh policy subcommand to compile policy expressions first into eBPF i.e., --mode ebpf option.

We can use this to address bottleneck in trusted keys in kernel: TPMKey ASN.1 provides key blob but not steps how to create policy session that authorizes the key.

Today: TpmKey ASN.1 with auth value and policy digest can be passed but really only auth value (+ PCR selection in TPM2_Create) can be used for authentication.

My vision for policy protected keys is basically:

1. Key data is passed as TPMKey ASN.1 just like today.
2. In addition eBPF program for creation policy session is passed when policy digest is used.

It’s perfectly secure given that a malicious eBPF program would end up to a different policy digest than what is associated with the key.

#linux #kernel #tpm

Refined the interface of offloaded objects:

1. Objects resident/loaded in TPM: tpm:
2. Offloaded objects: vtpm:

Thus, I removed also "key" and "session" subcommands and introduced "virtual" subcommand.

#linux #tpm #rustlang

tpm2sh 0.11.16

This is the release where things mostly work and is first usable version for wider audience than just me.

Functionality is focused on key management and it is quite limited on operations.

That said, it the most important functionalities, and most difficult to implement, in place:

1. Implicit creation of HMAC sessions to protect communication, and hiding its complexity . It is still a stub as parameter encryption is not in place but the mechanism is working correctly.
2. Key management including direct support for PKCS#1, PKCS#8 and SEC1 external keys with custom parsers so that dependencies are light for e.g., BuildRoot embedded/VM targets. 3, Seamless over-subscription with key context cache (in ~/.cache/tpm2sh). Detects stale contexts from previous power cycles. “Cache keys” can be referred bit “key:<hex grip>” type of “URI”, where grip is 8 bytes of the key’s name hash.
3. Seamless policy sessions with policy command, which can output both composite digest and session handle.
4. Intuitive way to download vendor certificates from the chip.
5. Full support for the TPMKey ASN.1 format, which is what kernel speaks.

Adding signing etc. ops would have been worse mistake to do before getting this basis right.

It’s not aiming to do all what tpm2-tools does but more like do stuff that I want to do and implementing that as a command-line tool :-) I.

#linux #kernel #tpm #rustlang #buildroot

tpm2sh 0.11: https://crates.io/crates/tpm2sh/0.11.0

cli philosophy, which I should document to README.md, is that no nested subcommands thank you. That constraint enforces to do efficient subcommand design (IMHO).

#linux #kernel #tpm