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

> On Oct 6, 2025, at 11:17 AM, Nicolai Stange <[email protected]> wrote:
> 
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> 
> 
> Hi Richard,
> 
> "Relph, Richard" <[email protected]> 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.

That’s my understanding of what James is proposing as well.

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

Right. Or simply add the _EX command and leave the existing “no data moved” command in place for those environments that want something more like a power off/on cycle (and backward compatibility.)

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

I note that TPM is an optional component of an SVSM build at this point.
And even if it is included, not everyone using SVSM may require or even want it.
The TCG mandates a *minimum* log size of 64K. I’ve seen a claim that IBM Power systems support a 64M log! Just how much space do we want to dedicate in SVSM for preserving the log across a reset of the guest?
Finally, there’s nothing preventing a guest OS from preserving the log in coordination with the rebooted guest BIOS without any involvement from SVSM whatsoever. There are other means for transporting the log than through the SVSM.

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

And I very much appreciate you summarizing that conversation for this wider list.

Thank you,
Richard

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