Re: SVSM vTPM specification

[Dov Murik <dovmurik@linux.ibm.com>]

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?

Actually, it is my understanding that SVSM itself *generates* the JSON
document:

1. Guest calls SVSM protocol GENERATE_ATTESTATION_REPORT(nonce=ABC123).
2. SVSM generates JSON document:

{
  "svsm-info-version": 1,
  "vtpm": {
    "pub_ek": "ABC123",
    "pub_srk": "DEF456"
  },
  "migration-helper": {
    "pub_transport_key": "GHI789"
  }
}

3. SVSM requests PSP SNP attestation report with
   REPORT_DATA = nonce || SHA256(json_doc)
4. SVSM returns signed_attestation_report + json_doc + cert_chain to
   guest.


So I don't see the need for *parsing* JSON (or CBOR, per Dionna's
suggestion) inside the SVSM.


-Dov


> 
>>
>>
>> (please correct me if I didn't get your suggestions)
>>
>>
>> In both approaches, when the guest asks for the report from the SVSM, it
>> will receive:
>>
>> 1. The SNP VMPL0 attestation report (~3KB)
>> 2. The extra_data in plaintext (for vtpm: just two public keys, <1KB)
>> 3. The certs chain from the host (<10KB)
> 
> I do like the idea to provide a JSON type input document from the start
> so that extending attestation reports in the future is easy and
> consistent. I would imagine that it wouldn't take much, from a vTPM
> perspective, to create a JSON string as input for generating the report.
> 
> If we go this route, the attestation request likely should be part of
> the core protocol.
> 
> And by providing the output document in the response, it should be
> pretty easy to recreate the hash.
> 
> Having said that, JSON can be represented a number of ways and so
> canonicalizing the output would be necessary. I found RFC 8785
> (https://www.rfc-editor.org/info/rfc8785) but I'm not sure it's truly a
> standard. Are there any better document formats that would be better?
> 
> Thanks,
> Tom
> 
>>
>>
>> -Dov
>>
>>
>>>> I'm having a hard time understanding any scenario that involves an
>>>> entity that has access both to an SNP report and the vTPM and which
>>>> also needs to verify the report.  If the objective is for the guest
>>>> (which has access to the vTPM) to obtain the TPM's endorsement key,
>>>> then it could obtain it directly via the vTPM protocol without
>>>> requiring the SNP report.  After all, the vTPM SVSM protocol does
>>>> not need to be limited to providing exactly the functionality of the
>>>> vTPM command set, but can also include other utilities that are
>>>> useful to the guest.  If the objective is for an external party to
>>>> obtain information about the vTPM, then it doesn't have access to
>>>> the vTPM anyway and will have to rely solely on what's in the report.
>>>
>>>> If the vTPM endorsement key is rooted to a well-known certificate,
>>>> then the TPM certificate can be provided directly by the guest
>>>> without relying on any SNP report (in exactly the same way that
>>>> physical TPMs do not rely on a separate hardware root of trust to
>>>> authenticate them).  Can you shed some light on scenarios in which
>>>> you think the guest has no choice but to compare the SNP report and
>>>> the vTPM state to verify that they match?
>>>
>>> I think that depends on the lifetime of the keys, and who manages them.
>>> If you're in a cloud environment where something apparently trusted is
>>> managing the state of your vTPMs, you might be able to do what you say;
>>> but then you still need a mechanism somewhere to get the SNP state
>>> to the trusted entity that then provides your vTPM state before anything
>>> in the guest uses the vTPM stored state.
>>>
>>> I think the argument is that if you used an ephemeral set of vTPM state,
>>> then at any time after boot you could provide a combined vTPM+SNP
>>> attestation report to a third party who would do the normal TPM
>>> validation and then do the SNP validation.  That avoids the need for
>>> magically loading state from some trusted entity in the firmware.
>>>
>>> Dave
>>>
>>>>
>>>> -Jon
>>>>
>>>> -----Original Message-----
>>>> From: James Bottomley <jejb@linux.ibm.com>
>>>> Sent: Friday, October 21, 2022 6:04 AM
>>>> To: Jon Lange <jlange@microsoft.com>; David Altobelli
>>>> <David.Altobelli@microsoft.com>; Steve Rutherford
>>>> <srutherford@google.com>
>>>> Cc: Daniel P. Berrangé <berrange@redhat.com>; Christophe de Dinechin
>>>> <cdupontd@redhat.com>; linux-coco@lists.linux.dev;
>>>> amd-sev-snp@lists.suse.com
>>>> Subject: [EXTERNAL] RE: SVSM vTPM specification
>>>>
>>>> On Fri, 2022-10-21 at 00:02 +0000, Jon Lange wrote:
>>>>> Surely the primary value of a document hash is to prove its
>>>>> authenticity, not to determine whether two documents reflect identical
>>>>> information.  I understand your concern that two "canonical"
>>>>> representations of the same data may result in different JSON
>>>>> encodings and therefore produce different hashes, but as long as each
>>>>> document can be authenticated by its hash, does it really matter if
>>>>> the hashes of the two documents are different?
>>>>
>>>> If you only have an AMD-SNP attestation report and access to the
>>>> vTPM, you have to query the TPM properties then construct and hash
>>>> the document yourself to verify the report.  I sometimes think half
>>>> the history of security protocol implementation consists of one
>>>> engineer struggling to reproduce the hash created and signed by
>>>> another, which is why I have a preference for it being exactly
>>>> specified and simple.
>>>>
>>>>> There is a ton of discussion here about vTPM because it's an important
>>>>> problem, and it is valuable to recognize that a vTPM implementation
>>>>> will likely require some sort of SVSM-issued document to describe that
>>>>> vTPM.  There's no reason to back away from defining the structure of
>>>>> such an SVSM-issued document.  But we should also expect that in the
>>>>> next 2-3 years, we're going to invent other valuable functionality
>>>>> that an SVSM can implement that will also require the SVSM to issue
>>>>> some sort of authenticated statement.  If we marry the SVSM report
>>>>> information to a vTPM, then it's going to be really hard to add that
>>>>> new functionality, and if we don't anticipate the need for
>>>>> extensibility, then we're going to wind up in a future where an SVSM
>>>>> will issue different kinds of authenticated information (vTPM on one
>>>>> hand and new feature on the other) and the relying party won't be able
>>>>> to know which is which.  I don't see how we can avoid the problem of
>>>>> defining an extensible document schema now that we can extend in the
>>>>> future as the role of the SVSM expands.  JSON is an extremely
>>>>> attractive syntax for such a schema - certainly much more so than XML,
>>>>> and also likely to fare much better than any binary standard.
>>>>
>>>> Allowing the relying party to know what type of authentication was
>>>> why I proposed a type prefix to the guest data in the report.  The
>>>> reason I like the type in the guest data and not the hash is so the
>>>> bare report is self identifying even if it costs us a byte or two of
>>>> the nonce.
>>>>
>>>> There are 2^32-1 possible SVSM protocols, so nothing in the above
>>>> precludes adding a json based hash call if a need arises (or indeed
>>>> many other binary/json/xml ones if that's what people prefer).
>>>>
>>>> James
>>>>
>>>>
>>