Jarkko Sakkinen
Posts
4835Following
322Followers
492OpenPGP: 3AB05486C7752FE1
Jarkko Sakkinen
jarkko
Edited 6 hours ago
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
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
0
0
0
Jarkko Sakkinen
jarkko
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
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
0
0
0
Jarkko Sakkinen
jarkko
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
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
0
0
0
Jarkko Sakkinen
jarkko
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
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
0
0
0
Jarkko Sakkinen
jarkko
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
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
0
0
0
Jarkko Sakkinen
jarkko
Edited 6 days ago
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.
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.
0
0
2
Jarkko Sakkinen
jarkko
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.
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.
0
0
0
Jarkko Sakkinen
jarkko
The largest patch series I've sent for some time:
https://lore.kernel.org/linux-integrity/20250929194832.2913286-1-jarkko@kernel.org/
https://lore.kernel.org/linux-integrity/20250929194832.2913286-1-jarkko@kernel.org/
0
0
1
Jarkko Sakkinen
jarkko
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.
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.
0
0
0
Jarkko Sakkinen
jarkko
Edited 12 days ago
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
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
1
2
1
Jarkko Sakkinen
repeated
repeated
Matthew Garrett
mjg59@nondeterministic.computerI 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
6
6
0
Jarkko Sakkinen
jarkko
Edited 13 days ago
I have pretty positive feelings after discussing on a call with Trenchboot patch set authors that we will be able to land it in foreseeable future.
I've kind of felt sympathy for that patch set especially with traumas from SGX patches :-) I offered a solution for nailing issues with early boot TPM access and it reflected, so I think we are now in a steady path for ultimate success.
Patch sets combining cryptography and device I/O are difficult because they end up always being exercise of inserting a cube into a circular hole. Trenchboot is particularly nasty because it intersects with both arch/x86 and TPM driver.
I've kind of felt sympathy for that patch set especially with traumas from SGX patches :-) I offered a solution for nailing issues with early boot TPM access and it reflected, so I think we are now in a steady path for ultimate success.
Patch sets combining cryptography and device I/O are difficult because they end up always being exercise of inserting a cube into a circular hole. Trenchboot is particularly nasty because it intersects with both arch/x86 and TPM driver.
0
0
0
Jarkko Sakkinen
jarkko
Edited 14 days ago
TPM2 driver was pretty static for multiple years but the volumes and use cases have been steadily increasing so right now many of the key parts are going through iterative rewrite:
https://lore.kernel.org/linux-integrity/aNQpvQBV43dhS6ad@kernel.org/
One thing I don't actually know about kernel is that can lib/* be used in the early boot code? I'd presume it can but just don't know the tidbit.
It would make whole a lot of sense to create decoupled command/response parsing/building implementation there and use that in the driver and early boot code.
#linux #kernel #tpm
https://lore.kernel.org/linux-integrity/aNQpvQBV43dhS6ad@kernel.org/
One thing I don't actually know about kernel is that can lib/* be used in the early boot code? I'd presume it can but just don't know the tidbit.
It would make whole a lot of sense to create decoupled command/response parsing/building implementation there and use that in the driver and early boot code.
#linux #kernel #tpm
0
0
0
Jarkko Sakkinen
jarkko
had my favorite breakfast at morning i.e. karelian pies with egg butter :-) only think that would add up to this would some cold-cured salmon
0
0
0
Jarkko Sakkinen
jarkko
I've started to make some groundwrok to make Trenchboot feasible to land to mainline kernel i.e. introducing builder/parser pattern in order to decouple physical transmission path from logical protocol shenanigans, translating the system to use mainly stack allocations and stuff like that.
Even tho C work, lot's ideas and inspiration come from my recent Rust work.
#linux #tpm #kernel
Even tho C work, lot's ideas and inspiration come from my recent Rust work.
#linux #tpm #kernel
0
0
0
Jarkko Sakkinen
repeated
repeated
Kernel Recipes
KernelRecipes@fosstodon.orgCome along for the ride — check out the first sneak peeks of the conference!
#kr2025
Many thanks to Jean-Christophe for the ride (Uweti)
0
8
2
Jarkko Sakkinen
repeated
repeated
Dan Gillmor
dangillmor@mastodon.socialTrump regime now requires press to sign a document agreeing not to obtain or possess "unauthorized" information.
Anyone who agrees to this is not qualified to call himself or herself a journalist.
But I'm betting most Big Journalism orgs will go ahead and sign.
11
7
0
Jarkko Sakkinen
jarkko
Sometimes lack of skills make one do complex tasks.
I was too lazy to learn how to
1. Package Rust programs to BuildRoot images.
2. Do the necessary fixes [1] and downgrades to get build working.
So as a temporary solution I wrote a TPM emulator :-) It's quite easy task with tpm2-protocol given that it is more like "a socket" than "a client" or "a server" abstraction.
However, now that I've done BuildRoot integration to my kernel testing builds [2], the next logical step is to split some offspring:
1. tpm2-protocol: core crate
2. tpm2sh: client
3. mocktpmd: standalone TPM emulator.
'd' is there so that if I ever want to further split mocktpmd to library and executable my naming conventions will scale ;-)
[1] https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?id=4cc0198ee778881efffa658ea2fc65aa5e2c36cf
[2]
https://codeberg.org/jarkko/linux-tpmdd-test/commit/21ade103f9836c7174a8b1c14592928e1c626839
#linux #kernel #tpm #rustlang
I was too lazy to learn how to
1. Package Rust programs to BuildRoot images.
2. Do the necessary fixes [1] and downgrades to get build working.
So as a temporary solution I wrote a TPM emulator :-) It's quite easy task with tpm2-protocol given that it is more like "a socket" than "a client" or "a server" abstraction.
However, now that I've done BuildRoot integration to my kernel testing builds [2], the next logical step is to split some offspring:
1. tpm2-protocol: core crate
2. tpm2sh: client
3. mocktpmd: standalone TPM emulator.
'd' is there so that if I ever want to further split mocktpmd to library and executable my naming conventions will scale ;-)
[1] https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?id=4cc0198ee778881efffa658ea2fc65aa5e2c36cf
[2]
https://codeberg.org/jarkko/linux-tpmdd-test/commit/21ade103f9836c7174a8b1c14592928e1c626839
#linux #kernel #tpm #rustlang
0
2
1
Jarkko Sakkinen
jarkko
my shitty buildroot kernel testing environment keeps improving as the years pass like a good wine ;-)
#buildroot
#buildroot
0
0
3