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

All,
  After chatting with Tom some, I’d like to restate the issues as I see them.
  My background is deeply embedded systems, notably in this context, PSP FW for the various flavors of SEV through the Genoa generation, and this is my first foray in to writing code for Linux, EDK2, or SVSM. And in Rust. So I claim ZERO expertise here.

   I was asked to enhance SVSM with a capability to “reboot” the VMPL 2 guest, without exiting QEMU, and without relying on kexec(). We discussed this, briefly, in some Coconut-SVSM meetings in the April and May time frame.

   For purposes of this work, and this discussion, I make the following assumptions about the use case for a reboot command:
   The reason for not wanting to exit QEMU is to maintain control of the resources allocated to QEMU… vCPUs, memory, what have you. Exiting QEMU would release those resources and who knows what might happen if that happens. Plus, of course, the time to re-acquire all the desired resources upon restarting QEMU would add, potentially significantly, to reboot time.
   The reason for not wanting to use kexec() could be to change some setting in the BIOS or boot a different OS.

    Exiting - for any reason - and re-starting QEMU would reset QEMU's vTPM. QEMU’s vTPM state can be persisted across reboots in a host file, but the vTPM itself undergoes something like a HW TPM’s power on reset each time QEMU starts. I don’t know how SVSM’s vTPM implementation models a persistent vTPM, though I assume it can. QEMU also offers the ability to NOT persist its vTPM across QEMU invocations. And however SVSM’s vTPM models a persistent vTPM, it, like a HW TPM, must be able to survive an asynchronous power cycle, even of the host. So providing a REBOOT mechanism in SVSM that also resets the vTPM, whether persistent or not, is definitely “in scope” as I see it. Whatever other REBOOT modes might be desired, this one seems necessary to me.

    If you disagree, please help me understand what I’m missing.

    The draft 1.01 spec comprehends something like this behavior. It doesn’t say what happens to guest state, including the vTPM, when a REBOOT_EXECUTE command is sent. I agree that needs to be clarified. The intent is that the system state be whatever it would be if the system-wide reset line had been asserted.

   James has put forth another reboot mode… one that, as I understand it, propagates the vTPM event log from Linux, through SVSM, to OVMF, offering kexec()-like functionality in terms of vTPM log maintenance. But kexec() doesn’t go through SVSM or OVMF at all. While I see some value in doing this, it seems to me a significantly different behavior than the reboot I described above. And more importantly, it seems a much larger task, since - AFAIK - EDK2/OVMF has no notion of accepting a TPM event log. Getting that community to buy in to the need and then put forth the resources to specify and implement this seems a long shot to me.

   Given the value that some customers see in an SVSM-based reboot facility along the lines of a power cycle, I think it’s important to not delay the reboot facility until all the other spec-level features for vTPM event log propagation are in place. When those other dependencies are sufficiently resolved, we can extend the reboot protocol spec to include a new command.

   As for how code in SVSM, outside the reboot protocol code, gets ‘reset’, I think that is an implementation detail that need not delay the specification.

   Tom and I discussed augmenting the spec to include a reboot query capability so the VMPL 2 guest can discover what kinds of reboot, if any, are supported. I’m fine with that.

Richard