RE: [EXTERNAL] Re: SVSM draft specification (v1.01 draft #3)

Tom said something that concerns me greatly:

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

This is a great principle to state, but one that will almost certainly be unable to make correct in the way the guest expects.  Because the SVSM does not restart, any code in the SVSM that must return to the reset state must implement explicit code to do so.  We could certainly define some sort of subscription mechanism that permits each running service to be advised when a guest reboot occurs, but it's up to each service to implement it correctly.  Any service that fails to implement this correctly will violate the expectation of the guest.  If we had a bunch of existing code, it would be a lost cause to audit 100% of it and confirm that it conforms to the reboot expectations.  We have at least a fighting chance given that we have very little existing code, but declaring a requirement to new code to implement reboot correctly doesn't mean that it's reasonable - or even possible - for new code modules to do so.

On top of that, remember that one goal of the COCONUT-SVSM project is to provide cross-platform compatibility for any functionality that isn't coupled to a single architecture.  There's nothing about reboot that is inherently bound to SEV-SNP, so there will be an expectation that this can be supported on Intel TDX or Arm CCA.  Both of those architectures implement one-way extensible measurement registers, and I fully expect that in the future, the COCONUT-SVSM kernel will offer services to enable use of those measurement registers.  When such registers are used, it is impossible for the SVSM to return to a reset state because the underlying platform doesn't permit any rollback of measurement registers.  In fact, I wouldn't be surprised if AMD defines such registers in the future as well, so this may end up being a universal problem.  I don't know how to reconcile "appear as if the guest was re-launched" with one-way extensible measurements.

We are defining the reboot protocol as its own protocol, with the ability to define extensibility in any way we want.  I think we are going to be in a much better position if we define reboot this way: (a) executing reboot restarts the guest but has no effect by itself on any other SVSM state, (b) the reboot protocol is defined to offer extension points that permit other protocols to advertise whether they can participate in reboot, or whether their state persists across guest reboots, and (c) the guest must opt into service resets for the set of services that it expects to reset, which of course will be constrained by the set of services that support reset.  Such a design makes the operation of reboot entirely explicit, with no unpleasant surprises that arise because some SVSM service failed to implement reboot correctly - or failed to realize it was supposed to implement it at all.

-Jon

-----Original Message-----
From: Tom Lendacky <[email protected]> 
Sent: Monday, October 6, 2025 10:57 AM
To: Nicolai Stange <[email protected]>
Cc: [email protected]; [email protected]; Jon Lange <[email protected]>; [email protected]; Relph, Richard <[email protected]>; Rodel, Jorg <[email protected]>; Melody Wang <[email protected]>; James Bottomley <[email protected]>
Subject: [EXTERNAL] Re: SVSM draft specification (v1.01 draft #3)

On 10/4/25 06:19, Nicolai Stange wrote:
> Hi Tom,
> 
> Tom Lendacky <[email protected]> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fcoconut-svsm%2Fsvsm%2Fpull%2F808%23issuecomment-3361113788&da
> ta=05%7C02%7Cjlange%40microsoft.com%7C111c90c2ab2f460b823608de0501b85f
> %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638953702155666999%7CUnk
> nown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJ
> XaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6%2BQemUT
> nSthBlMW3HXDAkS%2BUkwBQMAjOhEQdZPsE5mo%3D&reserved=0
> [2] 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrus
> tedcomputinggroup.org%2Fresource%2Ftcg-efi-protocol-specification%2F&d
> ata=05%7C02%7Cjlange%40microsoft.com%7C111c90c2ab2f460b823608de0501b85
> f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638953702155682015%7CUn
> known%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi
> JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=WaLeG8dI
> QvXNaKB4Kvj%2BFedamG1XETV8SFj27u54ZE8%3D&reserved=0
> 
> (*) 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.
>