SVSM vTPM specification

SVSM vTPM specification

[Tom Lendacky]

I'd like to approach this from the standpoint of an enlightened guest with 
a TPM driver that is SVSM aware. I'm by no means a TPM expert, but I'll 
pose a bunch of questions to see if we can start moving forward.

What would an enlightened guest need from the SVSM for attestation of the 
SVSM/vTPM? What would a vTPM driver need to supply to an SVSM for TPM 
operations?

For attestation, the SVSM could provide a VMPCK0 attestation report. What, 
if any, data should the guest supply to the SVSM to be part of the SNP 
attestation report data? Should this attestation request be part of the 
SVSM base protocol?

For the TPM, is it enough to emulate the TPM device register space? Rather 
than using a PCI BAR or an ACPI memory resource address, could the vTPM 
driver replicate the TPM register space in ordinary memory for the SVSM to 
process? Should this memory come from the SVSM or from the guest?

Or is there a better, more efficient method that can be used to perform 
TPM operations? What would that look like?

Here's hoping this starts the discussion...

Thanks,
Tom

Re: SVSM vTPM specification

[Dr. David Alan Gilbert]

* Tom Lendacky (thomas.lendacky@amd.com) wrote:
> I'd like to approach this from the standpoint of an enlightened guest with a
> TPM driver that is SVSM aware. I'm by no means a TPM expert, but I'll pose a
> bunch of questions to see if we can start moving forward.

Thanks for starting the discussion off.

> What would an enlightened guest need from the SVSM for attestation of the
> SVSM/vTPM? What would a vTPM driver need to supply to an SVSM for TPM
> operations?
> 
> For attestation, the SVSM could provide a VMPCK0 attestation report. What,
> if any, data should the guest supply to the SVSM to be part of the SNP
> attestation report data? Should this attestation request be part of the SVSM
> base protocol?

I'm not quite sure what a 'VMPCK0 attestation report' is?
It's important that the VMPL level in the attestation report reflects
the side asking for the attestation; in particular one TPM story goes
that the firmware (in VMPL0) would ask for an attestation and the
attestor would return the vTPM stored state.  It's important that the
state could only be returned to the vTPM not the guest, so the attestor
would check that the VMPL level in the attestation was 0; any guest
attestation would have a VMPL>0 and so the attestor wouldn't hand it the
vTPM state.
Hmm or are you saying such a report would be triggered by the guest
rather than the firmware, but it would be protected by VMPCK0 so the
guest wouldn't be able to read it?

I think one of the vTPMs keys should be in the SNP attestation report
(the EK???) - I think that would allow you to attest that the vTPM
you're talking to is a vTPM running in an SNP protected firmware.

> For the TPM, is it enough to emulate the TPM device register space? Rather
> than using a PCI BAR or an ACPI memory resource address, could the vTPM
> driver replicate the TPM register space in ordinary memory for the SVSM to
> process? Should this memory come from the SVSM or from the guest?
> 
> Or is there a better, more efficient method that can be used to perform TPM
> operations? What would that look like?

Can we make this look as close to the TPM CRB as possible; from
discussions with others it looks clear something extra is needed; but I
don't see the reason to be too inventive.

Dave

> Here's hoping this starts the discussion...
> 
> Thanks,
> Tom
> 
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: SVSM vTPM specification

[James Bottomley]

On Wed, 2022-10-12 at 18:33 +0100, Dr. David Alan Gilbert wrote:
> * Tom Lendacky (thomas.lendacky@amd.com) wrote:
[...]
> > What would an enlightened guest need from the SVSM for attestation
> > of the SVSM/vTPM? What would a vTPM driver need to supply to an
> > SVSM for TPM operations?
> > 
> > For attestation, the SVSM could provide a VMPCK0 attestation
> > report. What, if any, data should the guest supply to the SVSM to
> > be part of the SNP attestation report data? Should this attestation
> > request be part of the SVSM base protocol?
> 
> I'm not quite sure what a 'VMPCK0 attestation report' is?
> It's important that the VMPL level in the attestation report reflects
> the side asking for the attestation; in particular one TPM story goes
> that the firmware (in VMPL0) would ask for an attestation and the
> attestor would return the vTPM stored state.  It's important that the
> state could only be returned to the vTPM not the guest, so the
> attestor would check that the VMPL level in the attestation was 0;
> any guest attestation would have a VMPL>0 and so the attestor
> wouldn't hand it the vTPM state.
> Hmm or are you saying such a report would be triggered by the guest
> rather than the firmware, but it would be protected by VMPCK0 so the
> guest wouldn't be able to read it?
> 
> I think one of the vTPMs keys should be in the SNP attestation report
> (the EK???) - I think that would allow you to attest that the vTPM
> you're talking to is a vTPM running in an SNP protected firmware.

Traditionally the TPM identity is the public EK, so that should
definitely be in the report.  Ideally, I think the public storage root
key (key derived from the owner seed) should be in there two because it
makes it easy to create keys that can only be read by the TPM (keys
should be in the owner hierarchy which means they have to be encrypted
to the storage seed, so we need to know what a public key corresponding
to it is).

One wrinkle of the above is that, when provisioned, the TPM will only
have the seeds, not the keys (the keys are derived from the seeds via a
TPM2_CreatePrimary command).  The current TPM provisioning guidance:

https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/

Says that the EK should be at permanent handle

81010001

And there's an update saying that should be the RSA-2048 key and there
should be an EC (NIST-P256) one at 81010002.  The corresponding storage
keys should be at 81000001 and 81000002 respectively.  I think when the
SVSM provisions the TPM, it should run TPM2_CreatePrimary for those
four keys and put them into the persistent indexes, then insert the EC
keys only for EK and SRK into the attestation report.

James

Re: SVSM vTPM specification

[James Bottomley]

On Wed, 2022-10-12 at 18:33 +0100, Dr. David Alan Gilbert wrote:
> * Tom Lendacky (thomas.lendacky@amd.com) wrote:
[...]
> > For the TPM, is it enough to emulate the TPM device register space?
> > Rather than using a PCI BAR or an ACPI memory resource address,
> > could the vTPM driver replicate the TPM register space in ordinary
> > memory for the SVSM to process? Should this memory come from the
> > SVSM or from the guest?

To emulate an existing TPM device, you'd also have to emulate its
discovery mechanism (traditionally ACPI for the CRB TPM).  If you don't
do that you might as well invent a completely new mechanism that suits
the SVSM but requires a new driver.

> > Or is there a better, more efficient method that can be used to
> > perform TPM operations? What would that look like?
> 
> Can we make this look as close to the TPM CRB as possible; from
> discussions with others it looks clear something extra is needed; but
> I don't see the reason to be too inventive.

It is theoretically possible to emulate a CRB TPM with just a single
communication page and an ACPI entry (the Linux CRB driver is ACPI only
at this time and responds to the "MSFT0101" ACPI entry).

The CRB device responds to a very compact MMIO region (0x30 bytes long)
described in the CRB spec:

https://trustedcomputinggroup.org/resource/tpm-2-0-mobile-command-response-buffer-interface-specification/

In theory we could use a page that keeps trapping to the SVSM for this,
but the problem is that the CRB driver polls a register in the MMIO
region to check command completion, so even a single TPM command is
going to generate a huge number of such traps.  So while it's
theoretically possible to generate a SVSM emulation of the CRB device,
it would likely be too expensive in terms of traps, particularly if
we're using the SVSM vTPM for runtime measurements like IMA.

If we're going to do a new driver, I think basing it off the CRB spec
would be fine (the spec envisages command request/response being via
areas outside the MMIO region) and we could simply do a new driver that
plumbs directly into the nine operations in the tpm_class_ops structure

James

Re: SVSM vTPM specification

[Tom Lendacky]

On 10/12/22 13:44, James Bottomley wrote:
> On Wed, 2022-10-12 at 18:33 +0100, Dr. David Alan Gilbert wrote:
>> * Tom Lendacky (thomas.lendacky@amd.com) wrote:
> [...]
>>> What would an enlightened guest need from the SVSM for attestation
>>> of the SVSM/vTPM? What would a vTPM driver need to supply to an
>>> SVSM for TPM operations?
>>>
>>> For attestation, the SVSM could provide a VMPCK0 attestation
>>> report. What, if any, data should the guest supply to the SVSM to
>>> be part of the SNP attestation report data? Should this attestation
>>> request be part of the SVSM base protocol?
>>
>> I'm not quite sure what a 'VMPCK0 attestation report' is?

Right, I meant VMPL0 and that probably generated some confusion. The SVSM 
will use the VMPCK0 key for communicating with the PSP. That key is 
cleared from the guest's Secrets Page so that the guest can't use it and 
mess with the SVSM's communication path.

>> It's important that the VMPL level in the attestation report reflects
>> the side asking for the attestation; in particular one TPM story goes
>> that the firmware (in VMPL0) would ask for an attestation and the
>> attestor would return the vTPM stored state.  It's important that the
>> state could only be returned to the vTPM not the guest, so the
>> attestor would check that the VMPL level in the attestation was 0;
>> any guest attestation would have a VMPL>0 and so the attestor
>> wouldn't hand it the vTPM state.
>> Hmm or are you saying such a report would be triggered by the guest
>> rather than the firmware, but it would be protected by VMPCK0 so the
>> guest wouldn't be able to read it?

No, the VMPCK0 key is just used for communication with the PSP.

While the SVSM would request the attestation report from the PSP, the 
guest would need to request it from the SVSM.

>>
>> I think one of the vTPMs keys should be in the SNP attestation report
>> (the EK???) - I think that would allow you to attest that the vTPM
>> you're talking to is a vTPM running in an SNP protected firmware.
> 
> Traditionally the TPM identity is the public EK, so that should
> definitely be in the report.  Ideally, I think the public storage root
> key (key derived from the owner seed) should be in there two because it
> makes it easy to create keys that can only be read by the TPM (keys
> should be in the owner hierarchy which means they have to be encrypted
> to the storage seed, so we need to know what a public key corresponding
> to it is).
> 
> One wrinkle of the above is that, when provisioned, the TPM will only
> have the seeds, not the keys (the keys are derived from the seeds via a
> TPM2_CreatePrimary command).  The current TPM provisioning guidance:
> 
> https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/
> 
> Says that the EK should be at permanent handle
> 
> 81010001
> 
> And there's an update saying that should be the RSA-2048 key and there
> should be an EC (NIST-P256) one at 81010002.  The corresponding storage
> keys should be at 81000001 and 81000002 respectively.  I think when the
> SVSM provisions the TPM, it should run TPM2_CreatePrimary for those
> four keys and put them into the persistent indexes, then insert the EC
> keys only for EK and SRK into the attestation report.

We only have 512 bits to work with for the SVSM-provided data, so would 
hashes of the keys be ok?

Thanks,
Tom

> 
> James
> 
> 

RE: SVSM vTPM specification

[Daniele Buono]

Hi Tom,

> -----Original Message-----
> From: AMD-SEV-SNP <amd-sev-snp-
> bounces+dbuono=us.ibm.com@lists.suse.com> On Behalf Of Tom Lendacky
> Sent: Thursday, October 13, 2022 11:15 AM
> To: jejb@linux.ibm.com; Dr. David Alan Gilbert <dgilbert@redhat.com>
> Cc: amd-sev-snp@lists.suse.com; linux-coco@lists.linux.dev
> Subject: [EXTERNAL] Re: SVSM vTPM specification
> 
> On 10/12/22 13:44, James Bottomley wrote:
> > On Wed, 2022-10-12 at 18:33 +0100, Dr. David Alan Gilbert wrote:
> >> * Tom Lendacky (thomas.lendacky@amd.com) wrote:
> > [...]
> >>> What would an enlightened guest need from the SVSM for attestation
> >>> of the SVSM/vTPM? What would a vTPM driver need to supply to an
> SVSM
> >>> for TPM operations?
> >>>
> >>> For attestation, the SVSM could provide a VMPCK0 attestation report.
> >>> What, if any, data should the guest supply to the SVSM to be part of
> >>> the SNP attestation report data? Should this attestation request be
> >>> part of the SVSM base protocol?
> >>
> >> I'm not quite sure what a 'VMPCK0 attestation report' is?
> 
> Right, I meant VMPL0 and that probably generated some confusion. The
> SVSM will use the VMPCK0 key for communicating with the PSP. That key is
> cleared from the guest's Secrets Page so that the guest can't use it and
> mess with the SVSM's communication path.
> 
> >> It's important that the VMPL level in the attestation report reflects
> >> the side asking for the attestation; in particular one TPM story goes
> >> that the firmware (in VMPL0) would ask for an attestation and the
> >> attestor would return the vTPM stored state.  It's important that the
> >> state could only be returned to the vTPM not the guest, so the
> >> attestor would check that the VMPL level in the attestation was 0;
> >> any guest attestation would have a VMPL>0 and so the attestor
> >> wouldn't hand it the vTPM state.
> >> Hmm or are you saying such a report would be triggered by the guest
> >> rather than the firmware, but it would be protected by VMPCK0 so the
> >> guest wouldn't be able to read it?
> 
> No, the VMPCK0 key is just used for communication with the PSP.
> 
> While the SVSM would request the attestation report from the PSP, the
> guest would need to request it from the SVSM.
> 
> >>
> >> I think one of the vTPMs keys should be in the SNP attestation report
> >> (the EK???) - I think that would allow you to attest that the vTPM
> >> you're talking to is a vTPM running in an SNP protected firmware.
> >
> > Traditionally the TPM identity is the public EK, so that should
> > definitely be in the report.  Ideally, I think the public storage root
> > key (key derived from the owner seed) should be in there two because
> > it makes it easy to create keys that can only be read by the TPM (keys
> > should be in the owner hierarchy which means they have to be encrypted
> > to the storage seed, so we need to know what a public key
> > corresponding to it is).
> >
> > One wrinkle of the above is that, when provisioned, the TPM will only
> > have the seeds, not the keys (the keys are derived from the seeds via
> > a TPM2_CreatePrimary command).  The current TPM provisioning
> guidance:
> >
> > INVALID URI REMOVED
> 3A__trustedcomputingg
> > roup.org_resource_tcg-2Dtpm-2Dv2-2D0-2Dprovisioning-
> 2Dguidance_&d=DwIC
> > aQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=PwDj5KLZD0wJ1gHoNzzrSBtXihtcmpgmu1Gfvz90
> > OiI&m=CbwmAU6ST66wtEQFuQ4qta94ARMF3LuG37PEZv4VBvYtYy3EC-
> 3V59r8mnnWLQ4s
> > &s=jymS8y4c8HHr1EPKei62NGSAXYBI4Dnm3hCpHrtJUc8&e=
> >
> > Says that the EK should be at permanent handle
> >
> > 81010001
> >
> > And there's an update saying that should be the RSA-2048 key and there
> > should be an EC (NIST-P256) one at 81010002.  The corresponding
> > storage keys should be at 81000001 and 81000002 respectively.  I think
> > when the SVSM provisions the TPM, it should run TPM2_CreatePrimary
> for
> > those four keys and put them into the persistent indexes, then insert
> > the EC keys only for EK and SRK into the attestation report.
> 
> We only have 512 bits to work with for the SVSM-provided data, so would
> hashes of the keys be ok?

I believe so. When we discussed it internally, we decided that providing the
hash of the keys in the attestation report, and the keys themselves with an
unattested mechanism should be fine.
We can use the hashes to verify that the full keys obtained elsewhere are
indeed the ones generated here.

> 
> Thanks,
> Tom
> 
> >
> > James
> >
> >

Re: SVSM vTPM specification

[James Bottomley]

On Thu, 2022-10-13 at 10:14 -0500, Tom Lendacky wrote:
> On 10/12/22 13:44, James Bottomley wrote:
> > On Wed, 2022-10-12 at 18:33 +0100, Dr. David Alan Gilbert wrote:
> > > * Tom Lendacky (thomas.lendacky@amd.com) wrote:
> > [...]
> > > It's important that the VMPL level in the attestation report
> > > reflects the side asking for the attestation; in particular one
> > > TPM story goes that the firmware (in VMPL0) would ask for an
> > > attestation and the attestor would return the vTPM stored
> > > state.  It's important that the state could only be returned to
> > > the vTPM not the guest, so the attestor would check that the VMPL
> > > level in the attestation was 0; any guest attestation would have
> > > a VMPL>0 and so the attestor wouldn't hand it the vTPM state.
> > > Hmm or are you saying such a report would be triggered by the
> > > guest rather than the firmware, but it would be protected by
> > > VMPCK0 so the guest wouldn't be able to read it?
> 
> No, the VMPCK0 key is just used for communication with the PSP.
> 
> While the SVSM would request the attestation report from the PSP,
> the guest would need to request it from the SVSM.

I think this is fine.  The SVSM would do the attestation as it starts
the TPM but the guest would be able to retrieve it at any time. 
Essentially, if you use something like keylime, the agent would request
it on start up to prove it should trust the vTPM, but that could occur
way after VM boot.

> 
> > > I think one of the vTPMs keys should be in the SNP attestation
> > > report (the EK???) - I think that would allow you to attest that
> > > the vTPM you're talking to is a vTPM running in an SNP protected
> > > firmware.
> > 
> > Traditionally the TPM identity is the public EK, so that should
> > definitely be in the report.  Ideally, I think the public storage
> > root key (key derived from the owner seed) should be in there two
> > because it makes it easy to create keys that can only be read by
> > the TPM (keys should be in the owner hierarchy which means they
> > have to be encrypted to the storage seed, so we need to know what a
> > public key corresponding to it is).
> > 
> > One wrinkle of the above is that, when provisioned, the TPM will
> > only have the seeds, not the keys (the keys are derived from the
> > seeds via a TPM2_CreatePrimary command).  The current TPM
> > provisioning guidance:
> > 
> > https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/
> > 
> > Says that the EK should be at permanent handle
> > 
> > 81010001
> > 
> > And there's an update saying that should be the RSA-2048 key and
> > there should be an EC (NIST-P256) one at 81010002.  The
> > corresponding storage keys should be at 81000001 and 81000002
> > respectively.  I think when the SVSM provisions the TPM, it should
> > run TPM2_CreatePrimary for those four keys and put them into the
> > persistent indexes, then insert the EC keys only for EK and SRK
> > into the attestation report.
> 
> We only have 512 bits to work with for the SVSM-provided data, so
> would hashes of the keys be ok?

Well, if you put the hashes in, the consuming entity would then have to
find out via an additional channel what the actual keys were because
you can't reverse the hash (it's possible, just more effort).  If you
use point compression, an EC key (for the NIST p-256 curve) is only 32
bytes anyway, so it's the same size as a sha256 hash, so I'd say place
the actual public keys into the report to give complete and usable
information

James

Re: SVSM vTPM specification

[Tom Lendacky]

On 10/12/22 14:05, James Bottomley wrote:
> On Wed, 2022-10-12 at 18:33 +0100, Dr. David Alan Gilbert wrote:
>> * Tom Lendacky (thomas.lendacky@amd.com) wrote:
...
> 
> It is theoretically possible to emulate a CRB TPM with just a single
> communication page and an ACPI entry (the Linux CRB driver is ACPI only
> at this time and responds to the "MSFT0101" ACPI entry).
> 
> The CRB device responds to a very compact MMIO region (0x30 bytes long)
> described in the CRB spec:
> 
> https://trustedcomputinggroup.org/resource/tpm-2-0-mobile-command-response-buffer-interface-specification/
> 
> In theory we could use a page that keeps trapping to the SVSM for this,
> but the problem is that the CRB driver polls a register in the MMIO
> region to check command completion, so even a single TPM command is
> going to generate a huge number of such traps.  So while it's
> theoretically possible to generate a SVSM emulation of the CRB device,
> it would likely be too expensive in terms of traps, particularly if
> we're using the SVSM vTPM for runtime measurements like IMA.
> 
> If we're going to do a new driver, I think basing it off the CRB spec
> would be fine (the spec envisages command request/response being via
> areas outside the MMIO region) and we could simply do a new driver that
> plumbs directly into the nine operations in the tpm_class_ops structure
> 

This sounds good. I think we can model an API call to the SVSM vTPM using 
this. We can provide a struct that looks similar to the CRB Control Area 
and supply the GPA of this struct in RCX to the SVSM for the vTPM to 
perform the operation:

     - Command GPA
     - Command Size
     - Response GPA
     - Response Size
     - Status

Anything else that would go in the struct? Locality?

Thanks,
Tom

> James
> 
> 

Re: SVSM vTPM specification

[James Bottomley]

On Thu, 2022-10-13 at 13:54 -0500, Tom Lendacky wrote:
> On 10/12/22 14:05, James Bottomley wrote:
> > On Wed, 2022-10-12 at 18:33 +0100, Dr. David Alan Gilbert wrote:
> > > * Tom Lendacky (thomas.lendacky@amd.com) wrote:
> ...
> > It is theoretically possible to emulate a CRB TPM with just a
> > single
> > communication page and an ACPI entry (the Linux CRB driver is ACPI
> > only
> > at this time and responds to the "MSFT0101" ACPI entry).
> > 
> > The CRB device responds to a very compact MMIO region (0x30 bytes
> > long)
> > described in the CRB spec:
> > 
> > https://trustedcomputinggroup.org/resource/tpm-2-0-mobile-command-response-buffer-interface-specification/
> > 
> > In theory we could use a page that keeps trapping to the SVSM for
> > this,
> > but the problem is that the CRB driver polls a register in the MMIO
> > region to check command completion, so even a single TPM command is
> > going to generate a huge number of such traps.  So while it's
> > theoretically possible to generate a SVSM emulation of the CRB
> > device,
> > it would likely be too expensive in terms of traps, particularly if
> > we're using the SVSM vTPM for runtime measurements like IMA.
> > 
> > If we're going to do a new driver, I think basing it off the CRB
> > spec
> > would be fine (the spec envisages command request/response being
> > via
> > areas outside the MMIO region) and we could simply do a new driver
> > that
> > plumbs directly into the nine operations in the tpm_class_ops
> > structure
> > 
> 
> This sounds good. I think we can model an API call to the SVSM vTPM
> using 
> this. We can provide a struct that looks similar to the CRB Control
> Area 
> and supply the GPA of this struct in RCX to the SVSM for the vTPM to 
> perform the operation:
> 
>      - Command GPA
>      - Command Size
>      - Response GPA
>      - Response Size
>      - Status

Realistically, I think all TPM2 command/response actions can be packed
into

u32 TPM2_action(u64 command_gpa, u32 command_len, u64 response_gpa, u32
*response_len)

Where the u32 return would be the status (although if the SVSM has
trouble with the return status, we could add it as an extra modified
variable).

The way the current TPM driver interface works is shown in the
tpm_class_ops structure:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/tpm.h

we can shim all the non-ignorable calls into the above.  The standard
way of sending a command is tpm_try_transmit in

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm-interface.c

I think we can emulate an interrupt driven tpm (set TPM_CHIP_FLAG_IRQ
in the driver) and it will simply do a ->send() ->receive() pair, which
works for us since the thread of execution in ->send() will pass into
the SVSM and return with the result which we can then copy over in
->recv

Also note that tpm_try_transmit() uses the same buffer for send and
receive, so it is possible to reduce the number of parameters in
TPM2_action() above if that's the route people want to go.

> Anything else that would go in the struct? Locality?

Well, this is a question.  CRB devices are actually allowed not to have
a locality at all, so ignoring it is perfectly legal.  On the other
hand, locality is used to allow or deny certain accesses. 
Traditionally you allow firmware access at locality 4 as the trusted
hardware component.  However, the problem with implementing localities
is how does the SVSM know where we're calling from?  If it's unable to
bar access at certain localities, there's not much point implementing
them.  For reference the TIS TPM implements separate memory maps of its
registers, one for each locality and firmware bars access to the OS by
unmapping a range and refusing to allow the OS to map it back.

I suspect we'd get on faster by being pejorative and saying we won't
implement locality since we can't police it.

James
 

Re: SVSM vTPM specification

[Daniel P. Smith]

Pardon the interjection.

On 10/13/22 15:20, James Bottomley wrote:
> On Thu, 2022-10-13 at 13:54 -0500, Tom Lendacky wrote:
>> On 10/12/22 14:05, James Bottomley wrote:
>>> On Wed, 2022-10-12 at 18:33 +0100, Dr. David Alan Gilbert wrote:
>>>> * Tom Lendacky (thomas.lendacky@amd.com) wrote:
>> ...
>>> It is theoretically possible to emulate a CRB TPM with just a
>>> single
>>> communication page and an ACPI entry (the Linux CRB driver is ACPI
>>> only
>>> at this time and responds to the "MSFT0101" ACPI entry).
>>>
>>> The CRB device responds to a very compact MMIO region (0x30 bytes
>>> long)
>>> described in the CRB spec:
>>>
>>> https://trustedcomputinggroup.org/resource/tpm-2-0-mobile-command-response-buffer-interface-specification/

IMHO I would not use the mobile CRB, which was designed as a doorbell 
solution for ARM where trapping a page was not possible. Since it is 
possible to trap on page access, this makes it possible to implement the 
PC Client MMIO interface and enables implementations to provide the 
complete set of TPM capabilities, e.g. localities.

>>> In theory we could use a page that keeps trapping to the SVSM for
>>> this,
>>> but the problem is that the CRB driver polls a register in the MMIO
>>> region to check command completion, so even a single TPM command is
>>> going to generate a huge number of such traps.  So while it's
>>> theoretically possible to generate a SVSM emulation of the CRB
>>> device,
>>> it would likely be too expensive in terms of traps, particularly if
>>> we're using the SVSM vTPM for runtime measurements like IMA.
>>>
>>> If we're going to do a new driver, I think basing it off the CRB
>>> spec
>>> would be fine (the spec envisages command request/response being
>>> via
>>> areas outside the MMIO region) and we could simply do a new driver
>>> that
>>> plumbs directly into the nine operations in the tpm_class_ops
>>> structure
>>>
>>
>> This sounds good. I think we can model an API call to the SVSM vTPM
>> using
>> this. We can provide a struct that looks similar to the CRB Control
>> Area
>> and supply the GPA of this struct in RCX to the SVSM for the vTPM to
>> perform the operation:
>>
>>       - Command GPA
>>       - Command Size
>>       - Response GPA
>>       - Response Size
>>       - Status
> 
> Realistically, I think all TPM2 command/response actions can be packed
> into
> 
> u32 TPM2_action(u64 command_gpa, u32 command_len, u64 response_gpa, u32
> *response_len)
> 
> Where the u32 return would be the status (although if the SVSM has
> trouble with the return status, we could add it as an extra modified
> variable).
> 
> The way the current TPM driver interface works is shown in the
> tpm_class_ops structure:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/tpm.h
> 
> we can shim all the non-ignorable calls into the above.  The standard
> way of sending a command is tpm_try_transmit in
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm-interface.c
> 
> I think we can emulate an interrupt driven tpm (set TPM_CHIP_FLAG_IRQ
> in the driver) and it will simply do a ->send() ->receive() pair, which
> works for us since the thread of execution in ->send() will pass into
> the SVSM and return with the result which we can then copy over in
> ->recv
> 
> Also note that tpm_try_transmit() uses the same buffer for send and
> receive, so it is possible to reduce the number of parameters in
> TPM2_action() above if that's the route people want to go.
> 
>> Anything else that would go in the struct? Locality?
> 
> Well, this is a question.  CRB devices are actually allowed not to have
> a locality at all, so ignoring it is perfectly legal.  On the other
> hand, locality is used to allow or deny certain accesses.
> Traditionally you allow firmware access at locality 4 as the trusted
> hardware component.  However, the problem with implementing localities
> is how does the SVSM know where we're calling from?  If it's unable to
> bar access at certain localities, there's not much point implementing
> them.  For reference the TIS TPM implements separate memory maps of its
> registers, one for each locality and firmware bars access to the OS by
> unmapping a range and refusing to allow the OS to map it back.

If a guest were to attempt the SKINIT instruction, it should result in a 
NAE VMEXIT with reason being SKINIT. I haven't looked in-depth at VMPLs 
in detail yet but I would like to believe this would provide the 
necessary context of who made the call.

This is of particular interest to the TrenchBoot community as we have 
long had on our roadmap the desire to provide vDRTM for guests that is 
coupled with vTPM instances to provide for nested/deep attestation.

> I suspect we'd get on faster by being pejorative and saying we won't
> implement locality since we can't police it.
> 
> James

V/r,
Daniel

Re: SVSM vTPM specification

[James Bottomley]

On Thu, 2022-10-13 at 16:54 -0400, Daniel P. Smith wrote:
> Pardon the interjection.
> 
> On 10/13/22 15:20, James Bottomley wrote:
> > On Thu, 2022-10-13 at 13:54 -0500, Tom Lendacky wrote:
> > > On 10/12/22 14:05, James Bottomley wrote:
> > > > On Wed, 2022-10-12 at 18:33 +0100, Dr. David Alan Gilbert
> > > > wrote:
> > > > > * Tom Lendacky (thomas.lendacky@amd.com) wrote:
> > > ...
> > > > It is theoretically possible to emulate a CRB TPM with just a
> > > > single
> > > > communication page and an ACPI entry (the Linux CRB driver is
> > > > ACPI
> > > > only
> > > > at this time and responds to the "MSFT0101" ACPI entry).
> > > > 
> > > > The CRB device responds to a very compact MMIO region (0x30
> > > > bytes
> > > > long)
> > > > described in the CRB spec:
> > > > 
> > > > https://trustedcomputinggroup.org/resource/tpm-2-0-mobile-command-response-buffer-interface-specification/
> 
> IMHO I would not use the mobile CRB, which was designed as a
> doorbell solution for ARM where trapping a page was not possible.
> Since it is possible to trap on page access, this makes it possible
> to implement the PC Client MMIO interface and enables implementations
> to provide the complete set of TPM capabilities, e.g. localities.

You mean the TIS interface:

https://trustedcomputinggroup.org/resource/pc-client-work-group-pc-client-specific-tpm-interface-specification-tis/

We discussed this at length with AMD ... which I think isn't captured
in the email archives, unfortunately.  However, the bottom line is that
TIS uses a FIFO approach to sending data through the MMIO page.  That's
simply unscalable for pure emulation because it will result in 10-100x
the number of write traps in the MMIO page as the CRB driver which uses
a MMIO mailbox to trigger actions but passes the data via physical page
addresses not FIFOs.

So I think we could implement a reasonably performant CRB driver using
page trapping emulation, but not a TIS one.  For an enlightened driver,
a simple call interface seems to suffice.

James

Re: SVSM vTPM specification

[Daniel P. Smith]

On 10/13/22 17:06, James Bottomley wrote:
> On Thu, 2022-10-13 at 16:54 -0400, Daniel P. Smith wrote:
>> Pardon the interjection.
>>
>> On 10/13/22 15:20, James Bottomley wrote:
>>> On Thu, 2022-10-13 at 13:54 -0500, Tom Lendacky wrote:
>>>> On 10/12/22 14:05, James Bottomley wrote:
>>>>> On Wed, 2022-10-12 at 18:33 +0100, Dr. David Alan Gilbert
>>>>> wrote:
>>>>>> * Tom Lendacky (thomas.lendacky@amd.com) wrote:
>>>> ...
>>>>> It is theoretically possible to emulate a CRB TPM with just a
>>>>> single
>>>>> communication page and an ACPI entry (the Linux CRB driver is
>>>>> ACPI
>>>>> only
>>>>> at this time and responds to the "MSFT0101" ACPI entry).
>>>>>
>>>>> The CRB device responds to a very compact MMIO region (0x30
>>>>> bytes
>>>>> long)
>>>>> described in the CRB spec:
>>>>>
>>>>> https://trustedcomputinggroup.org/resource/tpm-2-0-mobile-command-response-buffer-interface-specification/
>>
>> IMHO I would not use the mobile CRB, which was designed as a
>> doorbell solution for ARM where trapping a page was not possible.
>> Since it is possible to trap on page access, this makes it possible
>> to implement the PC Client MMIO interface and enables implementations
>> to provide the complete set of TPM capabilities, e.g. localities.
> 
> You mean the TIS interface:
> 
> https://trustedcomputinggroup.org/resource/pc-client-work-group-pc-client-specific-tpm-interface-specification-tis/
> 
> We discussed this at length with AMD ... which I think isn't captured
> in the email archives, unfortunately.  However, the bottom line is that
> TIS uses a FIFO approach to sending data through the MMIO page.  That's
> simply unscalable for pure emulation because it will result in 10-100x
> the number of write traps in the MMIO page as the CRB driver which uses
> a MMIO mailbox to trigger actions but passes the data via physical page
> addresses not FIFOs.

Yes I am referring to the TIS interface but FIFO is only one of the 
software interface defined in the spec. There is also the TIS CRB 
interface which I should enable a similar experience as the mobile CRB.

> So I think we could implement a reasonably performant CRB driver using
> page trapping emulation, but not a TIS one.  For an enlightened driver,
> a simple call interface seems to suffice.
> 
> James
> 
> 

Re: SVSM vTPM specification

[James Bottomley]

On Thu, 2022-10-13 at 17:14 -0400, Daniel P. Smith wrote:
> On 10/13/22 17:06, James Bottomley wrote:
> > On Thu, 2022-10-13 at 16:54 -0400, Daniel P. Smith wrote:
> > > Pardon the interjection.
> > > 
> > > On 10/13/22 15:20, James Bottomley wrote:
> > > > On Thu, 2022-10-13 at 13:54 -0500, Tom Lendacky wrote:
> > > > > On 10/12/22 14:05, James Bottomley wrote:
> > > > > > On Wed, 2022-10-12 at 18:33 +0100, Dr. David Alan Gilbert
> > > > > > wrote:
> > > > > > > * Tom Lendacky (thomas.lendacky@amd.com) wrote:
> > > > > ...
> > > > > > It is theoretically possible to emulate a CRB TPM with just
> > > > > > a
> > > > > > single
> > > > > > communication page and an ACPI entry (the Linux CRB driver
> > > > > > is
> > > > > > ACPI
> > > > > > only
> > > > > > at this time and responds to the "MSFT0101" ACPI entry).
> > > > > > 
> > > > > > The CRB device responds to a very compact MMIO region (0x30
> > > > > > bytes
> > > > > > long)
> > > > > > described in the CRB spec:
> > > > > > 
> > > > > > https://trustedcomputinggroup.org/resource/tpm-2-0-mobile-command-response-buffer-interface-specification/
> > > 
> > > IMHO I would not use the mobile CRB, which was designed as a
> > > doorbell solution for ARM where trapping a page was not possible.
> > > Since it is possible to trap on page access, this makes it
> > > possible
> > > to implement the PC Client MMIO interface and enables
> > > implementations
> > > to provide the complete set of TPM capabilities, e.g. localities.
> > 
> > You mean the TIS interface:
> > 
> > https://trustedcomputinggroup.org/resource/pc-client-work-group-pc-client-specific-tpm-interface-specification-tis/
> > 
> > We discussed this at length with AMD ... which I think isn't
> > captured in the email archives, unfortunately.  However, the bottom
> > line is that TIS uses a FIFO approach to sending data through the
> > MMIO page.  That's simply unscalable for pure emulation because it
> > will result in 10-100x the number of write traps in the MMIO page
> > as the CRB driver which uses a MMIO mailbox to trigger actions but
> > passes the data via physical page addresses not FIFOs.
> 
> Yes I am referring to the TIS interface but FIFO is only one of the 
> software interface defined in the spec. There is also the TIS CRB 
> interface which I should enable a similar experience as the mobile
> CRB.

Well, not in the above spec there isn't, it's a pure FIFO.  I think you
might be thinking of the PTP spec:

https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/

which defined locality mapping for the CRB interface (among other
things).  But regardless of the TCG maze of slightly overlapping specs,
I think you now agree we can't use the FIFO interface because of the
high access trap overhead.  The outstanding question is over
localities, but simply implementing the PTP multiple pages won't give
us that.  It works for physical hardware because there's an motherboard
implementation specific way of shutting off access to MMIO registers at
a given locality.  We'd have to define such a thing for the SVSM ...
but, as of today, it's not really properly defined for OVMF, indicating
no-one's really using it as a security property for virtual
environments.

James

Re: SVSM vTPM specification

[Stuart Yoder]

On 10/13/22 4:41 PM, James Bottomley wrote:
> On Thu, 2022-10-13 at 17:14 -0400, Daniel P. Smith wrote:
>> On 10/13/22 17:06, James Bottomley wrote:
>>> On Thu, 2022-10-13 at 16:54 -0400, Daniel P. Smith wrote:
>>>> Pardon the interjection.
>>>>
>>>> On 10/13/22 15:20, James Bottomley wrote:
>>>>> On Thu, 2022-10-13 at 13:54 -0500, Tom Lendacky wrote:
>>>>>> On 10/12/22 14:05, James Bottomley wrote:
>>>>>>> On Wed, 2022-10-12 at 18:33 +0100, Dr. David Alan Gilbert
>>>>>>> wrote:
>>>>>>>> * Tom Lendacky (thomas.lendacky@amd.com) wrote:
>>>>>> ...
>>>>>>> It is theoretically possible to emulate a CRB TPM with just
>>>>>>> a
>>>>>>> single
>>>>>>> communication page and an ACPI entry (the Linux CRB driver
>>>>>>> is
>>>>>>> ACPI
>>>>>>> only
>>>>>>> at this time and responds to the "MSFT0101" ACPI entry).
>>>>>>>
>>>>>>> The CRB device responds to a very compact MMIO region (0x30
>>>>>>> bytes
>>>>>>> long)
>>>>>>> described in the CRB spec:
>>>>>>>
>>>>>>> https://trustedcomputinggroup.org/resource/tpm-2-0-mobile-command-response-buffer-interface-specification/
>>>>
>>>> IMHO I would not use the mobile CRB, which was designed as a
>>>> doorbell solution for ARM where trapping a page was not possible.
>>>> Since it is possible to trap on page access, this makes it
>>>> possible
>>>> to implement the PC Client MMIO interface and enables
>>>> implementations
>>>> to provide the complete set of TPM capabilities, e.g. localities.
>>>
>>> You mean the TIS interface:
>>>
>>> https://trustedcomputinggroup.org/resource/pc-client-work-group-pc-client-specific-tpm-interface-specification-tis/
>>>
>>> We discussed this at length with AMD ... which I think isn't
>>> captured in the email archives, unfortunately.  However, the bottom
>>> line is that TIS uses a FIFO approach to sending data through the
>>> MMIO page.  That's simply unscalable for pure emulation because it
>>> will result in 10-100x the number of write traps in the MMIO page
>>> as the CRB driver which uses a MMIO mailbox to trigger actions but
>>> passes the data via physical page addresses not FIFOs.
>>
>> Yes I am referring to the TIS interface but FIFO is only one of the
>> software interface defined in the spec. There is also the TIS CRB
>> interface which I should enable a similar experience as the mobile
>> CRB.
> 
> Well, not in the above spec there isn't, it's a pure FIFO.  I think you
> might be thinking of the PTP spec:
> 
> https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/
> 
> which defined locality mapping for the CRB interface (among other
> things).  But regardless of the TCG maze of slightly overlapping specs,
> I think you now agree we can't use the FIFO interface because of the
> high access trap overhead.  The outstanding question is over
> localities, but simply implementing the PTP multiple pages won't give
> us that.  It works for physical hardware because there's an motherboard
> implementation specific way of shutting off access to MMIO registers at
> a given locality.  We'd have to define such a thing for the SVSM ...
> but, as of today, it's not really properly defined for OVMF, indicating
> no-one's really using it as a security property for virtual
> environments.

Unless you expect to have some kind of virtual DRTM, all you need is
locality 0 in a virtual environment.

You could invent a new CRB-like interface, but how will it be 
advertised?  Through a new ACPI table definition that has to
get accepted by the UEFI Forum?  Updating the TCG ACPI spec?
And you will obviously need new drivers for each OS to be supported.

If you want to use a standard CRB and avoid overhead due to polling
in an MMIO interface you can implement the CRB interface completely in
normal DRAM, which is what is done for Trustzone-based firmware TPMs
on Arm.  The Mobile CRB spec specifically allows this. But, you will 
need a doorbell mechanism to signal the TPM to "start" operating on
a command that has been put in the CRB in DRAM.  The Linux CRB driver
works out of the box with this approach.

The standard TPM2 ACPI table could be used and all you need to define
is a new start method.

There are tradeoffs for both approaches.

Thanks,
Stuart

Re: SVSM vTPM specification

[Tom Lendacky]

On 10/14/22 12:16, Stuart Yoder wrote:
> On 10/13/22 4:41 PM, James Bottomley wrote:
>> On Thu, 2022-10-13 at 17:14 -0400, Daniel P. Smith wrote:
>>> On 10/13/22 17:06, James Bottomley wrote:
>>>> On Thu, 2022-10-13 at 16:54 -0400, Daniel P. Smith wrote:
>>>>> Pardon the interjection.
>>>>>
>>>>> On 10/13/22 15:20, James Bottomley wrote:
>>>>>> On Thu, 2022-10-13 at 13:54 -0500, Tom Lendacky wrote:
>>>>>>> On 10/12/22 14:05, James Bottomley wrote:
>>>>>>>> On Wed, 2022-10-12 at 18:33 +0100, Dr. David Alan Gilbert
>>>>>>>> wrote:
>>>>>>>>> * Tom Lendacky (thomas.lendacky@amd.com) wrote:
>>>>>>> ...
>>>>>>>> It is theoretically possible to emulate a CRB TPM with just
>>>>>>>> a
>>>>>>>> single
>>>>>>>> communication page and an ACPI entry (the Linux CRB driver
>>>>>>>> is
>>>>>>>> ACPI
>>>>>>>> only
>>>>>>>> at this time and responds to the "MSFT0101" ACPI entry).
>>>>>>>>
>>>>>>>> The CRB device responds to a very compact MMIO region (0x30
>>>>>>>> bytes
>>>>>>>> long)
>>>>>>>> described in the CRB spec:
>>>>>>>>
>>>>>>>> https://trustedcomputinggroup.org/resource/tpm-2-0-mobile-command-response-buffer-interface-specification/
>>>>>>>>
>>>>>
>>>>> IMHO I would not use the mobile CRB, which was designed as a
>>>>> doorbell solution for ARM where trapping a page was not possible.
>>>>> Since it is possible to trap on page access, this makes it
>>>>> possible
>>>>> to implement the PC Client MMIO interface and enables
>>>>> implementations
>>>>> to provide the complete set of TPM capabilities, e.g. localities.
>>>>
>>>> You mean the TIS interface:
>>>>
>>>> https://trustedcomputinggroup.org/resource/pc-client-work-group-pc-client-specific-tpm-interface-specification-tis/
>>>>
>>>>
>>>> We discussed this at length with AMD ... which I think isn't
>>>> captured in the email archives, unfortunately.  However, the bottom
>>>> line is that TIS uses a FIFO approach to sending data through the
>>>> MMIO page.  That's simply unscalable for pure emulation because it
>>>> will result in 10-100x the number of write traps in the MMIO page
>>>> as the CRB driver which uses a MMIO mailbox to trigger actions but
>>>> passes the data via physical page addresses not FIFOs.
>>>
>>> Yes I am referring to the TIS interface but FIFO is only one of the
>>> software interface defined in the spec. There is also the TIS CRB
>>> interface which I should enable a similar experience as the mobile
>>> CRB.
>>
>> Well, not in the above spec there isn't, it's a pure FIFO.  I think you
>> might be thinking of the PTP spec:
>>
>> https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/
>>
>>
>> which defined locality mapping for the CRB interface (among other
>> things).  But regardless of the TCG maze of slightly overlapping specs,
>> I think you now agree we can't use the FIFO interface because of the
>> high access trap overhead.  The outstanding question is over
>> localities, but simply implementing the PTP multiple pages won't give
>> us that.  It works for physical hardware because there's an motherboard
>> implementation specific way of shutting off access to MMIO registers at
>> a given locality.  We'd have to define such a thing for the SVSM ...
>> but, as of today, it's not really properly defined for OVMF, indicating
>> no-one's really using it as a security property for virtual
>> environments.
> 
> Unless you expect to have some kind of virtual DRTM, all you need is
> locality 0 in a virtual environment.
> 
> You could invent a new CRB-like interface, but how will it be advertised?  
> Through a new ACPI table definition that has to
> get accepted by the UEFI Forum?  Updating the TCG ACPI spec?
> And you will obviously need new drivers for each OS to be supported.

Since we're talking about enlightened guests, we can query the SVSM 
(through the SVSM_CORE_QUERY_PROTOCOL API) to check for the availability 
of the vTPM protocol. If present, then the OS will know to load an SVSM 
vTPM driver. This could be done, for example, on Linux, by registering a 
platform device.

Thanks,
Tom

> 
> If you want to use a standard CRB and avoid overhead due to polling
> in an MMIO interface you can implement the CRB interface completely in
> normal DRAM, which is what is done for Trustzone-based firmware TPMs
> on Arm.  The Mobile CRB spec specifically allows this. But, you will need 
> a doorbell mechanism to signal the TPM to "start" operating on
> a command that has been put in the CRB in DRAM.  The Linux CRB driver
> works out of the box with this approach.
> 
> The standard TPM2 ACPI table could be used and all you need to define
> is a new start method.
> 
> There are tradeoffs for both approaches.
> 
> Thanks,
> Stuart
> 

Re: SVSM vTPM specification

[Daniel P. Smith]

On 10/14/22 17:46, Tom Lendacky wrote:
> On 10/14/22 12:16, Stuart Yoder wrote:
>> On 10/13/22 4:41 PM, James Bottomley wrote:
>>> On Thu, 2022-10-13 at 17:14 -0400, Daniel P. Smith wrote:
>>>> On 10/13/22 17:06, James Bottomley wrote:
>>>>> On Thu, 2022-10-13 at 16:54 -0400, Daniel P. Smith wrote:
>>>>>> Pardon the interjection.
>>>>>>
>>>>>> On 10/13/22 15:20, James Bottomley wrote:
>>>>>>> On Thu, 2022-10-13 at 13:54 -0500, Tom Lendacky wrote:
>>>>>>>> On 10/12/22 14:05, James Bottomley wrote:
>>>>>>>>> On Wed, 2022-10-12 at 18:33 +0100, Dr. David Alan Gilbert
>>>>>>>>> wrote:
>>>>>>>>>> * Tom Lendacky (thomas.lendacky@amd.com) wrote:
>>>>>>>> ...
>>>>>>>>> It is theoretically possible to emulate a CRB TPM with just
>>>>>>>>> a
>>>>>>>>> single
>>>>>>>>> communication page and an ACPI entry (the Linux CRB driver
>>>>>>>>> is
>>>>>>>>> ACPI
>>>>>>>>> only
>>>>>>>>> at this time and responds to the "MSFT0101" ACPI entry).
>>>>>>>>>
>>>>>>>>> The CRB device responds to a very compact MMIO region (0x30
>>>>>>>>> bytes
>>>>>>>>> long)
>>>>>>>>> described in the CRB spec:
>>>>>>>>>
>>>>>>>>> https://trustedcomputinggroup.org/resource/tpm-2-0-mobile-command-response-buffer-interface-specification/
>>>>>>>>>
>>>>>>
>>>>>> IMHO I would not use the mobile CRB, which was designed as a
>>>>>> doorbell solution for ARM where trapping a page was not possible.
>>>>>> Since it is possible to trap on page access, this makes it
>>>>>> possible
>>>>>> to implement the PC Client MMIO interface and enables
>>>>>> implementations
>>>>>> to provide the complete set of TPM capabilities, e.g. localities.
>>>>>
>>>>> You mean the TIS interface:
>>>>>
>>>>> https://trustedcomputinggroup.org/resource/pc-client-work-group-pc-client-specific-tpm-interface-specification-tis/
>>>>>
>>>>>
>>>>> We discussed this at length with AMD ... which I think isn't
>>>>> captured in the email archives, unfortunately.  However, the bottom
>>>>> line is that TIS uses a FIFO approach to sending data through the
>>>>> MMIO page.  That's simply unscalable for pure emulation because it
>>>>> will result in 10-100x the number of write traps in the MMIO page
>>>>> as the CRB driver which uses a MMIO mailbox to trigger actions but
>>>>> passes the data via physical page addresses not FIFOs.
>>>>
>>>> Yes I am referring to the TIS interface but FIFO is only one of the
>>>> software interface defined in the spec. There is also the TIS CRB
>>>> interface which I should enable a similar experience as the mobile
>>>> CRB.
>>>
>>> Well, not in the above spec there isn't, it's a pure FIFO.  I think you
>>> might be thinking of the PTP spec:
>>>
>>> https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/
>>>
>>>
>>> which defined locality mapping for the CRB interface (among other
>>> things).  But regardless of the TCG maze of slightly overlapping specs,
>>> I think you now agree we can't use the FIFO interface because of the
>>> high access trap overhead.  The outstanding question is over
>>> localities, but simply implementing the PTP multiple pages won't give
>>> us that.  It works for physical hardware because there's an motherboard
>>> implementation specific way of shutting off access to MMIO registers at
>>> a given locality.  We'd have to define such a thing for the SVSM ...
>>> but, as of today, it's not really properly defined for OVMF, indicating
>>> no-one's really using it as a security property for virtual
>>> environments.
>>
>> Unless you expect to have some kind of virtual DRTM, all you need is
>> locality 0 in a virtual environment.
>>
>> You could invent a new CRB-like interface, but how will it be 
>> advertised? Through a new ACPI table definition that has to
>> get accepted by the UEFI Forum?  Updating the TCG ACPI spec?
>> And you will obviously need new drivers for each OS to be supported.
> 
> Since we're talking about enlightened guests, we can query the SVSM 
> (through the SVSM_CORE_QUERY_PROTOCOL API) to check for the availability 
> of the vTPM protocol. If present, then the OS will know to load an SVSM 
> vTPM driver. This could be done, for example, on Linux, by registering a 
> platform device.
> 
> Thanks,
> Tom

If enlightened guest/driver is acceptable, then why not adopt the 
pv-vTPM protocol, Xen's vTPM driver, for which there is already a driver 
present in the kernel, was designed for deep attestation, and does not 
inhibit/block features such as locality?

v/r,
dps

>>
>> If you want to use a standard CRB and avoid overhead due to polling
>> in an MMIO interface you can implement the CRB interface completely in
>> normal DRAM, which is what is done for Trustzone-based firmware TPMs
>> on Arm.  The Mobile CRB spec specifically allows this. But, you will 
>> need a doorbell mechanism to signal the TPM to "start" operating on
>> a command that has been put in the CRB in DRAM.  The Linux CRB driver
>> works out of the box with this approach.
>>
>> The standard TPM2 ACPI table could be used and all you need to define
>> is a new start method.
>>
>> There are tradeoffs for both approaches.
>>
>> Thanks,
>> Stuart
>>

Re: SVSM vTPM specification

[James Bottomley]

On Sun, 2022-10-16 at 12:29 -0400, Daniel P. Smith wrote:
> If enlightened guest/driver is acceptable, then why not adopt the 
> pv-vTPM protocol, Xen's vTPM driver, for which there is already a
> driver present in the kernel, was designed for deep attestation, and
> does not inhibit/block features such as locality?

Erm, because it requires the Xen bus for discovery and communication
... the KVM people might not be so keen on adding that.  The other
problem, even if we were to write a virtio equivalent (which KVM
doesn't have today because it relies on TIS or CRB emulations), is that
for all these virtual drivers, the back endpoint is in the host and we
want to terminate it in the SVSM, which is the guest.

To be clear, the current KVM drivers do emulate localites, it's just
that they're unused by the OS and Firmware.  If you look at the TPM
emulators themselves, they have the concept of locality, but when they
need it, they indirect via an additional platform call (in the ms-tpm,
which the current IBM prototype uses, it's a stubbed call to
__plat__LocalityGet/Set) ... the locality isn't provided as part of the
main TPM command processor, which is why we don't need to worry about
it in the initial prototype.  That means if anyone ever does figure out
how to do dynamic launch for virtual machines, and requires localities,
we can simply add handlers for the stub routines.

James

Re: SVSM vTPM specification

[Dov Murik]

On 13/10/2022 18:30, James Bottomley wrote:
> On Thu, 2022-10-13 at 10:14 -0500, Tom Lendacky wrote:
>> On 10/12/22 13:44, James Bottomley wrote:
>>> On Wed, 2022-10-12 at 18:33 +0100, Dr. David Alan Gilbert wrote:
>>>> * Tom Lendacky (thomas.lendacky@amd.com) wrote:
>>> [...]
>>>> It's important that the VMPL level in the attestation report
>>>> reflects the side asking for the attestation; in particular one
>>>> TPM story goes that the firmware (in VMPL0) would ask for an
>>>> attestation and the attestor would return the vTPM stored
>>>> state.  It's important that the state could only be returned to
>>>> the vTPM not the guest, so the attestor would check that the VMPL
>>>> level in the attestation was 0; any guest attestation would have
>>>> a VMPL>0 and so the attestor wouldn't hand it the vTPM state.
>>>> Hmm or are you saying such a report would be triggered by the
>>>> guest rather than the firmware, but it would be protected by
>>>> VMPCK0 so the guest wouldn't be able to read it?
>>
>> No, the VMPCK0 key is just used for communication with the PSP.
>>
>> While the SVSM would request the attestation report from the PSP,
>> the guest would need to request it from the SVSM.
> 
> I think this is fine.  The SVSM would do the attestation as it starts
> the TPM but the guest would be able to retrieve it at any time. 
> Essentially, if you use something like keylime, the agent would request
> it on start up to prove it should trust the vTPM, but that could occur
> way after VM boot.
> 
>>
>>>> I think one of the vTPMs keys should be in the SNP attestation
>>>> report (the EK???) - I think that would allow you to attest that
>>>> the vTPM you're talking to is a vTPM running in an SNP protected
>>>> firmware.
>>>
>>> Traditionally the TPM identity is the public EK, so that should
>>> definitely be in the report.  Ideally, I think the public storage
>>> root key (key derived from the owner seed) should be in there two
>>> because it makes it easy to create keys that can only be read by
>>> the TPM (keys should be in the owner hierarchy which means they
>>> have to be encrypted to the storage seed, so we need to know what a
>>> public key corresponding to it is).
>>>
>>> One wrinkle of the above is that, when provisioned, the TPM will
>>> only have the seeds, not the keys (the keys are derived from the
>>> seeds via a TPM2_CreatePrimary command).  The current TPM
>>> provisioning guidance:
>>>
>>> https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/
>>>
>>> Says that the EK should be at permanent handle
>>>
>>> 81010001
>>>
>>> And there's an update saying that should be the RSA-2048 key and
>>> there should be an EC (NIST-P256) one at 81010002.  The
>>> corresponding storage keys should be at 81000001 and 81000002
>>> respectively.  I think when the SVSM provisions the TPM, it should
>>> run TPM2_CreatePrimary for those four keys and put them into the
>>> persistent indexes, then insert the EC keys only for EK and SRK
>>> into the attestation report.
>>
>> We only have 512 bits to work with for the SVSM-provided data, so
>> would hashes of the keys be ok?
> 
> Well, if you put the hashes in, the consuming entity would then have to
> find out via an additional channel what the actual keys were because
> you can't reverse the hash (it's possible, just more effort).  If you
> use point compression, an EC key (for the NIST p-256 curve) is only 32
> bytes anyway, so it's the same size as a sha256 hash, so I'd say place
> the actual public keys into the report to give complete and usable
> information
> 

Do we need to leave room for a Guest-Owner-provided nonce?  Guest owner
will provide it to the guest OS which will provide it to the SVSM to be
included in REPORT_DATA of the VMPL0 attestation report.

If we don't add a nonce not, how can the guest owner verify the
freshness of the report?  Maybe the pub-EK is enough because it signs
the rest of the TPM-report and the guest-owner can somehow verify its
freshness?


It looks like REPORT_DATA needs to be

SHA512(guest_owner_nonce || pub_EK || pub_SRK)

And the guest does this:

1. Receive nonce from guest owner
2. Calls SVSM_GET_TPM_PUB_KEYS
3. Constructs report_data=sha512(guest_owner_nonce || pub_EK || pub_SRK)
4. Calls SVSM_GET_SNP_ATTESTATION_REPORT(report_data)
5. Send back both the report and pub_* to guest owner


-Dov

Re: SVSM vTPM specification

[Dov Murik]

On 13/10/2022 22:20, James Bottomley wrote:
> On Thu, 2022-10-13 at 13:54 -0500, Tom Lendacky wrote:
>> On 10/12/22 14:05, James Bottomley wrote:
>>> On Wed, 2022-10-12 at 18:33 +0100, Dr. David Alan Gilbert wrote:
>>>> * Tom Lendacky (thomas.lendacky@amd.com) wrote:
>> ...
>>> It is theoretically possible to emulate a CRB TPM with just a
>>> single
>>> communication page and an ACPI entry (the Linux CRB driver is ACPI
>>> only
>>> at this time and responds to the "MSFT0101" ACPI entry).
>>>
>>> The CRB device responds to a very compact MMIO region (0x30 bytes
>>> long)
>>> described in the CRB spec:
>>>
>>> https://trustedcomputinggroup.org/resource/tpm-2-0-mobile-command-response-buffer-interface-specification/
>>>
>>> In theory we could use a page that keeps trapping to the SVSM for
>>> this,
>>> but the problem is that the CRB driver polls a register in the MMIO
>>> region to check command completion, so even a single TPM command is
>>> going to generate a huge number of such traps.  So while it's
>>> theoretically possible to generate a SVSM emulation of the CRB
>>> device,
>>> it would likely be too expensive in terms of traps, particularly if
>>> we're using the SVSM vTPM for runtime measurements like IMA.
>>>
>>> If we're going to do a new driver, I think basing it off the CRB
>>> spec
>>> would be fine (the spec envisages command request/response being
>>> via
>>> areas outside the MMIO region) and we could simply do a new driver
>>> that
>>> plumbs directly into the nine operations in the tpm_class_ops
>>> structure
>>>
>>
>> This sounds good. I think we can model an API call to the SVSM vTPM
>> using 
>> this. We can provide a struct that looks similar to the CRB Control
>> Area 
>> and supply the GPA of this struct in RCX to the SVSM for the vTPM to 
>> perform the operation:
>>
>>      - Command GPA
>>      - Command Size
>>      - Response GPA
>>      - Response Size
>>      - Status
> 
> Realistically, I think all TPM2 command/response actions can be packed
> into
> 
> u32 TPM2_action(u64 command_gpa, u32 command_len, u64 response_gpa, u32
> *response_len)
> 
> Where the u32 return would be the status (although if the SVSM has
> trouble with the return status, we could add it as an extra modified
> variable).
> 
> The way the current TPM driver interface works is shown in the
> tpm_class_ops structure:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/tpm.h
> 
> we can shim all the non-ignorable calls into the above.  The standard
> way of sending a command is tpm_try_transmit in
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm-interface.c
> 
> I think we can emulate an interrupt driven tpm (set TPM_CHIP_FLAG_IRQ
> in the driver) and it will simply do a ->send() ->receive() pair, which
> works for us since the thread of execution in ->send() will pass into
> the SVSM and return with the result which we can then copy over in
> ->recv

Yep, the ftpm driver [1] stores the TPM response at the end of ->send()
and then just copies it over in ->recv(), like you said.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/tpm/tpm_ftpm_tee.c

> 
> Also note that tpm_try_transmit() uses the same buffer for send and
> receive, so it is possible to reduce the number of parameters in
> TPM2_action() above if that's the route people want to go.

I think that the leftover space in the SVSM's Calling Area (svsm_caa.svsm_buf:
4088 bytes) should be enough for the CRB struct and the command+response data buffer.
Using it might simplify the kernel driver a bit (reduce alloc/free calls).

-Dov


> 
>> Anything else that would go in the struct? Locality?
> 
> Well, this is a question.  CRB devices are actually allowed not to have
> a locality at all, so ignoring it is perfectly legal.  On the other
> hand, locality is used to allow or deny certain accesses. 
> Traditionally you allow firmware access at locality 4 as the trusted
> hardware component.  However, the problem with implementing localities
> is how does the SVSM know where we're calling from?  If it's unable to
> bar access at certain localities, there's not much point implementing
> them.  For reference the TIS TPM implements separate memory maps of its
> registers, one for each locality and firmware bars access to the OS by
> unmapping a range and refusing to allow the OS to map it back.
> 
> I suspect we'd get on faster by being pejorative and saying we won't
> implement locality since we can't police it.
> 
> James
>  
> 

Re: SVSM vTPM specification

[Christophe de Dinechin]

> On 18 Oct 2022, at 22:22, Dov Murik <dovmurik@linux.ibm.com> wrote:
> 
> 
> 
> On 13/10/2022 18:30, James Bottomley wrote:
>> On Thu, 2022-10-13 at 10:14 -0500, Tom Lendacky wrote:
>>> On 10/12/22 13:44, James Bottomley wrote:
>>>> On Wed, 2022-10-12 at 18:33 +0100, Dr. David Alan Gilbert wrote:
>>>>> * Tom Lendacky (thomas.lendacky@amd.com) wrote:
>>>> [...]
>>>>> It's important that the VMPL level in the attestation report
>>>>> reflects the side asking for the attestation; in particular one
>>>>> TPM story goes that the firmware (in VMPL0) would ask for an
>>>>> attestation and the attestor would return the vTPM stored
>>>>> state.  It's important that the state could only be returned to
>>>>> the vTPM not the guest, so the attestor would check that the VMPL
>>>>> level in the attestation was 0; any guest attestation would have
>>>>> a VMPL>0 and so the attestor wouldn't hand it the vTPM state.
>>>>> Hmm or are you saying such a report would be triggered by the
>>>>> guest rather than the firmware, but it would be protected by
>>>>> VMPCK0 so the guest wouldn't be able to read it?
>>> 
>>> No, the VMPCK0 key is just used for communication with the PSP.
>>> 
>>> While the SVSM would request the attestation report from the PSP,
>>> the guest would need to request it from the SVSM.
>> 
>> I think this is fine.  The SVSM would do the attestation as it starts
>> the TPM but the guest would be able to retrieve it at any time. 
>> Essentially, if you use something like keylime, the agent would request
>> it on start up to prove it should trust the vTPM, but that could occur
>> way after VM boot.
>> 
>>> 
>>>>> I think one of the vTPMs keys should be in the SNP attestation
>>>>> report (the EK???) - I think that would allow you to attest that
>>>>> the vTPM you're talking to is a vTPM running in an SNP protected
>>>>> firmware.
>>>> 
>>>> Traditionally the TPM identity is the public EK, so that should
>>>> definitely be in the report.  Ideally, I think the public storage
>>>> root key (key derived from the owner seed) should be in there two
>>>> because it makes it easy to create keys that can only be read by
>>>> the TPM (keys should be in the owner hierarchy which means they
>>>> have to be encrypted to the storage seed, so we need to know what a
>>>> public key corresponding to it is).
>>>> 
>>>> One wrinkle of the above is that, when provisioned, the TPM will
>>>> only have the seeds, not the keys (the keys are derived from the
>>>> seeds via a TPM2_CreatePrimary command).  The current TPM
>>>> provisioning guidance:
>>>> 
>>>> https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/
>>>> 
>>>> Says that the EK should be at permanent handle
>>>> 
>>>> 81010001
>>>> 
>>>> And there's an update saying that should be the RSA-2048 key and
>>>> there should be an EC (NIST-P256) one at 81010002.  The
>>>> corresponding storage keys should be at 81000001 and 81000002
>>>> respectively.  I think when the SVSM provisions the TPM, it should
>>>> run TPM2_CreatePrimary for those four keys and put them into the
>>>> persistent indexes, then insert the EC keys only for EK and SRK
>>>> into the attestation report.
>>> 
>>> We only have 512 bits to work with for the SVSM-provided data, so
>>> would hashes of the keys be ok?
>> 
>> Well, if you put the hashes in, the consuming entity would then have to
>> find out via an additional channel what the actual keys were because
>> you can't reverse the hash (it's possible, just more effort).  If you
>> use point compression, an EC key (for the NIST p-256 curve) is only 32
>> bytes anyway, so it's the same size as a sha256 hash, so I'd say place
>> the actual public keys into the report to give complete and usable
>> information
>> 
> 
> Do we need to leave room for a Guest-Owner-provided nonce?  Guest owner
> will provide it to the guest OS which will provide it to the SVSM to be
> included in REPORT_DATA of the VMPL0 attestation report.
> 
I think it’s a good idea, but I’m not clear on which component in the
guest would be responsible for that exchange.

You need a functioning networking stack, and you need a way to know what
attestation server to talk to.

IIUC, at this stage, we have no valid storage yet, since that would
require having received the response from the attestation server.
So the only storage we have is host storage managed by the hypervisor,
plus whatever fits in your SVSM-provided data.

Can we send this data without additional encryption since it’s already
cyphertext? Or do we want additional mechanisms, and if so, what root
certificates do we use? Where do we get them from without guest storage?

Do we rely on guest networking being up at that point? Or do we need
to provide additional mechanisms in the hypervisor to perform this
initial exchange on behalf of the guest?



> If we don't add a nonce not, how can the guest owner verify the
> freshness of the report?  Maybe the pub-EK is enough because it signs
> the rest of the TPM-report and the guest-owner can somehow verify its
> freshness?

I think that would work for transient vTPMs. If we want a long-lived
vTPM, then we’d need a mechanism for the guest owner to tell, ahead of
time, when to regenerate a new vTPM state, and to independently get
that state. In that case, the policy of when to update the vTPM state
would be deferred to some external server, and the process would be:

- Day 1: External server requests a new TPM state, stores state
- Day N: Guest boots, uses that TPM state, which is then verified
  by the external server
- Day M: External server decides to refresh the TPM state, will now
  only accept boots with fresher state


> 
> 
> It looks like REPORT_DATA needs to be
> 
> SHA512(guest_owner_nonce || pub_EK || pub_SRK)
> 
> And the guest does this:
> 
> 1. Receive nonce from guest owner
> 2. Calls SVSM_GET_TPM_PUB_KEYS
> 3. Constructs report_data=sha512(guest_owner_nonce || pub_EK || pub_SRK)
> 4. Calls SVSM_GET_SNP_ATTESTATION_REPORT(report_data)
> 5. Send back both the report and pub_* to guest owner
> 
> 
> -Dov

Re: SVSM vTPM specification

[Dov Murik]

On 19/10/2022 8:47, Christophe de Dinechin wrote:
> 
> 
>> On 18 Oct 2022, at 22:22, Dov Murik <dovmurik@linux.ibm.com> wrote:
>>
>>
>>
>> On 13/10/2022 18:30, James Bottomley wrote:
>>> On Thu, 2022-10-13 at 10:14 -0500, Tom Lendacky wrote:
>>>> On 10/12/22 13:44, James Bottomley wrote:
>>>>> On Wed, 2022-10-12 at 18:33 +0100, Dr. David Alan Gilbert wrote:
>>>>>> * Tom Lendacky (thomas.lendacky@amd.com) wrote:
>>>>> [...]
>>>>>> It's important that the VMPL level in the attestation report
>>>>>> reflects the side asking for the attestation; in particular one
>>>>>> TPM story goes that the firmware (in VMPL0) would ask for an
>>>>>> attestation and the attestor would return the vTPM stored
>>>>>> state.  It's important that the state could only be returned to
>>>>>> the vTPM not the guest, so the attestor would check that the VMPL
>>>>>> level in the attestation was 0; any guest attestation would have
>>>>>> a VMPL>0 and so the attestor wouldn't hand it the vTPM state.
>>>>>> Hmm or are you saying such a report would be triggered by the
>>>>>> guest rather than the firmware, but it would be protected by
>>>>>> VMPCK0 so the guest wouldn't be able to read it?
>>>>
>>>> No, the VMPCK0 key is just used for communication with the PSP.
>>>>
>>>> While the SVSM would request the attestation report from the PSP,
>>>> the guest would need to request it from the SVSM.
>>>
>>> I think this is fine.  The SVSM would do the attestation as it starts
>>> the TPM but the guest would be able to retrieve it at any time. 
>>> Essentially, if you use something like keylime, the agent would request
>>> it on start up to prove it should trust the vTPM, but that could occur
>>> way after VM boot.
>>>
>>>>
>>>>>> I think one of the vTPMs keys should be in the SNP attestation
>>>>>> report (the EK???) - I think that would allow you to attest that
>>>>>> the vTPM you're talking to is a vTPM running in an SNP protected
>>>>>> firmware.
>>>>>
>>>>> Traditionally the TPM identity is the public EK, so that should
>>>>> definitely be in the report.  Ideally, I think the public storage
>>>>> root key (key derived from the owner seed) should be in there two
>>>>> because it makes it easy to create keys that can only be read by
>>>>> the TPM (keys should be in the owner hierarchy which means they
>>>>> have to be encrypted to the storage seed, so we need to know what a
>>>>> public key corresponding to it is).
>>>>>
>>>>> One wrinkle of the above is that, when provisioned, the TPM will
>>>>> only have the seeds, not the keys (the keys are derived from the
>>>>> seeds via a TPM2_CreatePrimary command).  The current TPM
>>>>> provisioning guidance:
>>>>>
>>>>> https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/
>>>>>
>>>>> Says that the EK should be at permanent handle
>>>>>
>>>>> 81010001
>>>>>
>>>>> And there's an update saying that should be the RSA-2048 key and
>>>>> there should be an EC (NIST-P256) one at 81010002.  The
>>>>> corresponding storage keys should be at 81000001 and 81000002
>>>>> respectively.  I think when the SVSM provisions the TPM, it should
>>>>> run TPM2_CreatePrimary for those four keys and put them into the
>>>>> persistent indexes, then insert the EC keys only for EK and SRK
>>>>> into the attestation report.
>>>>
>>>> We only have 512 bits to work with for the SVSM-provided data, so
>>>> would hashes of the keys be ok?
>>>
>>> Well, if you put the hashes in, the consuming entity would then have to
>>> find out via an additional channel what the actual keys were because
>>> you can't reverse the hash (it's possible, just more effort).  If you
>>> use point compression, an EC key (for the NIST p-256 curve) is only 32
>>> bytes anyway, so it's the same size as a sha256 hash, so I'd say place
>>> the actual public keys into the report to give complete and usable
>>> information
>>>
>>
>> Do we need to leave room for a Guest-Owner-provided nonce?  Guest owner
>> will provide it to the guest OS which will provide it to the SVSM to be
>> included in REPORT_DATA of the VMPL0 attestation report.
>>
> I think it’s a good idea, but I’m not clear on which component in the
> guest would be responsible for that exchange.
> 
> You need a functioning networking stack, and you need a way to know what
> attestation server to talk to.
> 

You're right.  I was thinking about an attestation request coming later
during the guest OS boot (after bringing up networking).

> IIUC, at this stage, we have no valid storage yet, since that would
> require having received the response from the attestation server.
> So the only storage we have is host storage managed by the hypervisor,
> plus whatever fits in your SVSM-provided data.
> 
> Can we send this data without additional encryption since it’s already
> cyphertext? Or do we want additional mechanisms, and if so, what root
> certificates do we use? Where do we get them from without guest storage?
> 
> Do we rely on guest networking being up at that point? Or do we need
> to provide additional mechanisms in the hypervisor to perform this
> initial exchange on behalf of the guest?
> 

If we need early-launch attestation and secret injection (to get the
confidential TPM state very early, before firmware starts), then we'll
need an SEV-like flow: SVSM will stop the boot sequence, wait for a
nonce from host (which will proxy to guest owner), produce attestation
report, wait for secret injection, and then resume boot to firmware.

(And maybe the nonce can be generated by SVSM, like in SEV's
LAUNCH_MEASURE; this removes one network round-trip to guest owner.)

We can try to reuse the existing QEMU commands and secret-injection
structures (we'll need to define a small protocol between HV and SVSM to
pass these buffers); or invent something new (vsock support in SVSM?).

I wonder if all of this complication (early-launch secret injection for
SNP) can be decoupled from SVSM vTPM spec effort.  Other uses for these
early injected secrets?

-Dov

> 
> 
>> If we don't add a nonce not, how can the guest owner verify the
>> freshness of the report?  Maybe the pub-EK is enough because it signs
>> the rest of the TPM-report and the guest-owner can somehow verify its
>> freshness?
> 
> I think that would work for transient vTPMs. If we want a long-lived
> vTPM, then we’d need a mechanism for the guest owner to tell, ahead of
> time, when to regenerate a new vTPM state, and to independently get
> that state. In that case, the policy of when to update the vTPM state
> would be deferred to some external server, and the process would be:
> 
> - Day 1: External server requests a new TPM state, stores state
> - Day N: Guest boots, uses that TPM state, which is then verified
>   by the external server
> - Day M: External server decides to refresh the TPM state, will now
>   only accept boots with fresher state
> 
> 
>>
>>
>> It looks like REPORT_DATA needs to be
>>
>> SHA512(guest_owner_nonce || pub_EK || pub_SRK)
>>
>> And the guest does this:
>>
>> 1. Receive nonce from guest owner
>> 2. Calls SVSM_GET_TPM_PUB_KEYS
>> 3. Constructs report_data=sha512(guest_owner_nonce || pub_EK || pub_SRK)
>> 4. Calls SVSM_GET_SNP_ATTESTATION_REPORT(report_data)
>> 5. Send back both the report and pub_* to guest owner
>>
>>
>> -Dov
> 

Re: SVSM vTPM specification

[Daniel P. Berrangé]

On Wed, Oct 19, 2022 at 07:47:41AM +0200, Christophe de Dinechin wrote:
> 
> 
> > On 18 Oct 2022, at 22:22, Dov Murik <dovmurik@linux.ibm.com> wrote:
> > 
> > 
> > 
> > On 13/10/2022 18:30, James Bottomley wrote:
> >> On Thu, 2022-10-13 at 10:14 -0500, Tom Lendacky wrote:
> >>> On 10/12/22 13:44, James Bottomley wrote:
> >>>> On Wed, 2022-10-12 at 18:33 +0100, Dr. David Alan Gilbert wrote:
> >>>>> I think one of the vTPMs keys should be in the SNP attestation
> >>>>> report (the EK???) - I think that would allow you to attest that
> >>>>> the vTPM you're talking to is a vTPM running in an SNP protected
> >>>>> firmware.
> >>>> 
> >>>> Traditionally the TPM identity is the public EK, so that should
> >>>> definitely be in the report.  Ideally, I think the public storage
> >>>> root key (key derived from the owner seed) should be in there two
> >>>> because it makes it easy to create keys that can only be read by
> >>>> the TPM (keys should be in the owner hierarchy which means they
> >>>> have to be encrypted to the storage seed, so we need to know what a
> >>>> public key corresponding to it is).
> >>>> 
> >>>> One wrinkle of the above is that, when provisioned, the TPM will
> >>>> only have the seeds, not the keys (the keys are derived from the
> >>>> seeds via a TPM2_CreatePrimary command).  The current TPM
> >>>> provisioning guidance:
> >>>> 
> >>>> https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/
> >>>> 
> >>>> Says that the EK should be at permanent handle
> >>>> 
> >>>> 81010001
> >>>> 
> >>>> And there's an update saying that should be the RSA-2048 key and
> >>>> there should be an EC (NIST-P256) one at 81010002.  The
> >>>> corresponding storage keys should be at 81000001 and 81000002
> >>>> respectively.  I think when the SVSM provisions the TPM, it should
> >>>> run TPM2_CreatePrimary for those four keys and put them into the
> >>>> persistent indexes, then insert the EC keys only for EK and SRK
> >>>> into the attestation report.
> >>> 
> >>> We only have 512 bits to work with for the SVSM-provided data, so
> >>> would hashes of the keys be ok?
> >> 
> >> Well, if you put the hashes in, the consuming entity would then have to
> >> find out via an additional channel what the actual keys were because
> >> you can't reverse the hash (it's possible, just more effort).  If you
> >> use point compression, an EC key (for the NIST p-256 curve) is only 32
> >> bytes anyway, so it's the same size as a sha256 hash, so I'd say place
> >> the actual public keys into the report to give complete and usable
> >> information
> >> 
> > 
> > Do we need to leave room for a Guest-Owner-provided nonce?  Guest owner
> > will provide it to the guest OS which will provide it to the SVSM to be
> > included in REPORT_DATA of the VMPL0 attestation report.
> > 
> I think it’s a good idea, but I’m not clear on which component in the
> guest would be responsible for that exchange.
> 
> You need a functioning networking stack, and you need a way to know what
> attestation server to talk to.
> 
> IIUC, at this stage, we have no valid storage yet, since that would
> require having received the response from the attestation server.
> So the only storage we have is host storage managed by the hypervisor,
> plus whatever fits in your SVSM-provided data.
> 
> Can we send this data without additional encryption since it’s already
> cyphertext? Or do we want additional mechanisms, and if so, what root
> certificates do we use? Where do we get them from without guest storage?
> 
> Do we rely on guest networking being up at that point? Or do we need
> to provide additional mechanisms in the hypervisor to perform this
> initial exchange on behalf of the guest?

I'd be inclined to not rely on guest networking, and probably even
strictly decouple what the SVSM does to communicate, from any specific
attestation server connection protocol or details.

Implementing a network stack in SVSM looks like a very large piece of
work. It is conceivable that the guest network device is connected to
an entirely private network that can only communicate with other VMs
belonging to that guest owner. IOW, we can't assume the guest NIC has
the ability to route to the attestation server. I don't think we want
to be adding a 2nd NIC just for firmware phase attestation either.

Further if SVSM uses networking, and talks directly to the remote
attestation service, we can expect that attestation server will be
using normal best practice and exposing its service over TLS with
x509 server certs to be validated. That brings even more software
complexity into the SVSM. It would need to be told what attestation
server URL to use, though that is likely the easiest bit of the
problem since fw_cfg can supply that. If any aspect of the
attestation service protocol ever needs to change, then we also
need to update SVSM to match.


AFAICS, what SVSM needs to do for attestation is very straightforward.
It sends a blob of data, and then blocks further execution until it
gets another blob of data back in response.

From the POV of SVSM, conceptually this does not even need connection
based semantics in its communication method. So while we could use
virtio-vsock instead of a NIC, even that could be considered overkill.
An even simpler option to implement could be merely virtio-serial.
There's a possible question of whether we want a mechanism that is
cleanly separated from any device intended for guest OS usage. That
might motivate doing something separate from any existing virtual
device, that is dedicated just to SVSM attestation needs.

Whatever comms mechanism is exposed to the SVSM for early attestation
I think should only communicate with the hypervisor. A proxy on the
hypervisor would be responsible for receiving the attestation report
from SVSM, and opening up a connection to whatever attestation server
is required, getting the response and feeding it back to SVSM. We
thus rely entirely on existing hypervisor network stack, and all
knowledge about the attestation server is isolated from SVSM.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: SVSM vTPM specification

[Dr. David Alan Gilbert]

* Christophe de Dinechin (cdupontd@redhat.com) wrote:
> 
> 
> > On 18 Oct 2022, at 22:22, Dov Murik <dovmurik@linux.ibm.com> wrote:
> > 
> > 
> > 
> > On 13/10/2022 18:30, James Bottomley wrote:
> >> On Thu, 2022-10-13 at 10:14 -0500, Tom Lendacky wrote:
> >>> On 10/12/22 13:44, James Bottomley wrote:
> >>>> On Wed, 2022-10-12 at 18:33 +0100, Dr. David Alan Gilbert wrote:
> >>>>> * Tom Lendacky (thomas.lendacky@amd.com) wrote:
> >>>> [...]
> >>>>> It's important that the VMPL level in the attestation report
> >>>>> reflects the side asking for the attestation; in particular one
> >>>>> TPM story goes that the firmware (in VMPL0) would ask for an
> >>>>> attestation and the attestor would return the vTPM stored
> >>>>> state.  It's important that the state could only be returned to
> >>>>> the vTPM not the guest, so the attestor would check that the VMPL
> >>>>> level in the attestation was 0; any guest attestation would have
> >>>>> a VMPL>0 and so the attestor wouldn't hand it the vTPM state.
> >>>>> Hmm or are you saying such a report would be triggered by the
> >>>>> guest rather than the firmware, but it would be protected by
> >>>>> VMPCK0 so the guest wouldn't be able to read it?
> >>> 
> >>> No, the VMPCK0 key is just used for communication with the PSP.
> >>> 
> >>> While the SVSM would request the attestation report from the PSP,
> >>> the guest would need to request it from the SVSM.
> >> 
> >> I think this is fine.  The SVSM would do the attestation as it starts
> >> the TPM but the guest would be able to retrieve it at any time. 
> >> Essentially, if you use something like keylime, the agent would request
> >> it on start up to prove it should trust the vTPM, but that could occur
> >> way after VM boot.
> >> 
> >>> 
> >>>>> I think one of the vTPMs keys should be in the SNP attestation
> >>>>> report (the EK???) - I think that would allow you to attest that
> >>>>> the vTPM you're talking to is a vTPM running in an SNP protected
> >>>>> firmware.
> >>>> 
> >>>> Traditionally the TPM identity is the public EK, so that should
> >>>> definitely be in the report.  Ideally, I think the public storage
> >>>> root key (key derived from the owner seed) should be in there two
> >>>> because it makes it easy to create keys that can only be read by
> >>>> the TPM (keys should be in the owner hierarchy which means they
> >>>> have to be encrypted to the storage seed, so we need to know what a
> >>>> public key corresponding to it is).
> >>>> 
> >>>> One wrinkle of the above is that, when provisioned, the TPM will
> >>>> only have the seeds, not the keys (the keys are derived from the
> >>>> seeds via a TPM2_CreatePrimary command).  The current TPM
> >>>> provisioning guidance:
> >>>> 
> >>>> https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/
> >>>> 
> >>>> Says that the EK should be at permanent handle
> >>>> 
> >>>> 81010001
> >>>> 
> >>>> And there's an update saying that should be the RSA-2048 key and
> >>>> there should be an EC (NIST-P256) one at 81010002.  The
> >>>> corresponding storage keys should be at 81000001 and 81000002
> >>>> respectively.  I think when the SVSM provisions the TPM, it should
> >>>> run TPM2_CreatePrimary for those four keys and put them into the
> >>>> persistent indexes, then insert the EC keys only for EK and SRK
> >>>> into the attestation report.
> >>> 
> >>> We only have 512 bits to work with for the SVSM-provided data, so
> >>> would hashes of the keys be ok?
> >> 
> >> Well, if you put the hashes in, the consuming entity would then have to
> >> find out via an additional channel what the actual keys were because
> >> you can't reverse the hash (it's possible, just more effort).  If you
> >> use point compression, an EC key (for the NIST p-256 curve) is only 32
> >> bytes anyway, so it's the same size as a sha256 hash, so I'd say place
> >> the actual public keys into the report to give complete and usable
> >> information
> >> 
> > 
> > Do we need to leave room for a Guest-Owner-provided nonce?  Guest owner
> > will provide it to the guest OS which will provide it to the SVSM to be
> > included in REPORT_DATA of the VMPL0 attestation report.
> > 
> I think it’s a good idea, but I’m not clear on which component in the
> guest would be responsible for that exchange.

Hang on; we're mixing a few levels here.

To go back to Dov's question; the only reason to worry about 'leaving
room' for a nonce is James's idea of including actual keys and taking
all the space up.  IMHO that sounds delicate, and dependent on the key
type etc - where as if you include a hash, then you can mix a nonce in
as well.

> You need a functioning networking stack, and you need a way to know what
> attestation server to talk to.
> 
> IIUC, at this stage, we have no valid storage yet, since that would
> require having received the response from the attestation server.
> So the only storage we have is host storage managed by the hypervisor,
> plus whatever fits in your SVSM-provided data.
> 
> Can we send this data without additional encryption since it’s already
> cyphertext? Or do we want additional mechanisms, and if so, what root
> certificates do we use? Where do we get them from without guest storage?
> 
> Do we rely on guest networking being up at that point? Or do we need
> to provide additional mechanisms in the hypervisor to perform this
> initial exchange on behalf of the guest?

One question is :

  'When is the first time we need to use any of the stored
   keys or policy in the vTPM'

because as long as we don't need stored TPM state until later in the
boot process, we don't need to perform the attestation/load of the vTPM
state until then;  we *do* need to maintain the PCRs from startup,
but everything else can wait.    With SNP I think we can hold off doing
the attestation until that later point?

Perhaps that means we can wait until EFI is up to actually do the load
of the vTPM state?

Dave

> 
> 
> > If we don't add a nonce not, how can the guest owner verify the
> > freshness of the report?  Maybe the pub-EK is enough because it signs
> > the rest of the TPM-report and the guest-owner can somehow verify its
> > freshness?
> 
> I think that would work for transient vTPMs. If we want a long-lived
> vTPM, then we’d need a mechanism for the guest owner to tell, ahead of
> time, when to regenerate a new vTPM state, and to independently get
> that state. In that case, the policy of when to update the vTPM state
> would be deferred to some external server, and the process would be:
> 
> - Day 1: External server requests a new TPM state, stores state
> - Day N: Guest boots, uses that TPM state, which is then verified
>   by the external server
> - Day M: External server decides to refresh the TPM state, will now
>   only accept boots with fresher state
> 
> 
> > 
> > 
> > It looks like REPORT_DATA needs to be
> > 
> > SHA512(guest_owner_nonce || pub_EK || pub_SRK)
> > 
> > And the guest does this:
> > 
> > 1. Receive nonce from guest owner
> > 2. Calls SVSM_GET_TPM_PUB_KEYS
> > 3. Constructs report_data=sha512(guest_owner_nonce || pub_EK || pub_SRK)
> > 4. Calls SVSM_GET_SNP_ATTESTATION_REPORT(report_data)
> > 5. Send back both the report and pub_* to guest owner
> > 
> > 
> > -Dov
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: SVSM vTPM specification

[James Bottomley]

On Wed, 2022-10-19 at 12:21 +0100, Dr. David Alan Gilbert wrote:
> * Christophe de Dinechin (cdupontd@redhat.com) wrote:
> > > On 18 Oct 2022, at 22:22, Dov Murik <dovmurik@linux.ibm.com>
> > > wrote:
> > > On 13/10/2022 18:30, James Bottomley wrote:
> > > > On Thu, 2022-10-13 at 10:14 -0500, Tom Lendacky wrote:
> > > > > On 10/12/22 13:44, James Bottomley wrote:
> > > > > > On Wed, 2022-10-12 at 18:33 +0100, Dr. David Alan Gilbert
> > > > > > wrote:
> > > > > > > * Tom Lendacky (thomas.lendacky@amd.com) wrote:
> > > > > > [...]
> > > > > > > I think one of the vTPMs keys should be in the SNP
> > > > > > > attestation report (the EK???) - I think that would allow
> > > > > > > you to attest that the vTPM you're talking to is a vTPM
> > > > > > > running in an SNP protected firmware.
> > > > > > 
> > > > > > Traditionally the TPM identity is the public EK, so that
> > > > > > should definitely be in the report.  Ideally, I think the
> > > > > > public storage root key (key derived from the owner seed)
> > > > > > should be in there two because it makes it easy to create
> > > > > > keys that can only be read by the TPM (keys should be in
> > > > > > the owner hierarchy which means they have to be encrypted
> > > > > > to the storage seed, so we need to know what a public key
> > > > > > corresponding to it is).
> > > > > > 
> > > > > > One wrinkle of the above is that, when provisioned, the TPM
> > > > > > will only have the seeds, not the keys (the keys are
> > > > > > derived from the seeds via a TPM2_CreatePrimary
> > > > > > command).  The current TPM provisioning guidance:
> > > > > > 
> > > > > > https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/
> > > > > > 
> > > > > > Says that the EK should be at permanent handle
> > > > > > 
> > > > > > 81010001
> > > > > > 
> > > > > > And there's an update saying that should be the RSA-2048
> > > > > > key and there should be an EC (NIST-P256) one at
> > > > > > 81010002.  The corresponding storage keys should be at
> > > > > > 81000001 and 81000002 respectively.  I think when the SVSM
> > > > > > provisions the TPM, it should run TPM2_CreatePrimary for
> > > > > > those four keys and put them into the persistent indexes,
> > > > > > then insert the EC keys only for EK and SRK into the
> > > > > > attestation report.
> > > > > 
> > > > > We only have 512 bits to work with for the SVSM-provided
> > > > > data, so would hashes of the keys be ok?
> > > > 
> > > > Well, if you put the hashes in, the consuming entity would then
> > > > have to find out via an additional channel what the actual keys
> > > > were because you can't reverse the hash (it's possible, just
> > > > more effort).  If you use point compression, an EC key (for the
> > > > NIST p-256 curve) is only 32 bytes anyway, so it's the same
> > > > size as a sha256 hash, so I'd say place the actual public keys
> > > > into the report to give complete and usable information
> > > > 
> > > 
> > > Do we need to leave room for a Guest-Owner-provided nonce?  Guest
> > > owner will provide it to the guest OS which will provide it to
> > > the SVSM to be included in REPORT_DATA of the VMPL0 attestation
> > > report.
> > > 
> > I think it’s a good idea, but I’m not clear on which component in
> > the guest would be responsible for that exchange.
> 
> Hang on; we're mixing a few levels here.
> 
> To go back to Dov's question; the only reason to worry about 'leaving
> room' for a nonce is James's idea of including actual keys and taking
> all the space up.

Actually I didn't say I'd take up all the space.  I said including an
EC EK would take up half the space.  I asked AMD the question of where
the nonce goes separately and it does seem it has to go in here as
well, so that would rule out including the EC SRK.  That being the case
I'm fairly ambivalent whether the keys are hashed or not because you'll
need to know the SRK to wrap a key to the TPM, so you'd have to ask the
TPM to certify the SRK with the EK before you wrap.  I was interested
in providing full information in the report so you could wrap simply by
seeing it without asking for additional values, but it looks like that
isn't possible.

If the ECEK and the nonce are in the report, the sequence is

request report from SVSM and return it

verify report

TPM2_Certify(ECSRK with ECPRIMARY)

return certification data which guest owner verifies
Wrap key to ECSRK and send to guest

If the nonce and a sha256(ECPRIMARY|ECSRK) are in the report, the
sequence is

request report from SVSM
TPM2_ReadPublic(81010002)
TPM2_ReadPublic(81000002)
return both keys and report

recreate hash and verify report
Wrap key to ECSRK and send to guest

I don't think there's much in it.

>   IMHO that sounds delicate, and dependent on the key type etc -
> where as if you include a hash, then you can mix a nonce in as well.

Half nonce half information (32 bytes each) sounds about right.  I have
a slight preference for including a nonce directly rather than hashed
because for durable attestation you can prove independent nonces simply
from the report.  If you hash the nonce you need both it and the report
in the durable attestation.

James

Re: SVSM vTPM specification

[Christophe de Dinechin]

On 2022-10-19 at 09:08 +01, Daniel P. Berrangé <berrange@redhat.com> wrote...
> On Wed, Oct 19, 2022 at 07:47:41AM +0200, Christophe de Dinechin wrote:
>>
>>
>> > On 18 Oct 2022, at 22:22, Dov Murik <dovmurik@linux.ibm.com> wrote:
>> >
>> >
>> >
>> > On 13/10/2022 18:30, James Bottomley wrote:
>> >> On Thu, 2022-10-13 at 10:14 -0500, Tom Lendacky wrote:
>> >>> On 10/12/22 13:44, James Bottomley wrote:
>> >>>> On Wed, 2022-10-12 at 18:33 +0100, Dr. David Alan Gilbert wrote:
>> >>>>> I think one of the vTPMs keys should be in the SNP attestation
>> >>>>> report (the EK???) - I think that would allow you to attest that
>> >>>>> the vTPM you're talking to is a vTPM running in an SNP protected
>> >>>>> firmware.
>> >>>>
>> >>>> Traditionally the TPM identity is the public EK, so that should
>> >>>> definitely be in the report.  Ideally, I think the public storage
>> >>>> root key (key derived from the owner seed) should be in there two
>> >>>> because it makes it easy to create keys that can only be read by
>> >>>> the TPM (keys should be in the owner hierarchy which means they
>> >>>> have to be encrypted to the storage seed, so we need to know what a
>> >>>> public key corresponding to it is).
>> >>>>
>> >>>> One wrinkle of the above is that, when provisioned, the TPM will
>> >>>> only have the seeds, not the keys (the keys are derived from the
>> >>>> seeds via a TPM2_CreatePrimary command).  The current TPM
>> >>>> provisioning guidance:
>> >>>>
>> >>>> https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/
>> >>>>
>> >>>> Says that the EK should be at permanent handle
>> >>>>
>> >>>> 81010001
>> >>>>
>> >>>> And there's an update saying that should be the RSA-2048 key and
>> >>>> there should be an EC (NIST-P256) one at 81010002.  The
>> >>>> corresponding storage keys should be at 81000001 and 81000002
>> >>>> respectively.  I think when the SVSM provisions the TPM, it should
>> >>>> run TPM2_CreatePrimary for those four keys and put them into the
>> >>>> persistent indexes, then insert the EC keys only for EK and SRK
>> >>>> into the attestation report.
>> >>>
>> >>> We only have 512 bits to work with for the SVSM-provided data, so
>> >>> would hashes of the keys be ok?
>> >>
>> >> Well, if you put the hashes in, the consuming entity would then have
>> >> to find out via an additional channel what the actual keys were
>> >> because you can't reverse the hash (it's possible, just more effort).
>> >> If you use point compression, an EC key (for the NIST p-256 curve) is
>> >> only 32 bytes anyway, so it's the same size as a sha256 hash, so I'd
>> >> say place the actual public keys into the report to give complete and
>> >> usable information
>> >>
>> >
>> > Do we need to leave room for a Guest-Owner-provided nonce?  Guest owner
>> > will provide it to the guest OS which will provide it to the SVSM to be
>> > included in REPORT_DATA of the VMPL0 attestation report.
>> >
>> I think it’s a good idea, but I’m not clear on which component in the
>> guest would be responsible for that exchange.
>>
>> You need a functioning networking stack, and you need a way to know what
>> attestation server to talk to.
>>
>> IIUC, at this stage, we have no valid storage yet, since that would
>> require having received the response from the attestation server.  So the
>> only storage we have is host storage managed by the hypervisor, plus
>> whatever fits in your SVSM-provided data.
>>
>> Can we send this data without additional encryption since it’s already
>> cyphertext? Or do we want additional mechanisms, and if so, what root
>> certificates do we use? Where do we get them from without guest storage?
>>
>> Do we rely on guest networking being up at that point? Or do we need to
>> provide additional mechanisms in the hypervisor to perform this initial
>> exchange on behalf of the guest?
>
> I'd be inclined to not rely on guest networking, and probably even
> strictly decouple what the SVSM does to communicate, from any specific
> attestation server connection protocol or details.
>
> Implementing a network stack in SVSM looks like a very large piece of
> work. It is conceivable that the guest network device is connected to an
> entirely private network that can only communicate with other VMs
> belonging to that guest owner. IOW, we can't assume the guest NIC has the
> ability to route to the attestation server. I don't think we want to be
> adding a 2nd NIC just for firmware phase attestation either.

Yes, I was thinking about this scenario, but also wondering if the opposite
can happen, i.e. a guest having networking to the attestation server that
the host does not have access to. I can think of two cases that seem to make
sense (though not necessarily in public clouds):

- The guest has a dedicated hardware port to some private network
  e.g. through a virtual function
- The guest only networks to other VMs on the same host, without a phsyical
  NIC attached. Another (confidential) VM could be the attestation server.

So this is a bit of a can of worms.

>
> Further if SVSM uses networking, and talks directly to the remote
> attestation service, we can expect that attestation server will be
> using normal best practice and exposing its service over TLS with
> x509 server certs to be validated. That brings even more software
> complexity into the SVSM. It would need to be told what attestation
> server URL to use, though that is likely the easiest bit of the
> problem since fw_cfg can supply that. If any aspect of the
> attestation service protocol ever needs to change, then we also
> need to update SVSM to match.

Exactly.

>
>
> AFAICS, what SVSM needs to do for attestation is very straightforward.
> It sends a blob of data, and then blocks further execution until it
> gets another blob of data back in response.
>
> From the POV of SVSM, conceptually this does not even need connection
> based semantics in its communication method. So while we could use
> virtio-vsock instead of a NIC, even that could be considered overkill.
> An even simpler option to implement could be merely virtio-serial.
> There's a possible question of whether we want a mechanism that is
> cleanly separated from any device intended for guest OS usage. That
> might motivate doing something separate from any existing virtual
> device, that is dedicated just to SVSM attestation needs.

Bringing another architecture into the picture, if I understand the TDX
philosophy correctly, they would typically expect another enclave on the
same host to provide this kind of service.


>
> Whatever comms mechanism is exposed to the SVSM for early attestation
> I think should only communicate with the hypervisor. A proxy on the
> hypervisor would be responsible for receiving the attestation report
> from SVSM, and opening up a connection to whatever attestation server
> is required, getting the response and feeding it back to SVSM. We
> thus rely entirely on existing hypervisor network stack, and all
> knowledge about the attestation server is isolated from SVSM.
>

So I think that a configurable vsock-based or virtio-serial mechanism in
qemu that facilitates this kind of data exchange might be the right
approach. By "configurable", I mean that you should be able to pass it at
least the IP address to talk to, and possibly some TLS certificates to use
for the communication. And ideally, it should also be able to use a socket
to talk to another VM if that's the setup the guest owner chooses.

As pointed out above, such a mechanism could probably be designed to also be
usable by other architectures.

>
> With regards,
> Daniel


--
Cheers,
Christophe de Dinechin (https://c3d.github.io)
Theory of Incomplete Measurements (https://c3d.github.io/TIM)

Re: SVSM vTPM specification

[James Bottomley]

On Wed, 2022-10-19 at 09:08 +0100, Daniel P. Berrangé wrote:
> I'd be inclined to not rely on guest networking, and probably even
> strictly decouple what the SVSM does to communicate, from any
> specific attestation server connection protocol or details.

I think we should be clear: if you need a secret at start of day,
before the guest boots, then you need to retrieve an attestation from
the SVSM and inject a secret.  If you can delay needing the secret
until after boot (say for data volumes) then you can use the cloud
standard methods we have today (which actually do mostly operate over
the guest network path) and a TPM which manufactures on boot.

However, the above mechanism is out of scope for the vTPM project. 
This is simply about putting a vTPM into the SVSM which appears in the
guest as a TPM and providing a guest API to retrieve its attestation. 
So the scope of the project ends there.

If we want a TPM with persistent state, then the state has to be
injected pre-boot but that is the same pre-boot problem as all secret
injection.  I think there should be a separate project working on this
and we'll make sure they interlock correctly.

So I think there are three pieces

   1. Ephemeral vTPM with attestation retrieved from guest
   2. Attestation and injection API from SVSM to host/guest end point
   3. SVSM API for saving TPM state

We'll work initially on 1. Someone else can work on 2. but we'll make
sure they fit together.  3. would be required for full TPM emulation,
but might not be required if all we want is persistence of the seeds of
the TPM, so this would be evaluated when we have 1+2.

James

Re: SVSM vTPM specification

[Daniel P. Berrangé]

On Wed, Oct 19, 2022 at 08:38:19AM -0400, James Bottomley wrote:
> On Wed, 2022-10-19 at 09:08 +0100, Daniel P. Berrangé wrote:
> > I'd be inclined to not rely on guest networking, and probably even
> > strictly decouple what the SVSM does to communicate, from any
> > specific attestation server connection protocol or details.
> 
> I think we should be clear: if you need a secret at start of day,
> before the guest boots, then you need to retrieve an attestation from
> the SVSM and inject a secret.  If you can delay needing the secret
> until after boot (say for data volumes) then you can use the cloud
> standard methods we have today (which actually do mostly operate over
> the guest network path) and a TPM which manufactures on boot.
> 
> However, the above mechanism is out of scope for the vTPM project. 
> This is simply about putting a vTPM into the SVSM which appears in the
> guest as a TPM and providing a guest API to retrieve its attestation. 
> So the scope of the project ends there.
> 
> If we want a TPM with persistent state, then the state has to be
> injected pre-boot but that is the same pre-boot problem as all secret
> injection.  I think there should be a separate project working on this
> and we'll make sure they interlock correctly.
> 
> So I think there are three pieces
> 
>    1. Ephemeral vTPM with attestation retrieved from guest
>    2. Attestation and injection API from SVSM to host/guest end point
>    3. SVSM API for saving TPM state
> 
> We'll work initially on 1. Someone else can work on 2. but we'll make
> sure they fit together.  3. would be required for full TPM emulation,
> but might not be required if all we want is persistence of the seeds of
> the TPM, so this would be evaluated when we have 1+2.

Yes, that all makes sense to me as a division of concepts & work.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: SVSM vTPM specification

[Tom Lendacky]

On 10/19/22 08:05, Daniel P. Berrangé wrote:
> On Wed, Oct 19, 2022 at 08:38:19AM -0400, James Bottomley wrote:
>> On Wed, 2022-10-19 at 09:08 +0100, Daniel P. Berrangé wrote:
>>> I'd be inclined to not rely on guest networking, and probably even
>>> strictly decouple what the SVSM does to communicate, from any
>>> specific attestation server connection protocol or details.
>>
>> I think we should be clear: if you need a secret at start of day,
>> before the guest boots, then you need to retrieve an attestation from
>> the SVSM and inject a secret.  If you can delay needing the secret
>> until after boot (say for data volumes) then you can use the cloud
>> standard methods we have today (which actually do mostly operate over
>> the guest network path) and a TPM which manufactures on boot.
>>
>> However, the above mechanism is out of scope for the vTPM project.
>> This is simply about putting a vTPM into the SVSM which appears in the
>> guest as a TPM and providing a guest API to retrieve its attestation.
>> So the scope of the project ends there.
>>
>> If we want a TPM with persistent state, then the state has to be
>> injected pre-boot but that is the same pre-boot problem as all secret
>> injection.  I think there should be a separate project working on this
>> and we'll make sure they interlock correctly.
>>
>> So I think there are three pieces
>>
>>     1. Ephemeral vTPM with attestation retrieved from guest
>>     2. Attestation and injection API from SVSM to host/guest end point
>>     3. SVSM API for saving TPM state
>>
>> We'll work initially on 1. Someone else can work on 2. but we'll make
>> sure they fit together.  3. would be required for full TPM emulation,
>> but might not be required if all we want is persistence of the seeds of
>> the TPM, so this would be evaluated when we have 1+2.
> 
> Yes, that all makes sense to me as a division of concepts & work.

There was some offline talk about possibly putting the attestation report 
in the TPM NV area and allowing it to be pulled via TPM commands. However, 
if we want to be able to supply a new NONCE each time, I think, instead, 
that calls for it's own function in the SVSM vTPM protocol.

Currently, there are two functions in the vTPM protocol:

   1. An attestation report function
      - Input:
          - NONCE GPA (RCX)
          - NONCE size (RDX)
          - Report destination GPA (R8)
          - Report destination size (R9)
      - Output:
          - Result code (RAX)

      NONCE copied to SNP MSG_REPORT_REQ:REPORT_DATA[511:256].

      SHA-256 (EK Public Key | SRK Public Key) copied to SNP
      MSG_REPORT_REQ:REPORT_DATA[255:0].

      On success, the report is present at Report Destination GPA.

      If a new way of creating REPORT_DATA is needed in the future, the
      protocol could be extended with a new attestation report function
      (following the SVSM Core Protocol design of being additive).


   2. A vTPM operation function
      - Input:
          - Command GPA (RCX)
          - Command size (RDX)
          - Response GPA (R8)
          - Response size (R9)
      - Output:
          - Result code (RAX)

      On success, the result is present at Response GPA.

      @James Bottomley, I noticed in an earlier response that you had the
      Response size as a possible output, is that needed? The response
      output (header) contains the actual length of the response.

Are there any other functions that are needed?

Thanks,
Tom

> 
> With regards,
> Daniel

Re: SVSM vTPM specification

[James Bottomley]

On Wed, 2022-10-19 at 09:43 -0500, Tom Lendacky wrote:
> On 10/19/22 08:05, Daniel P. Berrangé wrote:
> > On Wed, Oct 19, 2022 at 08:38:19AM -0400, James Bottomley wrote:
> > > On Wed, 2022-10-19 at 09:08 +0100, Daniel P. Berrangé wrote:
> > > > I'd be inclined to not rely on guest networking, and probably
> > > > even strictly decouple what the SVSM does to communicate, from
> > > > any specific attestation server connection protocol or details.
> > > 
> > > I think we should be clear: if you need a secret at start of day,
> > > before the guest boots, then you need to retrieve an attestation
> > > from the SVSM and inject a secret.  If you can delay needing the
> > > secret until after boot (say for data volumes) then you can use
> > > the cloud standard methods we have today (which actually do
> > > mostly operate over the guest network path) and a TPM which
> > > manufactures on boot.
> > > 
> > > However, the above mechanism is out of scope for the vTPM
> > > project. This is simply about putting a vTPM into the SVSM which
> > > appears in the guest as a TPM and providing a guest API to
> > > retrieve its attestation. So the scope of the project ends there.
> > > 
> > > If we want a TPM with persistent state, then the state has to be
> > > injected pre-boot but that is the same pre-boot problem as all
> > > secret injection.  I think there should be a separate project
> > > working on this and we'll make sure they interlock correctly.
> > > 
> > > So I think there are three pieces
> > > 
> > >     1. Ephemeral vTPM with attestation retrieved from guest
> > >     2. Attestation and injection API from SVSM to host/guest end
> > > point
> > >     3. SVSM API for saving TPM state
> > > 
> > > We'll work initially on 1. Someone else can work on 2. but we'll
> > > make
> > > sure they fit together.  3. would be required for full TPM
> > > emulation,
> > > but might not be required if all we want is persistence of the
> > > seeds of
> > > the TPM, so this would be evaluated when we have 1+2.
> > 
> > Yes, that all makes sense to me as a division of concepts & work.
> 
> There was some offline talk about possibly putting the attestation
> report in the TPM NV area and allowing it to be pulled via TPM
> commands. However,  if we want to be able to supply a new NONCE each
> time, I think, instead, that calls for it's own function in the SVSM
> vTPM protocol.
> 
> Currently, there are two functions in the vTPM protocol:
> 
>    1. An attestation report function
>       - Input:
>           - NONCE GPA (RCX)
>           - NONCE size (RDX)
>           - Report destination GPA (R8)
>           - Report destination size (R9)
>       - Output:
>           - Result code (RAX)
> 
>       NONCE copied to SNP MSG_REPORT_REQ:REPORT_DATA[511:256].
> 
>       SHA-256 (EK Public Key | SRK Public Key) copied to SNP
>       MSG_REPORT_REQ:REPORT_DATA[255:0].

You still have to define *which* public key here.  Recall the TPM
internally has a seed.  First you have to derive the public key from
that seed.  I'd still favour using the NIST-P256 derivation of the
public key according to the TCG template, because NIST is going to
deprecate RSA-2048 at some point.

> 
>       On success, the report is present at Report Destination GPA.
> 
>       If a new way of creating REPORT_DATA is needed in the future,
> the
>       protocol could be extended with a new attestation report
> function


One thing we have to remember is that if we add any additional
attestation APIs, they can't allow them ever be used to generate a
report that looks like a vTPM attestation.  So if that's likely we'll
need multiple types of data put into the report, should we steal a byte
of the report data to specify what type of report (0 for TPM, 1 for the
next type and so on).

That way a consumer could rely on the fact that if the first byte was 0
this must be a vTPM report and nothing else could fake it.

>    2. A vTPM operation function
>       - Input:
>           - Command GPA (RCX)
>           - Command size (RDX)
>           - Response GPA (R8)
>           - Response size (R9)
>       - Output:
>           - Result code (RAX)
> 
>       On success, the result is present at Response GPA.
> 
>       @James Bottomley, I noticed in an earlier response that you had
> the
>       Response size as a possible output, is that needed? The
> response
>       output (header) contains the actual length of the response.

I think we can get away with just command GPA and size and put the
response back into the command buffer, given that's the way the linux
driver will work.  We will still need to return the response size since
it may be less than the command size.  I think the function definition
will have to specify that at least a page is available for writing at
RCX so we can cope with response size > command size.  The current ms
tpm defines the values MAX_COMMAND_SIZE and MAX_RESPONSE_SIZE and
they're currently hard coded to 4096, so we can rely on this value for
a while.

James

Re: SVSM vTPM specification

[Dov Murik]

On 19/10/2022 17:43, Tom Lendacky wrote:
> On 10/19/22 08:05, Daniel P. Berrangé wrote:
>> On Wed, Oct 19, 2022 at 08:38:19AM -0400, James Bottomley wrote:
>>> On Wed, 2022-10-19 at 09:08 +0100, Daniel P. Berrangé wrote:
>>>> I'd be inclined to not rely on guest networking, and probably even
>>>> strictly decouple what the SVSM does to communicate, from any
>>>> specific attestation server connection protocol or details.
>>>
>>> I think we should be clear: if you need a secret at start of day,
>>> before the guest boots, then you need to retrieve an attestation from
>>> the SVSM and inject a secret.  If you can delay needing the secret
>>> until after boot (say for data volumes) then you can use the cloud
>>> standard methods we have today (which actually do mostly operate over
>>> the guest network path) and a TPM which manufactures on boot.
>>>
>>> However, the above mechanism is out of scope for the vTPM project.
>>> This is simply about putting a vTPM into the SVSM which appears in the
>>> guest as a TPM and providing a guest API to retrieve its attestation.
>>> So the scope of the project ends there.
>>>
>>> If we want a TPM with persistent state, then the state has to be
>>> injected pre-boot but that is the same pre-boot problem as all secret
>>> injection.  I think there should be a separate project working on this
>>> and we'll make sure they interlock correctly.
>>>
>>> So I think there are three pieces
>>>
>>>     1. Ephemeral vTPM with attestation retrieved from guest
>>>     2. Attestation and injection API from SVSM to host/guest end point
>>>     3. SVSM API for saving TPM state
>>>
>>> We'll work initially on 1. Someone else can work on 2. but we'll make
>>> sure they fit together.  3. would be required for full TPM emulation,
>>> but might not be required if all we want is persistence of the seeds of
>>> the TPM, so this would be evaluated when we have 1+2.
>>
>> Yes, that all makes sense to me as a division of concepts & work.
> 
> There was some offline talk about possibly putting the attestation
> report in the TPM NV area and allowing it to be pulled via TPM commands.
> However, if we want to be able to supply a new NONCE each time, I think,
> instead, that calls for it's own function in the SVSM vTPM protocol.
> 
> Currently, there are two functions in the vTPM protocol:
> 
>   1. An attestation report function
>      - Input:
>          - NONCE GPA (RCX)
>          - NONCE size (RDX)

NONCE size must be 32 (bytes)?
or 31 if we use the initial type byte (See below).

>          - Report destination GPA (R8)
>          - Report destination size (R9)
>      - Output:
>          - Result code (RAX)
> 
>      NONCE copied to SNP MSG_REPORT_REQ:REPORT_DATA[511:256].

James suggested:

[511:504] - type byte 0x00 = vtpm attestation report
[503:256] - 31 bytes nonce

> 
>      SHA-256 (EK Public Key | SRK Public Key) copied to SNP
>      MSG_REPORT_REQ:REPORT_DATA[255:0].
> 
>      On success, the report is present at Report Destination GPA.
> 
>      If a new way of creating REPORT_DATA is needed in the future, the
>      protocol could be extended with a new attestation report function
>      (following the SVSM Core Protocol design of being additive).


It's just a bit weird that the SNP attestation report function is part
of the vTPM protocol; but I guess that it is needed so we can
distinguish it from other future types of attestation reports (with
James's suggested "type" byte, which must never be user-controlled; it
must be set inside the SVSM).



Hmm, do we need also something like SNP_GET_EXT_REPORT which also
returns the cert-chain stored in the host kernel? Or modify this call to
also return the certs?



> 
>   2. A vTPM operation function
>      - Input:
>          - Command GPA (RCX)
>          - Command size (RDX)
>          - Response GPA (R8)
>          - Response size (R9)
>      - Output:
>          - Result code (RAX)
> 
>      On success, the result is present at Response GPA.
> 
>      @James Bottomley, I noticed in an earlier response that you had the
>      Response size as a possible output, is that needed? The response
>      output (header) contains the actual length of the response.
> 
> Are there any other functions that are needed?
> 

Looks good to me.  I think this is what we have in our prototype as well.

(But see my thought about equivalent of SNP_GET_EXT_REPORT.)

-Dov

Re: SVSM vTPM specification

[Tom Lendacky]

On 10/19/22 10:20, James Bottomley wrote:
> On Wed, 2022-10-19 at 09:43 -0500, Tom Lendacky wrote:
>> On 10/19/22 08:05, Daniel P. Berrangé wrote:
>>> On Wed, Oct 19, 2022 at 08:38:19AM -0400, James Bottomley wrote:
>>>> On Wed, 2022-10-19 at 09:08 +0100, Daniel P. Berrangé wrote:
>>>>> I'd be inclined to not rely on guest networking, and probably
>>>>> even strictly decouple what the SVSM does to communicate, from
>>>>> any specific attestation server connection protocol or details.
>>>>
>>>> I think we should be clear: if you need a secret at start of day,
>>>> before the guest boots, then you need to retrieve an attestation
>>>> from the SVSM and inject a secret.  If you can delay needing the
>>>> secret until after boot (say for data volumes) then you can use
>>>> the cloud standard methods we have today (which actually do
>>>> mostly operate over the guest network path) and a TPM which
>>>> manufactures on boot.
>>>>
>>>> However, the above mechanism is out of scope for the vTPM
>>>> project. This is simply about putting a vTPM into the SVSM which
>>>> appears in the guest as a TPM and providing a guest API to
>>>> retrieve its attestation. So the scope of the project ends there.
>>>>
>>>> If we want a TPM with persistent state, then the state has to be
>>>> injected pre-boot but that is the same pre-boot problem as all
>>>> secret injection.  I think there should be a separate project
>>>> working on this and we'll make sure they interlock correctly.
>>>>
>>>> So I think there are three pieces
>>>>
>>>>      1. Ephemeral vTPM with attestation retrieved from guest
>>>>      2. Attestation and injection API from SVSM to host/guest end
>>>> point
>>>>      3. SVSM API for saving TPM state
>>>>
>>>> We'll work initially on 1. Someone else can work on 2. but we'll
>>>> make
>>>> sure they fit together.  3. would be required for full TPM
>>>> emulation,
>>>> but might not be required if all we want is persistence of the
>>>> seeds of
>>>> the TPM, so this would be evaluated when we have 1+2.
>>>
>>> Yes, that all makes sense to me as a division of concepts & work.
>>
>> There was some offline talk about possibly putting the attestation
>> report in the TPM NV area and allowing it to be pulled via TPM
>> commands. However,  if we want to be able to supply a new NONCE each
>> time, I think, instead, that calls for it's own function in the SVSM
>> vTPM protocol.
>>
>> Currently, there are two functions in the vTPM protocol:
>>
>>     1. An attestation report function
>>        - Input:
>>            - NONCE GPA (RCX)
>>            - NONCE size (RDX)
>>            - Report destination GPA (R8)
>>            - Report destination size (R9)
>>        - Output:
>>            - Result code (RAX)
>>
>>        NONCE copied to SNP MSG_REPORT_REQ:REPORT_DATA[511:256].
>>
>>        SHA-256 (EK Public Key | SRK Public Key) copied to SNP
>>        MSG_REPORT_REQ:REPORT_DATA[255:0].
> 
> You still have to define *which* public key here.  Recall the TPM
> internally has a seed.  First you have to derive the public key from
> that seed.  I'd still favour using the NIST-P256 derivation of the
> public key according to the TCG template, because NIST is going to
> deprecate RSA-2048 at some point.

Right, so it will be the EC EK and EC SRK.

Do you have a pointer to the TCG template you're referring too?

> 
>>
>>        On success, the report is present at Report Destination GPA.
>>
>>        If a new way of creating REPORT_DATA is needed in the future,
>> the
>>        protocol could be extended with a new attestation report
>> function
> 
> 
> One thing we have to remember is that if we add any additional
> attestation APIs, they can't allow them ever be used to generate a
> report that looks like a vTPM attestation.  So if that's likely we'll
> need multiple types of data put into the report, should we steal a byte
> of the report data to specify what type of report (0 for TPM, 1 for the
> next type and so on).

That sounds pretty reasonable.

> 
> That way a consumer could rely on the fact that if the first byte was 0
> this must be a vTPM report and nothing else could fake it.
> 
>>     2. A vTPM operation function
>>        - Input:
>>            - Command GPA (RCX)
>>            - Command size (RDX)
>>            - Response GPA (R8)
>>            - Response size (R9)
>>        - Output:
>>            - Result code (RAX)
>>
>>        On success, the result is present at Response GPA.
>>
>>        @James Bottomley, I noticed in an earlier response that you had
>> the
>>        Response size as a possible output, is that needed? The
>> response
>>        output (header) contains the actual length of the response.
> 
> I think we can get away with just command GPA and size and put the
> response back into the command buffer, given that's the way the linux
> driver will work.  We will still need to return the response size since

But it may not be how other drivers would prefer to work. The spec has to 
be OS agnostic, so I'd prefer to keep both. The Linux driver could just 
set them to the same address.

The response has to include the tpm_header, which contains the length, 
correct? If we don't have to return the length back I'd prefer not to.

> it may be less than the command size.  I think the function definition
> will have to specify that at least a page is available for writing at
> RCX so we can cope with response size > command size.  The current ms
> tpm defines the values MAX_COMMAND_SIZE and MAX_RESPONSE_SIZE and
> they're currently hard coded to 4096, so we can rely on this value for
> a while.

Sounds good.

Thanks,
Tom

> 
> James
> 
> 

Re: SVSM vTPM specification

[Tom Lendacky]

On 10/19/22 15:57, Dov Murik wrote:
> 
> 
> On 19/10/2022 17:43, Tom Lendacky wrote:
>> On 10/19/22 08:05, Daniel P. Berrangé wrote:
>>> On Wed, Oct 19, 2022 at 08:38:19AM -0400, James Bottomley wrote:
>>>> On Wed, 2022-10-19 at 09:08 +0100, Daniel P. Berrangé wrote:
>>>>> I'd be inclined to not rely on guest networking, and probably even
>>>>> strictly decouple what the SVSM does to communicate, from any
>>>>> specific attestation server connection protocol or details.
>>>>
>>>> I think we should be clear: if you need a secret at start of day,
>>>> before the guest boots, then you need to retrieve an attestation from
>>>> the SVSM and inject a secret.  If you can delay needing the secret
>>>> until after boot (say for data volumes) then you can use the cloud
>>>> standard methods we have today (which actually do mostly operate over
>>>> the guest network path) and a TPM which manufactures on boot.
>>>>
>>>> However, the above mechanism is out of scope for the vTPM project.
>>>> This is simply about putting a vTPM into the SVSM which appears in the
>>>> guest as a TPM and providing a guest API to retrieve its attestation.
>>>> So the scope of the project ends there.
>>>>
>>>> If we want a TPM with persistent state, then the state has to be
>>>> injected pre-boot but that is the same pre-boot problem as all secret
>>>> injection.  I think there should be a separate project working on this
>>>> and we'll make sure they interlock correctly.
>>>>
>>>> So I think there are three pieces
>>>>
>>>>      1. Ephemeral vTPM with attestation retrieved from guest
>>>>      2. Attestation and injection API from SVSM to host/guest end point
>>>>      3. SVSM API for saving TPM state
>>>>
>>>> We'll work initially on 1. Someone else can work on 2. but we'll make
>>>> sure they fit together.  3. would be required for full TPM emulation,
>>>> but might not be required if all we want is persistence of the seeds of
>>>> the TPM, so this would be evaluated when we have 1+2.
>>>
>>> Yes, that all makes sense to me as a division of concepts & work.
>>
>> There was some offline talk about possibly putting the attestation
>> report in the TPM NV area and allowing it to be pulled via TPM commands.
>> However, if we want to be able to supply a new NONCE each time, I think,
>> instead, that calls for it's own function in the SVSM vTPM protocol.
>>
>> Currently, there are two functions in the vTPM protocol:
>>
>>    1. An attestation report function
>>       - Input:
>>           - NONCE GPA (RCX)
>>           - NONCE size (RDX)
> 
> NONCE size must be 32 (bytes)?
> or 31 if we use the initial type byte (See below).
> 
>>           - Report destination GPA (R8)
>>           - Report destination size (R9)
>>       - Output:
>>           - Result code (RAX)
>>
>>       NONCE copied to SNP MSG_REPORT_REQ:REPORT_DATA[511:256].
> 
> James suggested:
> 
> [511:504] - type byte 0x00 = vtpm attestation report
> [503:256] - 31 bytes nonce

Sound good.

> 
>>
>>       SHA-256 (EK Public Key | SRK Public Key) copied to SNP
>>       MSG_REPORT_REQ:REPORT_DATA[255:0].
>>
>>       On success, the report is present at Report Destination GPA.
>>
>>       If a new way of creating REPORT_DATA is needed in the future, the
>>       protocol could be extended with a new attestation report function
>>       (following the SVSM Core Protocol design of being additive).
> 
> 
> It's just a bit weird that the SNP attestation report function is part
> of the vTPM protocol; but I guess that it is needed so we can
> distinguish it from other future types of attestation reports (with
> James's suggested "type" byte, which must never be user-controlled; it
> must be set inside the SVSM).
> 
> 
> 
> Hmm, do we need also something like SNP_GET_EXT_REPORT which also
> returns the cert-chain stored in the host kernel? Or modify this call to
> also return the certs?

Yes, good catch. I believe we do. Adding two more parameters (maybe change 
this to a struct now?) for Cert Data GPA and Cert Data size is the way to 
go. We want the Cert Data that is associated with the attestation report 
that was generated, in an "atomic" way. Once live migration is available, 
the VM could theoretically be migrated in between two functions calls and 
then the VCEK wouldn't match.

Thanks,
Tom

> 
> 
> 
>>
>>    2. A vTPM operation function
>>       - Input:
>>           - Command GPA (RCX)
>>           - Command size (RDX)
>>           - Response GPA (R8)
>>           - Response size (R9)
>>       - Output:
>>           - Result code (RAX)
>>
>>       On success, the result is present at Response GPA.
>>
>>       @James Bottomley, I noticed in an earlier response that you had the
>>       Response size as a possible output, is that needed? The response
>>       output (header) contains the actual length of the response.
>>
>> Are there any other functions that are needed?
>>
> 
> Looks good to me.  I think this is what we have in our prototype as well.
> 
> (But see my thought about equivalent of SNP_GET_EXT_REPORT.)
> 
> -Dov

Re: SVSM vTPM specification

[Dionna Amalie Glaze]

> >
> > Hmm, do we need also something like SNP_GET_EXT_REPORT which also
> > returns the cert-chain stored in the host kernel? Or modify this call to
> > also return the certs?
>
> Yes, good catch. I believe we do. Adding two more parameters (maybe change
> this to a struct now?) for Cert Data GPA and Cert Data size is the way to
> go. We want the Cert Data that is associated with the attestation report
> that was generated, in an "atomic" way. Once live migration is available,
> the VM could theoretically be migrated in between two functions calls and
> then the VCEK wouldn't match.
>
> Thanks,
> Tom
>
> >

I thought that TPM2_EC_Emphemeral would get the EC public key and
Tspi_Key_GetPubKey could be used to get the SRK public key. I might be
mistaken, but I believe the TPM has commands for this already, so the
vTPM protocol doesn't need an extra entrypoint. The TPM keys shouldn't
change through live migration, so querying separately should work.

-- 
-Dionna Glaze, PhD (she/her)

RE: [EXTERNAL] Re: SVSM vTPM specification

[David Altobelli]

[ Sorry in advance for formatting issues ]

>>       SHA-256 (EK Public Key | SRK Public Key) copied to SNP
>>       MSG_REPORT_REQ:REPORT_DATA[255:0].
>>

I think we are likely to want to attest more data over time, hashing JSON with JWK could be easily extended to add more fields.  If you wanted multiple types of report in a single call, the JSON data could be nested, to separate out vTPM vs whatever else.  JSON Data could be appended after hardware report (though that might require some additional unattested metadata describing content), or returned some other way.

-----Original Message-----
From: AMD-SEV-SNP <amd-sev-snp-bounces+daaltobe=microsoft.com@lists.suse.com> On Behalf Of Tom Lendacky
Sent: Wednesday, October 19, 2022 3:05 PM
To: Dov Murik <dovmurik@linux.ibm.com>; Daniel P. Berrangé <berrange@redhat.com>; James Bottomley <jejb@linux.ibm.com>
Cc: linux-coco@lists.linux.dev; amd-sev-snp@lists.suse.com; Christophe de Dinechin <cdupontd@redhat.com>
Subject: [EXTERNAL] Re: SVSM vTPM specification

On 10/19/22 15:57, Dov Murik wrote:
> 
> 
> On 19/10/2022 17:43, Tom Lendacky wrote:
>> On 10/19/22 08:05, Daniel P. Berrangé wrote:
>>> On Wed, Oct 19, 2022 at 08:38:19AM -0400, James Bottomley wrote:
>>>> On Wed, 2022-10-19 at 09:08 +0100, Daniel P. Berrangé wrote:
>>>>> I'd be inclined to not rely on guest networking, and probably even 
>>>>> strictly decouple what the SVSM does to communicate, from any 
>>>>> specific attestation server connection protocol or details.
>>>>
>>>> I think we should be clear: if you need a secret at start of day, 
>>>> before the guest boots, then you need to retrieve an attestation 
>>>> from the SVSM and inject a secret.  If you can delay needing the 
>>>> secret until after boot (say for data volumes) then you can use the 
>>>> cloud standard methods we have today (which actually do mostly 
>>>> operate over the guest network path) and a TPM which manufactures on boot.
>>>>
>>>> However, the above mechanism is out of scope for the vTPM project.
>>>> This is simply about putting a vTPM into the SVSM which appears in 
>>>> the guest as a TPM and providing a guest API to retrieve its attestation.
>>>> So the scope of the project ends there.
>>>>
>>>> If we want a TPM with persistent state, then the state has to be 
>>>> injected pre-boot but that is the same pre-boot problem as all 
>>>> secret injection.  I think there should be a separate project 
>>>> working on this and we'll make sure they interlock correctly.
>>>>
>>>> So I think there are three pieces
>>>>
>>>>      1. Ephemeral vTPM with attestation retrieved from guest
>>>>      2. Attestation and injection API from SVSM to host/guest end 
>>>> point
>>>>      3. SVSM API for saving TPM state
>>>>
>>>> We'll work initially on 1. Someone else can work on 2. but we'll 
>>>> make sure they fit together.  3. would be required for full TPM 
>>>> emulation, but might not be required if all we want is persistence 
>>>> of the seeds of the TPM, so this would be evaluated when we have 1+2.
>>>
>>> Yes, that all makes sense to me as a division of concepts & work.
>>
>> There was some offline talk about possibly putting the attestation 
>> report in the TPM NV area and allowing it to be pulled via TPM commands.
>> However, if we want to be able to supply a new NONCE each time, I 
>> think, instead, that calls for it's own function in the SVSM vTPM protocol.
>>
>> Currently, there are two functions in the vTPM protocol:
>>
>>    1. An attestation report function
>>       - Input:
>>           - NONCE GPA (RCX)
>>           - NONCE size (RDX)
> 
> NONCE size must be 32 (bytes)?
> or 31 if we use the initial type byte (See below).
> 
>>           - Report destination GPA (R8)
>>           - Report destination size (R9)
>>       - Output:
>>           - Result code (RAX)
>>
>>       NONCE copied to SNP MSG_REPORT_REQ:REPORT_DATA[511:256].
> 
> James suggested:
> 
> [511:504] - type byte 0x00 = vtpm attestation report [503:256] - 31 
> bytes nonce

Sound good.

> 
>>
>>       SHA-256 (EK Public Key | SRK Public Key) copied to SNP
>>       MSG_REPORT_REQ:REPORT_DATA[255:0].
>>
>>       On success, the report is present at Report Destination GPA.
>>
>>       If a new way of creating REPORT_DATA is needed in the future, 
>> the
>>       protocol could be extended with a new attestation report 
>> function
>>       (following the SVSM Core Protocol design of being additive).
> 
> 
> It's just a bit weird that the SNP attestation report function is part 
> of the vTPM protocol; but I guess that it is needed so we can 
> distinguish it from other future types of attestation reports (with 
> James's suggested "type" byte, which must never be user-controlled; it 
> must be set inside the SVSM).
> 
> 
> 
> Hmm, do we need also something like SNP_GET_EXT_REPORT which also 
> returns the cert-chain stored in the host kernel? Or modify this call 
> to also return the certs?

Yes, good catch. I believe we do. Adding two more parameters (maybe change this to a struct now?) for Cert Data GPA and Cert Data size is the way to go. We want the Cert Data that is associated with the attestation report that was generated, in an "atomic" way. Once live migration is available, the VM could theoretically be migrated in between two functions calls and then the VCEK wouldn't match.

Thanks,
Tom

> 
> 
> 
>>
>>    2. A vTPM operation function
>>       - Input:
>>           - Command GPA (RCX)
>>           - Command size (RDX)
>>           - Response GPA (R8)
>>           - Response size (R9)
>>       - Output:
>>           - Result code (RAX)
>>
>>       On success, the result is present at Response GPA.
>>
>>       @James Bottomley, I noticed in an earlier response that you had 
>> the
>>       Response size as a possible output, is that needed? The 
>> response
>>       output (header) contains the actual length of the response.
>>
>> Are there any other functions that are needed?
>>
> 
> Looks good to me.  I think this is what we have in our prototype as well.
> 
> (But see my thought about equivalent of SNP_GET_EXT_REPORT.)
> 
> -Dov

Re: SVSM vTPM specification

[James Bottomley]

On Wed, 2022-10-19 at 15:14 -0700, Dionna Amalie Glaze wrote:
> > > Hmm, do we need also something like SNP_GET_EXT_REPORT which also
> > > returns the cert-chain stored in the host kernel? Or modify this
> > > call to also return the certs?
> > 
> > Yes, good catch. I believe we do. Adding two more parameters (maybe
> > change this to a struct now?) for Cert Data GPA and Cert Data size
> > is the way to go. We want the Cert Data that is associated with the
> > attestation report that was generated, in an "atomic" way. Once
> > live migration is available, the VM could theoretically be migrated
> > in between two functions calls and then the VCEK wouldn't match.
> > 
> > Thanks,
> > Tom
> > 
> 
> I thought that TPM2_EC_Emphemeral would get the EC public key and
> Tspi_Key_GetPubKey could be used to get the SRK public key.

I don't think I really follow this at all.  Tspi_ was the old Trousers
(TPM 1.2) TSS API and TPM2_EC_Ephemeral is used to generate a random EC
key for use in the two phase commit protocol for doing ECDH.

>  I might be mistaken, but I believe the TPM has commands for this
> already, so the vTPM protocol doesn't need an extra entrypoint. The
> TPM keys shouldn't change through live migration, so querying
> separately should work.

The keys/certificates being referred to above quote are the PSP chip
signing keys used to sign the attestation report.  They do change if
the VM+SVSM is migrated to a new host.  The vTPM will go with the VM so
its seeds will remain the same, but the attestation report binding the
SVSM to the vTPM will change signing keys.

James

RE: SVSM vTPM specification

[James Bottomley]

On Thu, 2022-10-20 at 19:58 +0000, David Altobelli wrote:
> From: Steve Rutherford <srutherford@google.com>
> 
> > I'm a little leary of JSON in the SVSM. My fears of JSON parsers in
> > high trust tools might be unfounded though. Broadly speaking, the
> > idea of having something that contains what was >hashed would be
> > nice for future proofing. Having flexibility in which keys/data are
> > hashed into the report seems wise.
> I'm partial to JSON, but any format would do.  If parsing is
> problematic, outputting JSON data doesn't actually require parsing,
> it's just formatting some strings.

I too would prefer a format whose hash doesn't depend on how you
canonicalize it.

> > Separately, it's not clear to me why we need to attest to the SRK.
> > My understanding was that it was primarily used locally, and that
> > attestation was the job of the endorsement hierarchy. >Once you
> > have an EK, you can go through the necessary motions to certify the
> > SRK. That said, I can imagine wanting the hash of a standardized
> > AKpub to simplify those flows.
> Agree on not needing SRK, and AKpub (or AIKpub) being
> interesting.  Maybe there are some core claims that every
> implementation would want to offer, along with whatever optional
> claims improve their scenario?

Getting a TPM to certify a SRK given EKpub isn't simple.  You have to
create an AK in the TPM; do a make credential/activate credential round
trip on the AK to verify it against EKpub and then use the AK to
certify the SRK.  We could short circuit this if the EK were a signing
key ... then it would be able directly to certify the SRK.

James

RE: [EXTERNAL] RE: SVSM vTPM specification

[Jon Lange]

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?

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.

-Jon

-----Original Message-----
From: AMD-SEV-SNP <amd-sev-snp-bounces+jlange=microsoft.com@lists.suse.com> On Behalf Of James Bottomley
Sent: Thursday, October 20, 2022 1:30 PM
To: 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 Thu, 2022-10-20 at 19:58 +0000, David Altobelli wrote:
> From: Steve Rutherford <srutherford@google.com>
> 
> > I'm a little leary of JSON in the SVSM. My fears of JSON parsers in
> > high trust tools might be unfounded though. Broadly speaking, the
> > idea of having something that contains what was >hashed would be
> > nice for future proofing. Having flexibility in which keys/data are
> > hashed into the report seems wise.
> I'm partial to JSON, but any format would do.  If parsing is
> problematic, outputting JSON data doesn't actually require parsing,
> it's just formatting some strings.

I too would prefer a format whose hash doesn't depend on how you
canonicalize it.

> > Separately, it's not clear to me why we need to attest to the SRK.
> > My understanding was that it was primarily used locally, and that
> > attestation was the job of the endorsement hierarchy. >Once you
> > have an EK, you can go through the necessary motions to certify the
> > SRK. That said, I can imagine wanting the hash of a standardized
> > AKpub to simplify those flows.
> Agree on not needing SRK, and AKpub (or AIKpub) being
> interesting.  Maybe there are some core claims that every
> implementation would want to offer, along with whatever optional
> claims improve their scenario?

Getting a TPM to certify a SRK given EKpub isn't simple.  You have to
create an AK in the TPM; do a make credential/activate credential round
trip on the AK to verify it against EKpub and then use the AK to
certify the SRK.  We could short circuit this if the EK were a signing
key ... then it would be able directly to certify the SRK.

James

Re: SVSM vTPM specification

[Daniel P. Smith]

On 10/16/22 12:44, James Bottomley wrote:
> On Sun, 2022-10-16 at 12:29 -0400, Daniel P. Smith wrote:
>> If enlightened guest/driver is acceptable, then why not adopt the
>> pv-vTPM protocol, Xen's vTPM driver, for which there is already a
>> driver present in the kernel, was designed for deep attestation, and
>> does not inhibit/block features such as locality?
> 
> Erm, because it requires the Xen bus for discovery and communication
> ... the KVM people might not be so keen on adding that.  The other
> problem, even if we were to write a virtio equivalent (which KVM
> doesn't have today because it relies on TIS or CRB emulations), is that
> for all these virtual drivers, the back endpoint is in the host and we
> want to terminate it in the SVSM, which is the guest.

This is why I stated protocol and not transport. The Xen paravirt vTPM 
protocol is designed to go over a shared memory buffer using a doorbell 
notification, ie the transport mechanism under consideration. In 
addition the protocol defined a series of non-standard TPM command 
ordinals to interact with vTPM, more to deal with deep attestation. This 
approach could be leverage to access localities instead of trying to 
mimic a capability designed more for register access using a doorbell 
which introduces the possibility of synchronicity issues. This work 
could then serve as a basis for a "Enlightened" vTPM TCG specification 
to enable cross-implementation compatibility.

> To be clear, the current KVM drivers do emulate localites, it's just
> that they're unused by the OS and Firmware.  If you look at the TPM
> emulators themselves, they have the concept of locality, but when they
> need it, they indirect via an additional platform call (in the ms-tpm,
> which the current IBM prototype uses, it's a stubbed call to
> __plat__LocalityGet/Set) ... the locality isn't provided as part of the
> main TPM command processor, which is why we don't need to worry about
> it in the initial prototype.  That means if anyone ever does figure out
> how to do dynamic launch for virtual machines, and requires localities,
> we can simply add handlers for the stub routines.

Just as a last little 2₵, I would just highlight that the Mobile CRB 
committee likely never considered that mobile processors like Arm would 
add a dynamic launch capability that would require the usage of 
localities. Yet today Arm now has a DRTM specification which is trying 
to deal with the fact that the Mobile CRB specification has no locality 
support. Sometimes making adjustments with forethought over expediency 
will save a lot of pain, like having to come up with migrations plans 
with minimal disruptions to customers because wholesale replacement of a 
solution becomes necessary for something that was known/raised at the 
beginning.

v/r,
dps

Re: SVSM vTPM specification

[James Bottomley]

On Fri, 2022-10-21 at 07:54 -0400, Daniel P. Smith wrote:
> 
> On 10/16/22 12:44, James Bottomley wrote:
> > On Sun, 2022-10-16 at 12:29 -0400, Daniel P. Smith wrote:
> > > If enlightened guest/driver is acceptable, then why not adopt the
> > > pv-vTPM protocol, Xen's vTPM driver, for which there is already a
> > > driver present in the kernel, was designed for deep attestation,
> > > and does not inhibit/block features such as locality?
> > 
> > Erm, because it requires the Xen bus for discovery and
> > communication ... the KVM people might not be so keen on adding
> > that.  The other problem, even if we were to write a virtio
> > equivalent (which KVM doesn't have today because it relies on TIS
> > or CRB emulations), is that for all these virtual drivers, the back
> > endpoint is in the host and we want to terminate it in the SVSM,
> > which is the guest.
> 
> This is why I stated protocol and not transport. The Xen paravirt
> vTPM protocol is designed to go over a shared memory buffer using a
> doorbell notification, ie the transport mechanism under
> consideration. In addition the protocol defined a series of non-
> standard TPM command ordinals to interact with vTPM, more to deal
> with deep attestation. This approach could be leverage to access
> localities instead of trying to mimic a capability designed more for
> register access using a doorbell  which introduces the possibility of
> synchronicity issues. This work could then serve as a basis for a
> "Enlightened" vTPM TCG specification to enable cross-implementation
> compatibility.

The question under consideration was whether we could get an efficient
virtual TPM implementation for free (as in attach to an existing
driver).  The blocker to this for xen-tpmfront is the xenbus discovery.
If we're writing a new driver, we might as well do one that simply
attaches to the SVSM single call interface.  Since the CPU thread
passes into the VTPM and then returns with the result.  There's also no
current need to define non-standard ordinals, but if a need arises
nothing prevents layering them after the fact since they go down this
call interface.  This same is true of localities.  Since the locality
has to be deduced by the vTPM depending on environmental and physical
input nothing prevents them from being layered in later (when someone
figures out how to do localities in VMs).

> > To be clear, the current KVM drivers do emulate localites, it's
> > just that they're unused by the OS and Firmware.  If you look at
> > the TPM emulators themselves, they have the concept of locality,
> > but when they need it, they indirect via an additional platform
> > call (in the ms-tpm, which the current IBM prototype uses, it's a
> > stubbed call to __plat__LocalityGet/Set) ... the locality isn't
> > provided as part of the main TPM command processor, which is why we
> > don't need to worry about it in the initial prototype.  That means
> > if anyone ever does figure out how to do dynamic launch for virtual
> > machines, and requires localities, we can simply add handlers for
> > the stub routines.
> 
> Just as a last little 2₵, I would just highlight that the Mobile CRB 
> committee likely never considered that mobile processors like Arm
> would add a dynamic launch capability that would require the usage
> of localities. Yet today Arm now has a DRTM specification which is
> trying to deal with the fact that the Mobile CRB specification has no
> locality support. Sometimes making adjustments with forethought over
> expediency will save a lot of pain, like having to come up with
> migrations plans with minimal disruptions to customers because
> wholesale replacement of a solution becomes necessary for something
> that was known/raised at the  beginning.

The point of doing a CRB interface (if we do one) is to allow
attachment to an existing driver without too much trap overhead.  The
CRB interface is the one that fits this bill in the current linux
driver form regardless of what the design committee were or weren't
thinking.

You've studiously avoided sketching out what a dynamic launch might
look like for a confidential VM, but I'd have to guess it would be
facilitated and measured by the SVSM itself, being the trusted element.
Following this logic, anything written to the PCRs by the SVSM itself
would occur at a different locality from anything written through the
SVSM call interface ... the net result being only the SVSM could
control the privileged locality for the DRTM.  This would all work
regardless of the vagaries of the emulation presented beyond the SVSM.

James

RE: SVSM vTPM specification

[James Bottomley]

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

RE: [EXTERNAL] RE: SVSM vTPM specification

[Jon Lange]

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.

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?

-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

RE: SVSM vTPM specification

[James Bottomley]

On Fri, 2022-10-21 at 16:31 +0000, Jon Lange 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.

Actually, it doesn't.  Nothing prevents a particular type being
multiplexed (although if that happens the report for this particular
type is no-longer self describing).

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

If this becomes a future problem, we can by all means define a
multiplexed type.  However, absent knowledge that it is a real problem,
I'd like to begin with a simply defined format for the vTPM report plus
room for expansion (the type prefix).

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

To my way of thinking, the attestation report proves the binding of a
given vTPM to the SVSM of a given confidential enclave.  I believe this
is required before any relying party can use the TPM and rely on its
measurements. 


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

I think ideally the vTPM should behave like a real TPM.  I agree we
could use extension commands to multiplex SVSM commands over the TPM
interface, but then the standardisation question becomes how?  We could
elect to document these commands in the SVSM interface and hope no-one
tramples on them or go to the TCG and hope to standardise them that
way, but the easiest thing to do is to use the SVSM document to
standardise an SVSM interface to this instead of a TPM one.  Providing
a SVSM interface doesn't preclude providing a TCG extension interface,
so if it's useful (say TDX comes on board) then we can do it later
after we've proven the value with the SVSM interface.

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

A TPM certificate can only be trusted if you trust the manufacturing
process of the TPM.  This is fairly well defined for physical TPMs and
known (and regulated) manufacturers, but doesn't really work for pure
software TPMs.

>   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?

An Ephemeral vTPM: the SNP PreAttestation report confirms the code for
the SVSM and OVMF, so you need the OVMF measurements to prove the
kernel, inird and command line and the optional runtime measurements. 
If we get this right the vTPM will provide those measurement, but as a
pre-requisite to relying on those measurements, you need proof that the
vTPM you're relying on is the one within your confidential envelope. 
That's what the report provides by confirming the EK of the ephemeral
vTPM.

James

RE: [EXTERNAL] RE: SVSM vTPM specification

[Jon Lange]

My concern with the approach of starting with a single-use type and defining a multiplexed type in the future is that when the definition arrives in the future, all existing parsers will break when they see it being used.  As much as we will advocate an update in the parsing logic at the time, there will inevitably be some consumers that cry foul and demand that vTPM reports continue to follow the old format so that no parsers break.  This constraint would, in practice, relegate vTPM reports to be singleton for an extended period of time.  Knowing we have this future in front of us, I would strongly advocate that, at a minimum, we define a report format that supports the inclusion of both vTPM data and "other stuff", where the format of "other stuff" is defined in the future whenever we need it - but at least defining the potential inclusion today means that first-generation parsers will be prepared to ignore it when multiplexed reports start showing up down the road.

I support your proposal to use the SNP report as a root of trust to certify the vTPM keys.  This approach neatly avoids all of the problems associated with requiring some other certifying authority to bless vTPM keys.

I think everyone is likely to agree that the vTPM should act like a real TPM, and that the commands supported by a vTPM should match the command set defined by TCG.  What I am suggesting here is that the SVSM protocol need not be restricted to exactly the TCG-defined command set, if the extensions involve concepts that are specific to SNP or the SVSM.  Asking for an SNP report to bless the vTPM's state is not a TCG concept.  Similarly, other calls issued to the SVSM to obtain assurance about the path to the vTPM are specific to the SVSM concept and not necessarily related to TCG.  And when it comes to the guest determine whether it can trust the vTPM, don't forget that the SVSM is necessarily within the trust boundary of the guest because the SVSM calling convention does not permit inspection or modification by outside entities (input and output parameters lie with the gPA space of the guest which is only accessible within the guest's trust boundary).  If the SVSM protocol were to define an action to obtain a TPM endorsement key, or other TPM certifying information, the response would be known to be trustworthy because there is no path that could interfere with that delivery.  This means that a guest doesn't need to rely on an SNP report to know whether its vTPM is trustworthy.  An external relying party would need such a report so that it can ensure that the SVSM, vTPM, and other TCB state is authentic, but the guest can trust the SVSM and its operation implicitly.

-Jon


-----Original Message-----
From: James Bottomley <jejb@linux.ibm.com> 
Sent: Friday, October 21, 2022 8:20 PM
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 16:31 +0000, Jon Lange 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.

Actually, it doesn't.  Nothing prevents a particular type being
multiplexed (although if that happens the report for this particular
type is no-longer self describing).

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

If this becomes a future problem, we can by all means define a
multiplexed type.  However, absent knowledge that it is a real problem,
I'd like to begin with a simply defined format for the vTPM report plus
room for expansion (the type prefix).

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

To my way of thinking, the attestation report proves the binding of a
given vTPM to the SVSM of a given confidential enclave.  I believe this
is required before any relying party can use the TPM and rely on its
measurements. 


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

I think ideally the vTPM should behave like a real TPM.  I agree we
could use extension commands to multiplex SVSM commands over the TPM
interface, but then the standardisation question becomes how?  We could
elect to document these commands in the SVSM interface and hope no-one
tramples on them or go to the TCG and hope to standardise them that
way, but the easiest thing to do is to use the SVSM document to
standardise an SVSM interface to this instead of a TPM one.  Providing
a SVSM interface doesn't preclude providing a TCG extension interface,
so if it's useful (say TDX comes on board) then we can do it later
after we've proven the value with the SVSM interface.

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

A TPM certificate can only be trusted if you trust the manufacturing
process of the TPM.  This is fairly well defined for physical TPMs and
known (and regulated) manufacturers, but doesn't really work for pure
software TPMs.

>   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?

An Ephemeral vTPM: the SNP PreAttestation report confirms the code for
the SVSM and OVMF, so you need the OVMF measurements to prove the
kernel, inird and command line and the optional runtime measurements. 
If we get this right the vTPM will provide those measurement, but as a
pre-requisite to relying on those measurements, you need proof that the
vTPM you're relying on is the one within your confidential envelope. 
That's what the report provides by confirming the EK of the ephemeral
vTPM.

James

Re: [EXTERNAL] RE: SVSM vTPM specification

[Dr. David Alan Gilbert]

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

> 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
> 
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

RE: SVSM vTPM specification

[Dov Murik]

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.


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


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

Re: SVSM vTPM specification

[Tom Lendacky]

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?

> 
> 
> (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
>>>
>>>
> 

Re: SVSM vTPM specification

[Dionna Amalie Glaze]

> 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?
>

CBOR is used for this kind of purpose in Nitro enclaves, the Open DICE
profile, and the CoRIM standard from IETF uses CBOR for representing
SBOM-kinds of things.

-- 
-Dionna Glaze, PhD (she/her)

Re: SVSM vTPM specification

[Dov Murik]

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

Re: SVSM vTPM specification

[Christophe de Dinechin]

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?

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.

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.

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.


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


--
Cheers,
Christophe de Dinechin (https://c3d.github.io)
Theory of Incomplete Measurements (https://c3d.github.io/TIM)

Re: SVSM vTPM specification

[Tom Lendacky]

On 10/25/22 04:43, 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?
> 
> 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.
> 
> 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.
> 
> 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.

Agreed.

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

That is my understanding as well.

>>
>> 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"
>>    }
>> }

I was thinking that the guest would request the attestation report with 
the data it wants, e.g., just vTPM data. IIUC, you're thinking the output 
document would be everything the SVSM knows about from an attestation 
point of view.

In the above version, while the vTPM data would be pretty static, some of 
the other data could change and, given the same nonce, you could get 
different hashes. I guess it doesn't matter as long as you can take the 
output data and validate the hash and then extract the data you want.

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

And I guess as long as the output document is provided that can be 
verified against the hash, then canonicalizing of the JSON is really not 
needed.

Thanks,
Tom

>>
>>
>> -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
>>>>>>
>>>>>>
>>>>
> 
> 
> --
> Cheers,
> Christophe de Dinechin (https://c3d.github.io/)
> Theory of Incomplete Measurements (https://c3d.github.io/TIM)
> 

Re: SVSM vTPM specification

[James Bottomley]

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

Re: SVSM vTPM specification

[Steve Rutherford]

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

Re: SVSM vTPM specification

[James Bottomley]

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