Jarkko Sakkinen
Posts
4916Following
327Followers
491OpenPGP: 3AB05486C7752FE1
Jarkko Sakkinen
jarkko
@jwildeboer they are a bit late as most popular daws and best plugins are supporting clap.
i guess that's why they did this :-) vst is somewhat obsolete compared to cool modulation features etc. offered by clap.
i guess that's why they did this :-) vst is somewhat obsolete compared to cool modulation features etc. offered by clap.
2
0
2
Jarkko Sakkinen
jarkko
Yet another reason for improving DSO support in Rust would be to give people freedom of choice to license with LGPL.
0
0
0
Jarkko Sakkinen
jarkko
https://crates.io/crates/tpm2sh/0.13.0
With the tpm2sh 0.13.0 the goals that I set when I started working on this in August are fulfilled:
1. First class handling of TPMKey ASN.1 format, and import capabilities from the most common formats for ECC and RSA keys (PKCS#1, PCKS#8 and SEC1).
2. Meaningful and "human" way to describe key policies (e.g., "(pcr(sha256:16) or pcr(sha256:7)) and secret(tpm:81000001)").
3. Intutive interface to browse the TPM memory and download EK certificates.
4. Virtual TPM address space with transparent context handling and clean up of stale contexts (from earlier power cycles).
In other words, tpm2sh addresses now the immediate kernel hacking needs for TPM driver itself, Linux keyring, IMA etc. One additional feature I'm going to finish off at some point is parameter encryption, which won't take long tas tpm2sh already creates unsalted and unbound HMAC sessions for different tasks.
Patches are always welcome, and can be sent to tpmprotocol@lists.linux.dev ;-)
#linux #kernel #tpm #rustlang
With the tpm2sh 0.13.0 the goals that I set when I started working on this in August are fulfilled:
1. First class handling of TPMKey ASN.1 format, and import capabilities from the most common formats for ECC and RSA keys (PKCS#1, PCKS#8 and SEC1).
2. Meaningful and "human" way to describe key policies (e.g., "(pcr(sha256:16) or pcr(sha256:7)) and secret(tpm:81000001)").
3. Intutive interface to browse the TPM memory and download EK certificates.
4. Virtual TPM address space with transparent context handling and clean up of stale contexts (from earlier power cycles).
In other words, tpm2sh addresses now the immediate kernel hacking needs for TPM driver itself, Linux keyring, IMA etc. One additional feature I'm going to finish off at some point is parameter encryption, which won't take long tas tpm2sh already creates unsalted and unbound HMAC sessions for different tasks.
Patches are always welcome, and can be sent to tpmprotocol@lists.linux.dev ;-)
#linux #kernel #tpm #rustlang
0
1
2
Jarkko Sakkinen
jarkko
tpm2sh 0.12.4 uses hmac sessions but they are not very useful tho as they are both unsalted and unbound sessions. This is of course on purpose because the infrastructure needs to be polished first. Right now it is a mess (but works) :-)
Just like you never do "start-session" for policies but instead describe them in expressions HMAC functionality is transparent to the user and does not require any configuration.
Just like you never do "start-session" for policies but instead describe them in expressions HMAC functionality is transparent to the user and does not require any configuration.
0
0
0
Since language will grow only on policy primitives but not so much in syntax it made sense to:
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2sh.git/tree/src/policy/mod.rs?h=main
It's not whole a lot of code, and I'm sure this will get more streamlined over time.
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2sh.git/tree/src/policy/mod.rs?h=main
It's not whole a lot of code, and I'm sure this will get more streamlined over time.
0
0
1
Jarkko Sakkinen
jarkko
Edited 13 days ago
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
https://crates.io/crates/tpm2sh/0.12.3
#linux #tpm #rustlang
1
0
3
Jarkko Sakkinen
jarkko
Edited 15 days ago
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
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
0
0
1
Jarkko Sakkinen
jarkko
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/
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/
0
0
0
Jarkko Sakkinen
jarkko
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 ;-)
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 ;-)
0
0
5
@jwildeboer @pjakobs not to mention that everyone had Atari joystick ports in the 80s and early 90s :-)
0
0
1
@jwildeboer @pjakobs Atari 800 had innovative Atari SIO bus designed by Joe Decuir, who later on took the same basic design, and created USB ;-)
0
0
2
Jarkko Sakkinen
jarkko
Edited 18 days ago
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
https://mytechinsights.wordpress.com/2025/08/06/himmelblau-1-0-released-finally-real-intune-policy-enforcement-on-linux/
#himmelblau #azure #intune @linuxfoundation
0
0
0
Jarkko Sakkinen
jarkko
@Aissen @geal I prefer combinator parsers over PEG because in combinator parsers with the price of higher "initial cost" you get re-usable components, and maintenance costs over long period of time are much lower than with PEG (assuming that grammar is relatively stable). And yeah, everything lives in the same closure (i.e. in the Rust implementation).
0
0
2
Jarkko Sakkinen
jarkko
Edited 18 days ago
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
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
0
0
0