Jarkko Sakkinen
Posts
5042Following
329Followers
503OpenPGP: 3AB05486C7752FE1
Jarkko Sakkinen
jarkko
There's no separate "pcr-read" command anymore in tpm2sh as policy command is robust enough to address that task too:
❯ sudo target/debug/tpm2sh policy "pcr(sha256:0,7)"
pcr(sha256:0,7, 9c367f8c268d51ced151a664d88e37e74fcd84485eff8ff9bc26d22aa9091020)
With --compose flag it creates the policy digest.
❯ sudo target/debug/tpm2sh policy "pcr(sha256:0,7)"
pcr(sha256:0,7, 9c367f8c268d51ced151a664d88e37e74fcd84485eff8ff9bc26d22aa9091020)
With --compose flag it creates the policy digest.
0
0
1
Jarkko Sakkinen
jarkko
Edited 3 months ago
The goal in in tpm2sh 0.11 is to repeal and replace the pre-existing uses of tpm2-tools to enable things like PCR sealed hard drive encryption. I'm focusing on smooth and for a sysadmin type of a person common sense type of flow.
It's more like UI problem than a technical problem. A great cli is such that you can put it powerpoint sheet and everyone will get it down to reconfiguring your computers.
#tpm #rust #linux
It's more like UI problem than a technical problem. A great cli is such that you can put it powerpoint sheet and everyone will get it down to reconfiguring your computers.
#tpm #rust #linux
0
1
1
Jarkko Sakkinen
jarkko
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?id=f085a5107eb140c1708a0e9ec11e4c3b4aa962ca
Migrated few more tests to data-driven format and renamed the original test tool as 'adhoc.rs' for tests that don't fit to the data-driven framework (yet).
I think this will cage the implementation right way and over time the factor to break it will grow...
Migrated few more tests to data-driven format and renamed the original test tool as 'adhoc.rs' for tests that don't fit to the data-driven framework (yet).
I think this will cage the implementation right way and over time the factor to break it will grow...
0
0
0
Jarkko Sakkinen
jarkko
Edited 3 months ago
A literally WYSIWYG pattern for command-line usage and help where each subcommand has a directory with 'mod.rs', 'usage.txt' and 'help.txt':
- Text files are more readable than code generation (unless you are a compiler).
- Text files has factors better outreach than code generation.
- Text files are non-executable read-only data.
- A bug in a static text file is a typo. Typo is a distraction for sure, but it does not radiate software bugs.
- The factor it simplifies command argument processing is much heavier than some minor redundancy that using text files introduces.
- Text files can be read without building a project.
#rust #clap #lexopt
- Text files are more readable than code generation (unless you are a compiler).
- Text files has factors better outreach than code generation.
- Text files are non-executable read-only data.
- A bug in a static text file is a typo. Typo is a distraction for sure, but it does not radiate software bugs.
- The factor it simplifies command argument processing is much heavier than some minor redundancy that using text files introduces.
- Text files can be read without building a project.
#rust #clap #lexopt
1
2
2
Jarkko Sakkinen
jarkkoZerocopy will be easy to implement now that I’ve found out how it is done by experimenting with basic types.
Memory requirements are relaxed as in:
- Before (0.10.x): stack is required for the artifact
- After (0.11.x): a CPU with registers will do for the memory, and read-only address for the input data.
70-80% of code base will be re-usable and remaining 20% is rewriting macros, tweaking a few call sites and creating a few new traits for macro consumption.
Despite 0.10.x having clone semantics, it is the correct traversal that is the hard problem here and it needs to be solved only once that data can be used to inject slice markers to exactly correct locations. This is why also parsing or building process nees no extra memory other than CPU cores registers.
The number lines in implementation will with higher odds go down rather than up. Looking pretty good…
0
0
3
Jarkko Sakkinen
jarkko
Procedural macros: how to get started? How they play with compiler? How can I, or can I use them with rustc w/o cargo?
I'm specifically not interested on "how to program proc macros tutorial". At this point more about "geometry" and how they link and in essence all bin related info.
#rust #cargo #macros
I'm specifically not interested on "how to program proc macros tutorial". At this point more about "geometry" and how they link and in essence all bin related info.
#rust #cargo #macros
3
0
2
Jarkko Sakkinen
jarkko
Edited 3 months ago
It took a lot of effort but now all parts of running TPM2_Import are fixed in both tpm2sh and TPM2_Import and integration tests runs perfectly.
Last fix: https://github.com/puavo-org/tpm2sh/commit/3627530516fdcc8739b3c7aea6fab6a136201bfa
It's a bidirectional test where both the client and the emulator are based on tpm2-protocol. The other side sends commands and parses responses, and the other side send responses and parses commands.
Given the fair amount of software crypto involved to perform any possible bidirectional handshake it is shows off pretty well how robust the implementation is.
#rust #tpm #linux
Last fix: https://github.com/puavo-org/tpm2sh/commit/3627530516fdcc8739b3c7aea6fab6a136201bfa
It's a bidirectional test where both the client and the emulator are based on tpm2-protocol. The other side sends commands and parses responses, and the other side send responses and parses commands.
Given the fair amount of software crypto involved to perform any possible bidirectional handshake it is shows off pretty well how robust the implementation is.
#rust #tpm #linux
0
1
2
Jarkko Sakkinen
jarkko
now "algorithms" is exact description of the available hardware algorithms:
❯ sudo target/debug/tpm2sh algorithms
ecc:bn-p256:sha256
ecc:nist-p256:sha256
keyedhash:sha256
rsa:2048:sha256
it queries the hardware correctly and for RSA it also runs TPM2_TestParms to verify the bit sizes. it was surprsingly hard to get this right but i'd guess this might be even most accurate tool on doing this task (not because it is great but because available software sucks).
❯ sudo target/debug/tpm2sh algorithms
ecc:bn-p256:sha256
ecc:nist-p256:sha256
keyedhash:sha256
rsa:2048:sha256
it queries the hardware correctly and for RSA it also runs TPM2_TestParms to verify the bit sizes. it was surprsingly hard to get this right but i'd guess this might be even most accurate tool on doing this task (not because it is great but because available software sucks).
0
0
0
simple, stupid and super practical:
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?id=aa88967684edeb10e2601baf94fb259371190523
it's like per commit fuzz testing :-)
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?id=aa88967684edeb10e2601baf94fb259371190523
it's like per commit fuzz testing :-)
0
0
0
Jarkko Sakkinen
jarkko
I first used clap in tpm2sh, then switched to lexopt and again back to clap because of too much boilerplate code.
The problem I run every single time with clap is how hard it is to control if you actually want to control in detail.
Now I found the ultimate compromise for my situation:
1. I pre-rendered from clap usage and help to usage.txt and help.txt for each subcommand.
2. I changed my subcommands as directories. E.g., from "create-primary.rs" to "create-primary/mod.rs".
3. I deployed the text files to associated directories.
4. Finally I migrated parsing back lexopt.
Intial commit:
59 files changed, 538 insertions(+), 521 deletions(-)
Not too bad. WIth only parsing is just super complicated tool to do that task, or more complicated than necessary, and lexopt adds visibility to code paths so it is overall much more maintainable :-)
Also few redundant edits every once in a while to two txt files per subcommand is IMHO much more maintainable than adjusting generation from the source code.
The problem I run every single time with clap is how hard it is to control if you actually want to control in detail.
Now I found the ultimate compromise for my situation:
1. I pre-rendered from clap usage and help to usage.txt and help.txt for each subcommand.
2. I changed my subcommands as directories. E.g., from "create-primary.rs" to "create-primary/mod.rs".
3. I deployed the text files to associated directories.
4. Finally I migrated parsing back lexopt.
Intial commit:
59 files changed, 538 insertions(+), 521 deletions(-)
Not too bad. WIth only parsing is just super complicated tool to do that task, or more complicated than necessary, and lexopt adds visibility to code paths so it is overall much more maintainable :-)
Also few redundant edits every once in a while to two txt files per subcommand is IMHO much more maintainable than adjusting generation from the source code.
1
0
0
Jarkko Sakkinen
jarkko
After fixing a few bugs where resolution repeats a common pattern I created these
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?id=f5e0e82aaad3135be73c3f7a35aaec08e78cfe7c
I.e. if a command or response acts weird the dump can be put either "response.txt" or "command.txt" and roundtrip parse-build-compare will be peformed when running either "cargo test" or "make test".
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?id=f5e0e82aaad3135be73c3f7a35aaec08e78cfe7c
I.e. if a command or response acts weird the dump can be put either "response.txt" or "command.txt" and roundtrip parse-build-compare will be peformed when running either "cargo test" or "make test".
1
0
0
Jarkko Sakkinen
jarkko
@liskin kernel.org "Normies" are like the main filter how i deploy my projects :-)
E.g., in this recent tpm2-protocol i use mailing list partly because i want purposely rise the barrier for contributions. However, tpm2sh is at Github in order to "build the following", market the technological advantages to projects such as Himmeblau (Intune integration from the people who deliver us Samba) and perhaps even get contributors for the actual tech project :-)
E.g., in this recent tpm2-protocol i use mailing list partly because i want purposely rise the barrier for contributions. However, tpm2sh is at Github in order to "build the following", market the technological advantages to projects such as Himmeblau (Intune integration from the people who deliver us Samba) and perhaps even get contributors for the actual tech project :-)
1
0
0
Jarkko Sakkinen
jarkko
@liskin someone should productize "mailhub" and base it on the first class user experience of kernel.org (vger + lore + patchwork) and cli tools (b4, lei). only email can take most and best out of git :-)
even for low-traffic early phase project where i'm mostly talking to myself i get a lot from this as i can search and timeline my mumblings :-) https://lore.kernel.org/tpm-protocol/
at github i feel as i was suffering from artificial dementia. you don't have "history" at github
even for low-traffic early phase project where i'm mostly talking to myself i get a lot from this as i can search and timeline my mumblings :-) https://lore.kernel.org/tpm-protocol/
at github i feel as i was suffering from artificial dementia. you don't have "history" at github
1
0
1
@colinianking I said originally that I'm going to use just one Sunday for this to translate tpm2-scripts to Rust and now it is already four weeks and counting :-) went a bit out of proportions
0
0
1