From: James Bottomley <jejb@linux.ibm.com>
To: Steve Rutherford <srutherford@google.com>
Cc: "Christophe de Dinechin" <cdupontd@redhat.com>,
"Dov Murik" <dovmurik@linux.ibm.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"David Altobelli" <David.Altobelli@microsoft.com>,
"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
"amd-sev-snp@lists.suse.com" <amd-sev-snp@lists.suse.com>
Subject: Re: SVSM vTPM specification
Date: Sat, 29 Oct 2022 09:27:15 -0400 [thread overview]
Message-ID: <86a90a4530af01f94ba58c73d5c1750cea682476.camel@linux.ibm.com> (raw)
In-Reply-To: <CABayD+e5LYgNvuu1-Pd9LmKHiWZr5HcfTX9ueG8ibvq8zmAPhQ@mail.gmail.com>
On Fri, 2022-10-28 at 17:25 -0700, Steve Rutherford wrote:
> Seems like this thread has petered out a bit, but without all the
> concrete details. A few remaining questions I have:
>
> 1) Is JSON good enough? or should the report use CBOR? (Both seem
> fine. CBOR seems popular for similar situations).
Well, neither I would think. If everyone's determined to use a key
value representation, the utility of which I still question since we
have no current need for it, then we'd should at least use one that has
a natural representation for binary data (the only thing the vTPM wants
to return), which neither JSON nor CBOR have.
> 2) Do the contents of the vtpm sub-section need to be pre-specified
> (i.e. standardized)? Or are they going to be completely customizable?
> (For example, there are many standard EKs, though the ECC one
> (template L-2) is probably the one most people will want.
The TCG is having a bit of rapid evolution on this:
https://trustedcomputinggroup.org/resource/tcg-ek-credential-profile-for-tpm-family-2-0/
However, all their previous specs only had L-1 for RSA and L-2 for EC,
and manufacturers have so far only produced physical TPMs based on
that, so I think we would too. I think L-2 is best because EC keys are
small and have the NIST preferred 128 bits of security.
> I've discussed the idea of an ephemeral "null hierarchy only" TPM
> with some coworkers, but that would complicate standardization of any
> EK in these reports. I'd also like to bolt on an AK (i.e. a default
> EK-like signing key in the endorsement hierarchy) to some reports we
> end up providing, but I don't see a need for that to be guaranteed in
> every report. It just needs to be c ompatible with whatever we choose
> here. Google provides a trusted AK for existing vTPMs.)
I've got to ask why? The reason for using an AK is because the TPM
protocol tries to anonymize quotes, so the EK proves the AK to a
privacy CA and the privacy CA vouches for the AK to the relying party
but the relying party can't use the quote or the AK to track the TPM.
If you don't need the privacy property (which you lose if you provide
the AK) you just make the EK able to sign as well as encyrpt, so the EK
can also be the trusted AK. There's no need to add additional
complexity. I suggested a while back we might want a signing EK for
this reason, since the guest owner both verifies the vTPM and consumes
the quotes there's no need for privacy.
> 3) If reports are customizable, how do we avoid collisions that could
> lead to misinterpretations across vendors? Do reports need a
> vendor-specific key carved out for individual vendors to scribble in?
There's a nonce to prevent reply and provide a challenge/response
security check. I would also think that if a key value representation
is chosen, the values would be standardized for each key and all the
vendor could do is choose keys. This is why I think we're over
designing. As long as the report can be extended, we can leave arguing
over the future extensions when they come along. Right at the moment
we're wasting an enormous amount of time arguing over potential future
extensions, while not addressing the current problem of what
information does the current vTPM report need to provide? Just p256 EC
or p256 EK+SRK or something else?
> 4) Are there going to be any custom inputs that get passed through
> from the guest to the report other than a nonce? (I think the answer
> is no, but want to make sure I'm not missing something here)
I think only nonce.
> 5) How will all of this interact with persistent storage of the
> seeds/NVDATA? (My current thought is that the report should summarize
> how the SVSM stored its NVDATA and who/what it trusted. So long as
> it's possible to add those details to the report, I'm not sure we
> need to align on the precise details of NVDATA-persistence
> attestation right now.)
We already discussed that upthread. the conclusion was:
https://lore.kernel.org/all/Y0%2F2D93P%2Fxgp1sU9@redhat.com/
The persistent data has to be injected into the SVSM via secret
injection so you trust it a priori.
James
next prev parent reply other threads:[~2022-10-29 13:27 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-12 16:38 SVSM vTPM specification Tom Lendacky
2022-10-12 17:33 ` Dr. David Alan Gilbert
2022-10-12 18:44 ` James Bottomley
2022-10-13 15:14 ` Tom Lendacky
2022-10-13 15:29 ` Daniele Buono
2022-10-13 15:30 ` James Bottomley
2022-10-18 20:22 ` Dov Murik
2022-10-19 5:47 ` Christophe de Dinechin
2022-10-19 6:39 ` Dov Murik
2022-10-19 8:08 ` Daniel P. Berrangé
2022-10-19 12:09 ` Christophe de Dinechin
2022-10-19 12:38 ` James Bottomley
2022-10-19 13:05 ` Daniel P. Berrangé
2022-10-19 14:43 ` Tom Lendacky
2022-10-19 15:20 ` James Bottomley
2022-10-19 21:58 ` Tom Lendacky
2022-10-19 20:57 ` Dov Murik
2022-10-19 22:04 ` Tom Lendacky
2022-10-19 22:14 ` Dionna Amalie Glaze
2022-10-19 23:38 ` James Bottomley
2022-10-19 22:36 ` [EXTERNAL] " David Altobelli
[not found] ` <CABayD+cYCj=uOtC5h1d781jh_B6XqxmZNfR69taEex7yvkizRw@mail.gmail.com>
[not found] ` <SJ0PR21MB132378C080FFED1E283B4051E92A9@SJ0PR21MB1323.namprd21.prod.outlook.com>
2022-10-20 20:29 ` James Bottomley
2022-10-21 0:02 ` [EXTERNAL] " Jon Lange
2022-10-21 13:04 ` James Bottomley
2022-10-21 16:31 ` [EXTERNAL] " Jon Lange
2022-10-22 3:20 ` James Bottomley
2022-10-24 4:51 ` [EXTERNAL] " Jon Lange
2022-10-24 10:59 ` Dr. David Alan Gilbert
2022-10-24 11:45 ` Dov Murik
2022-10-24 19:02 ` Tom Lendacky
2022-10-24 19:18 ` Dionna Amalie Glaze
2022-10-25 8:51 ` Dov Murik
2022-10-25 9:43 ` Christophe de Dinechin
2022-10-25 14:08 ` Tom Lendacky
2022-10-25 14:13 ` James Bottomley
2022-10-29 0:25 ` Steve Rutherford
2022-10-29 13:27 ` James Bottomley [this message]
2022-10-19 11:21 ` Dr. David Alan Gilbert
2022-10-19 11:45 ` James Bottomley
2022-10-12 19:05 ` James Bottomley
2022-10-13 18:54 ` Tom Lendacky
2022-10-13 19:20 ` James Bottomley
2022-10-13 20:54 ` Daniel P. Smith
2022-10-13 21:06 ` James Bottomley
2022-10-13 21:14 ` Daniel P. Smith
2022-10-13 21:41 ` James Bottomley
2022-10-14 17:16 ` Stuart Yoder
2022-10-14 21:46 ` Tom Lendacky
2022-10-16 16:29 ` Daniel P. Smith
2022-10-16 16:44 ` James Bottomley
2022-10-21 11:54 ` Daniel P. Smith
2022-10-21 12:31 ` James Bottomley
2022-10-18 20:45 ` Dov Murik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86a90a4530af01f94ba58c73d5c1750cea682476.camel@linux.ibm.com \
--to=jejb@linux.ibm.com \
--cc=David.Altobelli@microsoft.com \
--cc=amd-sev-snp@lists.suse.com \
--cc=berrange@redhat.com \
--cc=cdupontd@redhat.com \
--cc=dovmurik@linux.ibm.com \
--cc=linux-coco@lists.linux.dev \
--cc=srutherford@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).