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

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

On 10/6/25 21:59, James Bottomley wrote:
> On Mon, 2025-10-06 at 12:56 -0500, Tom Lendacky wrote:
>> 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 Linux we have kexec reboot, which doesn't reset the TPM, it merely
> carries the logs across without resetting the PCRs, even though the
> guest gets relaunched.
> 
>>> 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?"
> 
> This was discussed in the referenced issue.  What I said then was:
> 
> ---
> In theory, yes, but it depends on the mechanism.  What we'd discussed
> before was making OVMF responsible for the SVSM measurement log, so we
> could simply do additional TCG measurements into standard PCRs and they
> would automatically be part of remote verification and the SVSM
> wouldn't need to keep the log.  Now we'd actually have to keep that log
> inside the SVSM as well to do the replay.
> 
> There's also a security point: just in time measurements into a non-
> repudiable store have well known and hard to influence properties i.e.
> very little attack surface.  If we do the above the security properties
> alter (the initial measurements are potentially no longer just in time,
> so the auditability becomes more suspect) and the SVSM log store itself
> now becomes part of the attack surface, which is quite a huge
> expansion.
> ---
> 
> I really think the kexec model where the TPM PCRs don't reset and the
> log carries over is the correct one.  And, as Jon pointed out, it would
> also work in RTMR environments which can't be reset without a full VM
> reboot anyway.

I really don't want to delay the release of the next version of the SVSM
spec. While this is all being discussed and worked out, I'll just remove
the the Reboot protocol at this point so that the Core protocol update,
vTPM protocol update and the new APIC emulation protocol and UEFI MM
protocol can get finalized and published.

Thanks,
Tom

> 
> Regards,
> 
> James
>