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

[Nicolai Stange <nstange@suse.de>]

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)