Conversation
Jarkko Sakkinen
jarkko
Edited 4 days ago
i'd be interested on seeing a new version of /dev/tpmrm0 that would take advantage of my protocol marshaler/unmarshaler.
it's about 5k of rust code but large portion of that is just architectural types.
the first problem is the hardest: what to call the new at this point still imaginary device :-)
it's a post initcall use case just like /dev/tpmrm0 e..g, use by systemd (afaik tbh have not checked) where as hardware interfacing stuff would be tedious given tight bindings to to the boot. thus, it is not extremely hard to implement in linux-rust as long as the device can turn on before PID 1.
benefits could be e.g., to simplify TPM code in daemons such as systemd, if the resource manager would do a better job servicing their requirements.
#linux #tpm #rust #rustlang
it's about 5k of rust code but large portion of that is just architectural types.
the first problem is the hardest: what to call the new at this point still imaginary device :-)
it's a post initcall use case just like /dev/tpmrm0 e..g, use by systemd (afaik tbh have not checked) where as hardware interfacing stuff would be tedious given tight bindings to to the boot. thus, it is not extremely hard to implement in linux-rust as long as the device can turn on before PID 1.
benefits could be e.g., to simplify TPM code in daemons such as systemd, if the resource manager would do a better job servicing their requirements.
#linux #tpm #rust #rustlang
1
0
0
features that protocol crate can do is to break down any byte stream to either direction into a data type 1:1 matching its internal structure, modify it and turn it back into bytes, which delivers quite robust filtering architecture, which is non-existent in /dev/tpmrm0.
0
0
0