Conversation

Jarkko Sakkinen

this is how i'm reorganizing tpm2_library that i resurrected yesterday:

protocol
├── Cargo.toml
└── src
├── envelope
│   ├── create_primary_command.rs
│   ├── create_primary_response.rs
│   ├── create_response.rs
│   ├── dictionary_attack_lock_reset_command.rs
│   ├── empty_response.rs
│   ├── flush_context_command.rs
│   ├── get_capability_command.rs
│   ├── get_capability_response.rs
│   └── mod.rs
├── lib.rs
├── object
│   ├── creation_ticket.rs
│   ├── mod.rs
│   ├── tpm2b_data.rs
│   ├── tpm_alg_id.rs
│   ├── tpma_object.rs
│   ├── tpml_pcr_selection.rs
│   ├── tpms_sensitive_create.rs
│   └── tpmt_public.rs

and further:

1. object "registry" is a flat and fat given that there is standard body doing "intelligent hashing", i.e. TCG is my UUID algorithm for that directory. agreed that the de-facto names are ugly but it is ugly AND clean :-) it is known to scale with the spec from the get go to foreseeable future making it ugly, clean and super stable.
2. all objects marshal and unmarshhal.
3. envelope is also flat as i have unidirectionality as constraint and both commands and responses translate bytestream and back.

this api is aimed to work for clients and emulators. i have no interest to write a simulator but it's still easy to figure out how to make that useful: the same crate can be used to implement TPM interaction and tests can use it to mock the TPM chip interaction :-)

[and it will appear to gitlab anytime soon]

#tpm #linux #tss
0
0
0