for what is worth here's arch installation running for my Ryzen 9950X desktop :-)

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/sysdarch.git/

Just though to upload it somewhere for backup.

It has secure boot (sbctl), TPM2 unlock, and finally EXT4, which is probably a twist from current standards (but is so convenient given universal support everywhere).

@jarkko Arch installer we all deserve.

@jarkko
Right, reminds me I need to write `sbctl setup`

@Foxboron I recently migrated from shim to sbctl based secure boot. Now I'm thinking why I did not do this before :-)

@Foxboron sound work with sbctl i have to say :-) superconvenient tool!

@jarkko
Thanks! Also supports tpm keys :)

Lacks policies though. Need to solve that soon in my TPM tooling.

@Foxboron I need to try that out against my tool. It already nicely operates with openssl and tpm2-tools.

tpm2sh can generate keys with policies.

The set of commands is fairly limited but it is a subset that I pick to maximize coverage for the time being: or, secret and pcr.

Unfortunately spec is quite incomplete when it comes to PolicyOr but my tool generates the full PolicyRestart dance to the file. That way e.g. kernel in future can implement a functional executor.

What executor needs to done with output data:

1. Fill policy handle with active session handle.
2. Resolve handles for PolicySecret calls.

It would be cool to maintain some kind of interoperatibility with sbctl given the state of spec and that way sort of "fill out the blanks" :-)

For auth values in the latest version I've ended up to "<handle>:<hex>" type of list of mappings. Linear list of values is quite difficult to map when you have both purely auth value authenticated object and policies referencing to handles.

@jarkko
There are some issues with the Policies in the specc, but we should solve that with the specc on the ML with Bottomley. Your tools currently do not follow the specc and uses new optional sections in place where I've proposed additions.

I can't make guarantees it will continue to work.

@jarkko
But generally, I've wanted to solve policies for `ssh-tpm-agent` as well. Both uses the same underlying libraries so any improvements to any of these tools improve both.

@Foxboron I have exactly one optional field "parentPublic".

Other than I'm willing to consider changes if there is need. My tools has been built quite rapidly so maybe you are not in-sync with very latest version but it is otherwise in par with the spec :-)

E.g., in very first version it did handle e.g. PolicySecret incorrectly but as of today it follows correctly the ASN.1 definition.

@Foxboron If possible, could you point out the part of the current version that don't right to you?

I'm proactively concerned about this because I need to know what we want for kernel in the long run.

We don't want two separate formats so it is better to address this issue rather sooner than later :-) I'm not hanging myself to my implementation. I'm just working without better information (perhaps).

Actually no need to even look at the source code (unless you really want to). Just describe what goes wrong and I'll check whether I need to address something or if it is already addressed.

@Foxboron My guess it might be TPM2_PolicySecret section that you might be referring into, which was incorrectly handled in earlier versions but as of today it is treated same way as in the ASN.1 spec (objectHandleHint, objectName and policyRef).

@jarkko

https://groups.io/g/openssl-tpm2-engine/topic/115384542

And the following thread for implementing support for creation data. The optional section conflicts with the `parent_pubkey` you introduced.

So the story with tpm2sh is that I only started it in August so that link feels like ancient history me in this fast-phased timeline :-)

If you have something other in mind and have good rationale for it, I want to align with that.The point is that tpm2sh is a reference model for me how kernel will handle the ASN.1 format.

@Foxboron And if possible drop me email to jarkko@kernel.org. I think it is fair common shared goal that tools and also kernel will have the definition, right?

@jarkko

Yes, I read the LKML posts.

The rationale is that the TPM keyfile specc is the one hosted by Bottomley and what most of the tooling implements.

@Foxboron I don't necessarily agree anymore to the word how I saw things then :-) The claim of endangering securiy was definitely wrong or at least a bit weak argument.

It's mostly about convenience (not about security) of not having to specify parent explitly, definitely something I can consider to drop. I also tested that openssl and tpm2-tools can handle files generated with my tool despite having that field.

Things that were not in the spec:

1. PolicyOr: I fully open code this including PolicyRestart calls.
2. Policy handle: I zero out this field in the encoded data.

I even looked at tpm2-tools and it does not really have anything at all for encoding arbitrary policies so I had to work on "without better knowledge". And without better knowledge this is the encoding I will use as basis for any kernel patch reviews or my own possible contributions.

full asn1 definition: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-tpmkey.git/tree/src/asn1.rs

@jarkko

I think the policy stuff needs work. I believe Lennart has some opinions there as well that might be useful.

But generally I think we should follow one spec, it will be easier to standardize on.

@Foxboron

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-tpmkey.git/commit/?id=89902ad0be70c3bc86a7c20fa42af1802e2b9e69

I guess for the time being this will address the current issues :-)

As per policy encoding I follow what exist now as in detail and as closely as currently is possible. I think it is still quite useful to have at least one working implementation as PoC or reference model.

@jarkko
Cool, thanks.

Feel free to write a patch to the mailing list if you want `parent_pubkey` in the specc though.

I intend to see if we could maybe get it properly standardized once the Creation data is part of the specc.

@Foxboron It felt then important but not as much now :-) I'm happy to take one step back on that. I wrote the whole 20'ish kSLOC in three(ish) months and your opinions tend to develop during that process, especially what you see as a priority and what not. Looking at those mails, I don't really get all what I said anymore.

As per policy encoding, a working implementation is already an argument (IMHO) :-) And I know the implementation that I have now would be workable model for kernel as the execute could be implemented in 500-1000 lines of C code. Not something where I fight and I'm happy to hear what e.g., Lennart has to say about policy encoding.

My only strong opinion at this point is that I want to be at least aware of where things turn out as per policy encoding :-)

@Foxboron As you can see from this screenshot from few days ago it is "somewhat compatible". I need to test out it next with sbctl.

@Foxboron Now I exactly recall why it is less important now. I do the trick inside cache i.e. I have separate encoding for cache policies, which retain e.g. information about parent's public field. That way I get most of the convenience without having to break the file format. At the time I did not even know that I will have vTPM cache eventually :-) Things happened quite fast (and without much sleep)

@Foxboron Personally I think we don't have at this point a working model for spec. It's essentially a proprietary spec because a single Microsoft employee controls it. For me that means that is solely Microsoft controlled spec which is not right.

Up until that is changed, I cannot e.g. accept patches that would add policies for trusted keys. Not saying it should be located in kernel tree but there should some kind of shared repository to discuss about it and propose updates.

In kernel we support only public and private fields essentially with parent auth value and that is what it stays up until there is "community edition" of the spec.

E.g., for me IMA it might be useful if one could apply policy sealed trusted key as the anchor of trust.

@jarkko
The mailing list works fine? I have submitted several patches to the spec at this point.

@Foxboron

OK, tpm2@lists.linux.dev is fine but there is no documented contribution model for the spec :-) It is fine for PoC'ing but unacceptable lock-in for a mainline kernel patch when going beyond importing public and private blobs.

For me "acceptable" here would mean actually having at least a draft in the official IETF pipeline. That would decouple "proprietary control".

E.g., like David has done:

https://datatracker.ietf.org/doc/html/draft-woodhouse-cert-best-practice-00

IETF is not a single stakeholder properietary entity and there's a working model for reviewing and improving drafts.

Backing story with my own Rust TPM2 stack is actually exactly this spec. I created a patch set [1] over a year ago to implement TPM2 parts of this spec but felt that I could not finish it with quality standards that would make me happy because lack of a proper tools for testing the patch set :-)

[1] https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jarkko@kernel.org/

@Foxboron This would also give better visibility to other communities such as *BSD communities. Or who know perhaps e.g., Haiku would want TPM keys too some day? It really cannot be driven like this forever and it is responsible act from me to block any attempts to do so (further).

@jarkko

No, I meant the mailing list for the specc. Which I linked earlier.

openssl-tpm2-engine@groups.io

As for the IETF step, this is why I've submitted patches for creation data. Bottomley wanted that into the specc first.

See: https://github.com/tpm2-software/tpm2-openssl/issues/120#issuecomment-2405327343

@Foxboron OK that is great. Once there is a IETF draft I don't consider it as a Microsoft proprietary product :-)

As a disclaimer, it's not that I would necessarily want to comment on that. I rather adapt and perhaps workaround key spec in my implementation that proactively drive it because it is simply not my thing :-) This is what happend with parentPublic as cache internally handles it. However, as a maintainer I feel safer to accept change if a key type is driven by a real spec, which is not the case with TPMKey ASN.1 definition (YET).

@Foxboron Thanks for bringing me up on speed where things stand. Helps me to do rights things right :-)

@Foxboron I'll bring up the IETF draft topic on the next TPM-RS meeting, which is on 8th of Dec. TPM-RS is like TSS2 type of project driven by Google, Microsoft and well the "usual suspects". I'd like to think that there is common mutual interest to drive this further.

@Foxboron https://github.com/orgs/tpm-rs/discussions/179#discussioncomment-15090227

@Foxboron Full spam thread summarized: https://github.com/tpm2-software/tpm2-openssl/issues/120#issuecomment-3583885470

:-)