Jarkko Sakkinen
jarkko
Edited 6 months ago
I've been fine-tuning the policy and caching engine in tpm2sh a lot and next version will allow to:
1. View policy as an expression via 'tpm2sh memory -p <handle>'
2. Create primary keys with arbitrary policies (was not just done nothing special in it).
3. Creating, viewing and maintaining policies for persistent keys.
These sort of come as "side-effect" of just cleaning up and polishing the groundwork :-)
#linux #tpm #rustlang
1. View policy as an expression via 'tpm2sh memory -p <handle>'
2. Create primary keys with arbitrary policies (was not just done nothing special in it).
3. Creating, viewing and maintaining policies for persistent keys.
These sort of come as "side-effect" of just cleaning up and polishing the groundwork :-)
#linux #tpm #rustlang
0
0
1
Jarkko Sakkinen
jarkko
What are known good workarounds with systemd-creds for situations like this:
https://github.com/himmelblau-idm/himmelblau/issues/901
I can admit that I don't really know what I'm doing ATM :-)
#systemd
https://github.com/himmelblau-idm/himmelblau/issues/901
I can admit that I don't really know what I'm doing ATM :-)
#systemd
0
0
0
@Foxboron @achilleas I have defacto answer for question four: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
0
0
1
@Foxboron Full spam thread summarized: https://github.com/tpm2-software/tpm2-openssl/issues/120#issuecomment-3583885470
:-)
:-)
0
0
0
1
0
0
@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.
1
0
1
Jarkko Sakkinen
jarkko
@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).
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).
1
0
0
@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).
0
0
0
Jarkko Sakkinen
jarkko
@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/
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/
2
0
0
Jarkko Sakkinen
repeated
repeated
OpenAI says dead teen violated TOS when he used ChatGPT to plan suicide.
Ghouls gonna ghoul: Facing five lawsuits alleging wrongful deaths, OpenAI lobbed its first defense Tuesday, denying in a court filing that ChatGPT caused a teen's suicide and...
https://jwz.org/b/ykxy
1
2
0
@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.
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.
1
0
0
@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)
1
0
0
Jarkko Sakkinen
jarkko
@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 :-)
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 :-)
2
0
0
@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.
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.
1
0
1
full asn1 definition: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-tpmkey.git/tree/src/asn1.rs
0
0
0