@hunger I have also somewhat clear milestone deriving from a kernel patch set: https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jarkko@kernel.org/
For v8, one of the goals is to have the smoke testing transcripts described in tpm2-cli
.
Main gist of upcoming changes for my crate are scoped in the this:
tpm2_createprimary --hierarchy o -G rsa2048 -c owner.txt
tpm2_evictcontrol -c owner.txt 0x81000001
openssl genrsa -out private.pem 2048
tpm2_import -C 0x81000001 -G rsa -i private.pem -u key.pub -r key.priv
tpm2_encodeobject -C 0x81000001 -u key.pub -r key.priv -o key.priv.pem
openssl asn1parse -inform pem -in key.priv.pem -noout -out key.priv.der
[and similar for ECDSA]
In my project tpm2_call
has the protocol layer and zero OS specific shenangians, i.e. it is ultra-portable.
However, in tpm2-cli
I can just add a command that does the equivalent flow using openssl and asn1 crates. Generally the winds and stream in this project go in a way that I let shit grow in tpm2-cli
and abstract away stuff that is agnostic and mature enough to tpm2_call
. This way abstraction formalize by evolution and stimulus and not by top-down design…
@hunger yep, so for me it is somewhat is easy choice because I’m the main consumer of my own product.
For instance the first pieces of functionality are response code to (spec) mnemonic decoding and object enumeration. I wrote those only because that will free from having to use tpm2_rc_decode
and tpm2_getcap
for this again.
Consortium projects can have sometimes issues that there is bunch of people who do not actually use it every day in their tool set. I.e. ‘’let’s do something ugly that covers our spec” type of acting ;-)
The second problem is that often in such projects moving changes to upstream can take ages because nobody cares that much. So I can either choose:
All I did in 48h improved my kernel flow at instant. That is at least measurable benefit. Doing for myself, not for users ;-)
Closed my tpm-rs
bug because I do not want to contribute to that project: https://github.com/tpm-rs/tpm-rs/issues/71#issuecomment-2171360982
Why? I think mine is better or will grow so much better than this. It is more idiomatic #Rust, and generally less layered and more lean and mean ;-)
I will review merge requests for mine tho, on the basis of common sense and code quality tho: https://gitlab.com/jarkkojs/tpm2_library/-/issues
@cgwalters @fale BTW, is the Fedora version up to date or would it be more advisable at this point to build from upstream (0.1.11)? Or is there a more bleeding edge copr for this work?
I have personal interest for this because to this day I’ve used libvirt
for development environments and qemu-system-*
for more automated QA [1]. For the former use case this might be my entry to popular “development containers” ;-) So I might be even willing to fix some issues along the way, if I encounter any.
I’m more of a “allow list” than a “deny list” type of person, and thus Linux containers have felt to me quite bad to this day, to be honest.
<personal-and-extremely-subjective-opinion>
Docker is a great example of a successful duct tape product to fix something broken to appear as unbroken ;-) Market was formed by bad design decisions in kernel (emphasis on subjectivity of this opinion) [2]. </personal-and-extremely-subjective-opinion>
[1] https://gitlab.com/jarkkojs/linux-tpmdd-test [2] Mainly speaking about the “evil net of namespaces”, which is a mess. I think Cgroups in its second iteration is quite good actually for what it does.
TPM2 command encoding with #bincode and #serde:
let options = DefaultOptions::new()
.with_fixint_encoding()
.with_big_endian();
buf.extend(&options.serialize(&(Tag::NoSessions as u16)).unwrap());
buf.extend(&options.serialize(&22_u32).unwrap());
buf.extend(
&options
.serialize(&(CommandCode::GetCapability as u32))
.unwrap(),
);
buf.extend(&options.serialize(&(Capability::Handles as u32)).unwrap());
buf.extend(&options.serialize(&HR_PERSISTENT).unwrap());
buf.extend(&options.serialize(&1_u32).unwrap());