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

[Tom Lendacky <thomas.lendacky@amd.com>]

On 10/4/25 06:19, Nicolai Stange wrote:
> 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."

Right, the base idea of a reboot would be that everything should appear
as if the guest was re-launched.

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

Yes.

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

Couldn't that be replayed by the SVSM into the TPM on "reboot?"

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

Maybe we need a QUERY command to determine if REBOOT is possible then.
If we add/have dynamic measurements but they can't be replayed back into
the TPM to present a "fresh" boot environment, then the QUERY command
returns an indicator that REBOOT is not possible.

Thoughts?

Thanks,
Tom

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