Re: SVSM vTPM specification

[James Bottomley <jejb@linux.ibm.com>]

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