Jarkko Sakkinen
Posts
4887Following
324Followers
489OpenPGP: 3AB05486C7752FE1
Jarkko Sakkinen
jarkko
Edited 3 days ago
Decomposition time now that tpm2sh has matured to a usable peace of software.
First off, here's basic set of cryptographic routines defined in the TCG TPM 2.0 architecture specification:
https://crates.io/crates/tpm2-crypto
They've been tested equally in client and emulator implementation.
More to come as I dislike the size of current tpm2sh code base (7 KSLOC).
#linux #tpm #rustlang
First off, here's basic set of cryptographic routines defined in the TCG TPM 2.0 architecture specification:
https://crates.io/crates/tpm2-crypto
They've been tested equally in client and emulator implementation.
More to come as I dislike the size of current tpm2sh code base (7 KSLOC).
#linux #tpm #rustlang
1
0
0
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
Jarkko Sakkinen
jarkko
Edited 5 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 8 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
Jarkko Sakkinen
jarkko
Edited 10 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
Edited 10 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
Jarkko Sakkinen
repeated
repeated
AGRO TURBO.EXE SATAN 🇺🇦🇨🇿
lkundrak@metalhead.clubbreaking: white house being replaced by a white trailer park
1
1
1
Jarkko Sakkinen
jarkkoFor 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 ;-)
1
0
1
Jarkko Sakkinen
jarkko
Edited 11 days ago
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
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
1
0
0
Jarkko Sakkinen
jarkkohttps://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:*'
1
0
0
Jarkko Sakkinen
repeated
repeated
