policies:

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

@andrew fixed since

@andrew yes it demonstrates known bug but actual function works :-)

known argument parsing bug but downloading certs does work :-)

PKCS#1, PKCS#8 and SEC1 parsers implemented with rasn and can be converted to TPMKey files, or loaded directly. I created my own parser because popular crates such pkcs8 do "so much more" than this tool needs.

I.e., it's the best tool at preparing stuff into blobs that are usable by kernel.

#buildroot i.e. edition 2021 compatible

https://codeberg.org/jarkko/linux-tpmdd-test/src/branch/main/package/tpm2sh/tpm2sh.mk

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

Reasons why I wrote my own parsers for PKCS#1, SEC1 and PKCS#8 on top of awesome rasn [1] crate instead of using e.g., pkcs8 crate is that:

1. Usually generic crates do so much useless shit outside of the app's requirements so it might not be huge effort to make focused code tuned for the app.
2. Compilation times.
3. It gave me so much DOWNGRADE options, thanks to simpler depenencies, which is huge robustness addition. It's something you learn to appreciate once you do anything embedded/FPGA on ANY language.

[1] https://github.com/librasn/rasn

#linux #rustlang #tpm

I did not know I was this far with loading PKCS#8 keys as I was fully focus for few weeks on TPM2_Import:

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2sh.git/commit/?h=main&id=9b4e31f8bea02953d56d8243a1b9157096642c54

I.e. I had enough parsing code to tell the user that PKCS#8 is not supported that I could now just as well just plain load them ;-)

#linux #tpm

I'm now in zero known bugs state with tpm2sh so maybe it is good soon to release 0.11, which is first real release TBH. Previous were test code for tpm2-protocol

External key loading and import was like something I debugged ridiculous amount of times but considering how many openssl commands you need to do to achieve same result, I'm pretty happy :-)

I also stick to SEC1 and PKCS#1 simply because this is not openssl, and you can use other tools to convert keys to these formats. This allows me NOT to use crazy complex loader crates like pkcs8 crate and have my fully custom loaders made using rasn crate.

#linux #tpm

in tpm2-tools one thing that destroys CLI ergonomics as temporary files that you trash your filesystem with.

I have:

❯ cargo run context list
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.07s
Running `target/debug/tpm2sh context list`
context://4a77dd6d38efc808 primary ecc-nist-p256(sha256)
context://83b9e6c06223acd6 secondary ecc-nist-p256(sha256)
context://e227342ffe74a76c secondary rsa-2048(sha256)

❯ cargo run session list
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.07s
Running `target/debug/tpm2sh session list`
tpm://0x02000000 hmac
tpm://0x03000001 policy

At start tpm2sh does refresh for both lists:

1. context load+save+flush for keys
2. context load+save for sessions

And detects stale loads and deletes those entries i.e, those from previous power cycle.

When one refers to contexts or sessions these URIs must be used as references. All the data is stored at ~/.cache/tpm2sh/.

Inorder to bring cross-compatibility with tpm2-tools load-command supports loading context files and migrating them to tpm2sh caches.

#linux #tpm

Great I finally got fully jq based mustache template processing working:

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-pull-request.git/tree/linux-git-pull?h=main

And it works too:

https://lore.kernel.org/linux-integrity/aOKTFv1vh1cvvcLk@kernel.org/T/#u

not going to comment politically on ongoing wars but as far as ukraine is considered, it's really a force majeure situation against all odds.

drones are the new nuke. ukraine has the most advanced and robust technologies and expertise on the topic. it destines pretty much inevitable win after this hell they've went through.

because nobody is going to let that expertise slip to opponent no matter what is the situation or outcomes in the battlefield.

I reduced key options for tpm2sh next release to

1. SEC1
2. PKCS#1
3. TpmKey

I mean you can always use other tools (e.g., openssl) do conversions. This simplifies the implementation a lot and makes it transparent, as then I can do all parsing inside the app with rasn. Especially for error flows it's nice that parsing errors come only from rasn.

The largest patch series I've sent for some time:

https://lore.kernel.org/linux-integrity/20250929194832.2913286-1-jarkko@kernel.org/

first patch set to make better grounds for trenchboot:

https://lore.kernel.org/linux-integrity/20250929035938.1773341-1-jarkko@kernel.org/T/#t

After this gets to mainline a second series will follow but this already does the absolutely minimal to make the feature feasible.

i refershed my (c)dynlib knowledge and i got this understanding:

1. cdynlib is great because it enables e.g., audio plugins, which is actually multi-billion market. not like niche edge case such as crypto libraries but necessity for creative work.
2. dynlib is not stable and if I understand correctly both rustc version updates and also parameter configurations can lead to troubles (happy to be corrected on this with factual knowledge as I'm not 100% confident of my understanding).

So yeah to get e.g., hot-patchable crypto and stuff like that dynlib some day needs to stabilize. I've now also learned after discussing with one of ther rustc-team-member that this is actually also a distant goal, but not necessarily a "speculative goal" and that is just great. I do understand the complexity of this problem so that actually was my only expectation even if it took years.

Great that edges will be covered some day...

#rust #rustlang

I have been learning more about PDFs than I really wanted to for maybe the absolutely most funny reason possible - letting agency forgery: https://mjg59.dreamwidth.org/73317.html