Re: SVSM draft specification (v1.01 draft #3)

[Nicolai Stange <nstange@suse.de>]

Hi Richard,

"Relph, Richard" <Richard.Relph@amd.com> writes:

>     I disagree with the premise “that establishing such semantics now
> would prohibit us” from doing anything whatsoever in the future. The
> new Reset command has flags.

just to make it explicit: AFAIU, flags are insufficient for implementing
an event log handover mechanism like James proposed. What would be
needed for that is a means to pass the event log from the guest into
`SVSM_REBOOT_EXECUTE` for handover to the relaunched guest. But granted,
given the current lack of any defined mechanism for injecting such an
eventlog back into the restarted guest again, it would be quite a task
to define all that coherently protocol-wise at this point.


> It’s in a completely separate, versioned protocol that can be extended
> with additional commands. Though the current spec says this command
> will live ‘forever’, I’m OK with having the protocol specify a minimum
> version that would, in the future, even permit this command to be
> unusable.

You mean like bumping the protocol version the day the SVSM wants to do
self-measurements into the TPM PCRs and say something along the lines of
"starting from version XY, `SVSM_REBOOT_EXECUTE` has become undefined,
please use `SVSM_REBOOT_EXECUTE_EX` instead"? Perhaps not ideal in terms
of future interoperability, but definitely fine as far as I'm concerned.


> For now, we can mandate that the reset command does not alter or
> modify TPM state in any way

The option to do nothing isn't really a good one IMO:
1.) The restarted guest would not be able to present a complete,
    verifiable event log for a remote attestation, because it's lacking
    the head part of what's been extended into the PCRs. That is, remote
    attestation of the restarted guest would be impossible (at least
    if supposed to cover the boot event log).
2.) There are potential security implications with e.g. a restarted
    "bad" guest continuing on the TPM state of a preceding "good" one.

> and leave it up to the VMPL 2 guest to decide what to do.
> Alternatively, we could specify that the command reset the TPM and
> RTM as if it were a power off/on cycle.  Or use one of the flag
> bits to differentiate between these 2 simple possibilities.

> Anything else seems like it would be unnecessarily complicated at
> this point in time.

Not for me to judge upon really, I merely wanted to give a heads-up that
there is a related discussion happening over at GH in the first place.

Thanks,

Nicolai

-- 
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany
GF: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)