On 6/16/23 16:20, Sean Christopherson wrote: > On Fri, Jun 16, 2023, Dmytro Maluka wrote: >> On 6/13/23 19:03, Sean Christopherson wrote: >>> On Mon, Jun 12, 2023, Carlos Bilbao wrote: >>>> +well as CoCo technology specific hypercalls, if present. Additionally, the >>>> +host in a CoCo system typically controls the process of creating a CoCo >>>> +guest: it has a method to load into a guest the firmware and bootloader >>>> +images, the kernel image together with the kernel command line. All of this >>>> +data should also be considered untrusted until its integrity and >>>> +authenticity is established via attestation. >>> >>> Attestation is SNP and TDX specific. AIUI, none of SEV, SEV-ES, or pKVM (which >>> doesn't even really exist on x86 yet), have attestation of their own, e.g. the >>> proposed pKVM support would rely on Secure Boot of the original "full" host kernel. >> >> Seems to be a bit of misunderstanding here. Secure Boot verifies the >> host kernel, which is indeed also important, since the pKVM hypervisor >> is a part of the host kernel image. But when it comes to verifying the >> guests, it's a different story: a protected pKVM guest is started by the >> (untrusted) host at an arbitrary moment in time, not before the early >> kernel deprivileging when the host is still considered trusted. >> (Moreover, in practice the guest is started by a userspace VMM, i.e. not >> exactly the most trusted part of the host stack.) So the host can >> maliciously or mistakenly load a wrong guest image for running as a >> protected guest, so we do need attestation for protected guests. >> >> This attestation is not implemented in pKVM on x86 yet (you are right >> that pKVM on x86 is little more than a proposal at this point). But in >> pKVM on ARM it is afaik already working, it is software based (ensured >> by pKVM hypervisor + a tiny generic guest bootloader which verifies the >> guest image before jumping to the guest) and architecture-independent, >> so it should be possible to adopt it for x86 as is. > > Sorry, instead of "Attestation is SNP and TDX specific", I should have said, "The > form of attestation described here is SNP and TDX specific". > > pKVM's "attestation", effectively has its root of trust in the pKVM hypervisor, > which is in turn attested via Secure Boot. I.e. the guest payload is verified > *before* it is launched. Got it, fair point. Yep, I think this understanding is fully correct. > That is different from SNP and TDX where guest code and data is controlled by the > *untrusted* host. The initial payload is measured by trusted firmware, but it is > not verified, and so that measurement must be attested after the guest boots, > before any sensitive data is provisioned to the guest. > > Specifically, with "untrusted" inserted by me for clarification, my understanding > is that this doesn't hold true for pKVM when splitting hairs: > > Additionally, the **untrusted** host in a CoCo system typically controls the > process of creating a CoCo guest: it has a method to load into a guest the > firmware and bootloader images, the kernel image together with the kernel > command line. All of this data should also be considered untrusted until its > integrity and authenticity is established via attestation. > > because the guest firmware comes from a trusted entity, not the untrusted host.
