Re: SVSM vTPM specification

[Steve Rutherford <srutherford@google.com>]

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).

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. 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 compatible with whatever we choose here. Google provides a
trusted AK for existing vTPMs.)

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?

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)

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.)

Thanks,
Steve



On Tue, Oct 25, 2022 at 7:14 AM James Bottomley <jejb@linux.ibm.com> wrote:
>
> On Tue, 2022-10-25 at 11:43 +0200, Christophe de Dinechin wrote:
> > On 2022-10-25 at 11:51 +03, Dov Murik <dovmurik@linux.ibm.com>
> > wrote...
> > > On 24/10/2022 22:02, Tom Lendacky wrote:
> > > > On 10/24/22 06:45, Dov Murik wrote:
> > > > >
> > > > > On 24/10/2022 13:59, Dr. David Alan Gilbert wrote:
> > > > > > * Jon Lange (jlange@microsoft.com) wrote:
> > > > > > > The drawback to having an identifier-prefixed document is
> > > > > > > that it necessarily restricts each report to providing only
> > > > > > > a single statement from a single SVSM protocol.  If, in the
> > > > > > > future, we find it is common for a relying party to
> > > > > > > require, say, five different protocol statements, this
> > > > > > > imposes a requirement to obtain five separate reports.
> > > > > > > This means a minimum of five round trips from the SVSM to
> > > > > > > the PSP, which seems undesirable.  I think we will really
> > > > > > > want to invest in defining an extensible format that can be
> > > > > > > placed into a single report.  I'm not claiming that JSON is
> > > > > > > the only option here, but I think we will regret any format
> > > > > > > that prevents extension within a single report.
> > > > > >
> > > > > > Having something structured does seem to me better than
> > > > > > tacking a magic byte on. (Although as I remember, the SNP
> > > > > > report already contains a flag saying which VMPL level the
> > > > > > request was generated from; whether that's enough to
> > > > > > discriminate between guest requests, and requests by the
> > > > > > firmware I don't know).
> > > > > >
> > > > >
> > > > > The VMPL level is not enough to distinguish between different
> > > > > reports which all originate from the SVSM (for example, let's
> > > > > say we have an SVSM-vTPM report and an SVSM-migration-helper
> > > > > report).
> > > > >
> > > > > I think that the two options presented here are:
> > > > >
> > > > > 1. SNP REPORT_DATA = type_byte + nonce + sha256(extra_data)
> > > > > [James]. The meaning/format of extra_data depends on
> > > > > type_byte.  For now we design just for vtpm (type_byte=0x00).
> > > > > In the future, adding more info (like migration-helper report)
> > > > > will use new type_byte values (0x01,
> > > > > ...).
> > > > >
> > > > > 2. SNP REPORT_DATA = nonce + sha256(extra_data) [Jon].
> > > > > extra_data is a JSON document which may contain a vtpm section,
> > > > > a migration-helper section.  In the future, we can add more
> > > > > info but adding sections to this JSON document.
> > > >
> > > > If I understand this method correctly, the input would be a JSON
> > > > document requesting certain elements (a one-to-one relationship
> > > > or a one-to-many?) and their values be used in generating an
> > > > output JSON document, correct?
> > > >
> > > > That would mean parsing the input document in the SVSM. The SVSM
> > > > would return an error on improper documents. What about
> > > > unidentified fields, would those just be returned with null for
> > > > their values or not included in the output document?
> > >
> > > You mention "input document" -- who would provide it?
>
> I think you have to be more precise about "it".  There are two
> potential types of "it": one is the template you want the SVSM to fill
> in and the other is the JSON document with the values.  I can't really
> see why we'd provide the latter to the SVSM because why would it
> believe our values without checking them and if it knows enough to
> check them why does it need them passed in?
>
> The next problem is there might be values in the template only the SVSM
> knows (this isn't the case for the TPM, but it might be true for the
> migration parameters).
>
> >
> > In the migration-helper case, the migration helper data would not
> > originate from the SVSM itself, would it? So I guess it would have to
> > be provided, presumably in JSON form.
>
> Just from a security point of view, you never want any attestor to
> attest to information it doesn't itself know.  Thus the only input
> information from an unverified source should be the challenge (the
> nonce).  If there's information about the migration the SVSM doesn't
> know and can't verify, it shouldn't be part of the report.
>
> >
> > In other words, I think long term, the SVSM would need to parse
> > _some_ input, but this is a problem we can defer until we actually
> > need it.  For the first iteration, we can certainly generate the
> > “base” JSON entirely from the SVSM. I think both statements are true
> > irrespective of the approach chosen.
> >
> > But Dov's question points to more than just parsing. If the SVSM were
> > to hold information such as migration helper data, we then have to
> > think about storage in the SVSM, e.g. what is maximum size of
> > migration helper data.  Or alternatively, formulate the interface in
> > such a way that it's the caller's responsiblity to provide "fill-in-
> > the-blanks" JSON data with space for the vTPM data, in which case we
> > are back to having to parse JSON input.
>
> Well, no, I don't think you need to do either.  The SVSM has a 32 bit
> protocol definition.  You can just define a new protocol to produce the
> migration report and that can have different input arguments if
> necessary (migrations would need some form of attestation from the
> remote that the local SVSM can verify, so they need more information
> than the SVSM knows at the time).  This does mean that you don't
> necessarily need an input template unless you want to do multiplexed
> reports, which is a decision I'd punt on until a need arises, so I'd
> still keep the SVSM attestation report as not having an input template.
>
> As for storage, the SVSM has access initially to all the memory of the
> VM before it begins OVMF, so it can just take possession of anything it
> needs.  I don't believe at this size we need to design a maximum size
> ... lets see first what uses appear.
>
> > I tend to agree that we'd better think about this scenario ahead of
> > time, just to make sure we can cover it properly in both approaches.
>
> Well, yes and no.  You don't have to boil the ocean designing this, you
> just have to know that the design you chose is extensible (as both
> proposals seem to be).
>
> James
>
>