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

["Relph, Richard" <Richard.Relph@amd.com>]

Nicolai,
    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. 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.
    For now, we can mandate that the reset command does not alter or modify TPM state in any way 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.
Richard

> On Oct 4, 2025, at 6:19 AM, Nicolai Stange <nstange@suse.de> wrote:
> 
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> 
> 
> Hi Tom,
> 
> Tom Lendacky <thomas.lendacky@amd.com> writes:
> 
>> Attached is the next version of the draft SVSM specification with the
>> following changes since the previous version:
>> 
>>  - APIC emulation protocol added
>>    - Coconut-SVSM will need to be audited, as the current APIC emulation
>>      code does not completely match the "Alternate Injection Support"
>>      specification on which this protocol is based.
>>  - Reboot protocol added
> 
> there's an ongoing discussion at GH ([1]) on how a reboot should
> interact with the _TPM_Init (think an emulated TPM power cycle) and that
> should probably get resolved before making the spec update effective.
> 
> I'm trying my best to summarize the problem in what follows, James
> (CCed) might have some additional input.
> 
> So, naively, a cold reset of the firmware, which qualifies as a reset of
> what's called the "Root of Trust for Measurement" (RTM) in TCG
> terminology, would require a reset of the TPM, i.e. to make it enter the
> _TPM_Init state, c.f. the TCG TPM 2.0 Library v184, part 1
> ("Architecture"), sec. 10.2.2 ("Initialization State"). Quote: "It
> should not be possible to reset the TPM without resetting the RTM. It
> should not be possible to reset the RTM without resetting the TPM."
> 
> In particular, a reset of the TPM causes a reinitialization of all PCRs
> to their respective default values as defined in the platform profile
> (constant all-zeroes or all-ones in most cases).
> 
> At the current stage of the SVSM development, that's fine and could
> easily get implemented.
> 
> However, James remarked in the course of the linked GH discussion that
> establishing such semantics now would prohibit us from letting the SVSM
> measure dynamic parts + configuration of itself into the TPM PCRs in the
> future. IIUC, the idea is to record standard TCG events capturing the
> dynamic aspects of the SVSM into the firmware's PCR-measured eventlog
> (for the firmware event log c.f. [2], EFI_TCG2_PROTOCOL.GetEventLog),
> which is quite appealing, because it would integrate transparently with
> existing workflows and tools like `tpm2_eventlog` etc..
> 
> So assuming we do not want to preclude the implementation of something
> like that in the future, the question is how to define interactions with
> the new `SVSM_REBOOT_EXECUTE` protocol command.
> 
> From a high-level, AFAICT, we probably would have to
> a.) Convey all or a subsequence of the eventlog to the relaunched
>    firmware. If a subsequence, then that would have to contain all TCG
>    event records relevant to the SVSM's self-measurements.
> b.) Either do a "partial" TPM reset, making it to re-enter _TPM_Init,
>    but keep some subset of PCRs (*) at their current values in case the
>    full event log is conveyed, or do a full TPM reset and issue initial
>    PCR extends from the SVSM corresponding to the to be conveyed log in
>    case of a proper subsequence.
> 
> The "relevant log subsequence" option is technically feasible in theory,
> but would require the SVSM to keep a log of its own events for the
> replay at firmware relaunch. James, who entered the GH discussion with a
> suggestion to hand the full log over with some mechanism resembling the
> one from Linux kexec warm reboots, later on mentioned some drawbacks
> with the approach of having the SVSM replay an internally stored log at
> firmware relaunch, please refer to [1] for details.
> 
> I myself don't have an opinion on the topic, but as a hand-over
> mechanism for the TCG event log would likely require support from the
> newly proposed `SVSM_REBOOT_EXECUTE` command, I wanted to make you aware
> of the pending discussion.
> 
> Thanks!
> 
> Nicolai
> 
> [1] https://github.com/coconut-svsm/svsm/pull/808#issuecomment-3361113788
> [2] https://trustedcomputinggroup.org/resource/tcg-efi-protocol-specification/
> 
> (*) Which one is not clear to me yet -- the obvious candidate is PCR[0]
>    and possibly some more, but there might be interactions with the
>    H-CRTM semantics, which require to initialize the PCR[0] differently
>    depending on whether the firmware issued a H-CRTM measurement
>    sequence before invoking TPM2_Startup() or not, c.f. TCG TPM 2.0
>    Library v184, part 1, ("Architecture"), sec. 32.3 ("H-CRTM before
>    TPM2_Startup() and TPM2_Startup() without H-CRTM").
> 
>> Please review. If there are no or only minor comments, this draft will
>> become the next version of the specification.
> 
> --
> SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany
> GF: Ivo Totev, Andrew McDonald, Werner Knoblich
> (HRB 36809, AG Nürnberg)