Jarkko Sakkinen
Posts
4950Following
329Followers
494OpenPGP: 3AB05486C7752FE1
Jarkko Sakkinen
jarkko
Edited 3 months ago
this SVG garbage fuck. is there something we could put .gitattributes, .gitignore or something that would make it not to destroy git grep experience?
2
0
0
Jarkko Sakkinen
jarkko
Edited 3 months ago
I migrated dyn trait (or Box<dyn TpmObject>) as part of tpm2_protocol test suite just to demonstrate that on-wire TPM2 protocol can be dynamically detected without any spurious dependencies ;-)
Screencast demonstrates also the time that it takes to run the full kselftest compatible test suite.
#linux #kernel #tpm #rust
Screencast demonstrates also the time that it takes to run the full kselftest compatible test suite.
#linux #kernel #tpm #rust
0
0
1
Jarkko Sakkinen
jarkko
Well... hell... TCG TPM 2.0 specification 184 minus one command coverage.
1
0
0
Jarkko Sakkinen
jarkko
tpm2sh starts to look pretty good and has at least the features i want it to have for kernel testing.
tpm2_protocol is "kernel-ready" (including Box<dyn TpmObject>, which is essential for a driver uapi) and this the full list of commands it lacks for 100% TCG TPM 2.0 specification coverage:
https://github.com/puavo-org/tpm2_library/issues/4
I'm pretty much done with this project for the moment :-)
tpm2_protocol is "kernel-ready" (including Box<dyn TpmObject>, which is essential for a driver uapi) and this the full list of commands it lacks for 100% TCG TPM 2.0 specification coverage:
https://github.com/puavo-org/tpm2_library/issues/4
I'm pretty much done with this project for the moment :-)
1
0
0
Jarkko Sakkinen
jarkko
This was nasty one to fix and took many days (and nights tbh) but now finally command parsing is fixed and all my tests pass:
https://github.com/puavo-org/tpm2_library/commit/7b0fc824bd341fb21c90a06b945f01feb1c20f5e
There's MS TPM 2.0 emulator and swtpm, and that's like all of command parsing and response synthesis I'm aware of. I.e. by practical means there was no useful existing work to take example of :-) I'm pretty happy and a bit proud too that I've reach unipolarity by writing Rust macros reflecting TCG specifications.
I don't have now known bugs in the protocol crate. I'm sure there's a bunch but still feels nice after 1.5 weeks of sleepless nights and 7K SLOC of code (protocol + cli).
#linux #kernel #rust #tpm
https://github.com/puavo-org/tpm2_library/commit/7b0fc824bd341fb21c90a06b945f01feb1c20f5e
There's MS TPM 2.0 emulator and swtpm, and that's like all of command parsing and response synthesis I'm aware of. I.e. by practical means there was no useful existing work to take example of :-) I'm pretty happy and a bit proud too that I've reach unipolarity by writing Rust macros reflecting TCG specifications.
I don't have now known bugs in the protocol crate. I'm sure there's a bunch but still feels nice after 1.5 weeks of sleepless nights and 7K SLOC of code (protocol + cli).
#linux #kernel #rust #tpm
1
0
1
Jarkko Sakkinen
jarkko
Edited 3 months ago
I'm ready to push this online, but not for a while tag a release because cli should be made to work optimally.
E.g., policy-secret is placeholder. it would much nicer to have "policy [--train] <expression>" with some combinatorial language.
It could take advantage of object references provided my baked-in stack machine:
1. Subcommands a take list of JSON objects from stdin and consume as many as they need from top of te stack.
2. Each subcommand then produce results to the top.
Of course some things come through arguments (e.g. for key creation I have "--persistent").
Also perhaps load and import should be combined to a single smart command. The point is that this is where I don't know what to do exactly and changes for cli interface are welcome :-) I'm now happy that I got allocs and panics away from protocol crate making it "linux-rust ready".
In the protocol crate itself there is one single puzzle where constant improvement makes sense both in kernel and user space: narrowing the delta between "SIZE" and "len()" of TpmSize trait. Ideally the delta would be zero t some point. To be usable in kernel I've now reach that goal (easily) but optimizing this equation makes it substantially better.
E.g., policy-secret is placeholder. it would much nicer to have "policy [--train] <expression>" with some combinatorial language.
It could take advantage of object references provided my baked-in stack machine:
1. Subcommands a take list of JSON objects from stdin and consume as many as they need from top of te stack.
2. Each subcommand then produce results to the top.
Of course some things come through arguments (e.g. for key creation I have "--persistent").
Also perhaps load and import should be combined to a single smart command. The point is that this is where I don't know what to do exactly and changes for cli interface are welcome :-) I'm now happy that I got allocs and panics away from protocol crate making it "linux-rust ready".
In the protocol crate itself there is one single puzzle where constant improvement makes sense both in kernel and user space: narrowing the delta between "SIZE" and "len()" of TpmSize trait. Ideally the delta would be zero t some point. To be usable in kernel I've now reach that goal (easily) but optimizing this equation makes it substantially better.
2
1
2
Jarkko Sakkinen
jarkko
Edited 3 months ago
The design that I'm aiming with this cli interface is that it would be usable for TPM2 interaction for application written shell (bash, fish etc.) scripting languages (i.e. password managers and similar).
When it starts to be easy to combine the subcommands in script this should be in fairly good state.
Import and load support keys in ASN.1 format, which is used by kernel for loading trusted keys. Software crypto for now is with libssl bindings as it is sort for safe-play for crypto (CVEs, security hotfixes, auditing) and also it is what I'm most used to in kernel development (and that is what I ultimately care about).
When it starts to be easy to combine the subcommands in script this should be in fairly good state.
Import and load support keys in ASN.1 format, which is used by kernel for loading trusted keys. Software crypto for now is with libssl bindings as it is sort for safe-play for crypto (CVEs, security hotfixes, auditing) and also it is what I'm most used to in kernel development (and that is what I ultimately care about).
0
0
1
Jarkko Sakkinen
jarkko
Edited 3 months ago
Regex filtered search for algorithms in the TPM chip and the format used for algorithms in tpm2-cli.
Some other idioms are context: and nvram: as sinks for output.
Some other idioms are context: and nvram: as sinks for output.
0
0
0
Jarkko Sakkinen
jarkko
I'm making sure the cli works nicely before pushing to Gitlab for some days. It is at least much saner looking already (IMHO) than tpm2-tools.
0
0
1
Jarkko Sakkinen
jarkko
great now the deps are in the reasonable level for this type of tool :-) (and meson replaced with plain make).
using cjson was not a great idea in the first place as when doing json output for small and trivial low-level tools like this instead of dumping big continuous json string is also really the best option (vs pretty printing).
maybe i soon tag a release and put this debian packaging pipeline :-)
using cjson was not a great idea in the first place as when doing json output for small and trivial low-level tools like this instead of dumping big continuous json string is also really the best option (vs pretty printing).
maybe i soon tag a release and put this debian packaging pipeline :-)
0
0
0