On Fri, Jun 16, 2023, Dmytro Maluka wrote: > On 6/14/23 16:15, Sean Christopherson wrote: > > On Wed, Jun 14, 2023, Elena Reshetova wrote: > >> Not having a network access requirement doesn’t implicitly invalidate the > >> separation guarantees between the host and guest, it just makes it easier > >> since you have one interface less between the host and guest. > > > > My point is that if the protected guest doesn't need any I/O beyond the hardware > > device that it accesses, then the threat model is different because many of the > > new/novel attack surfaces that come with the TDX/SNP threat model don't exist. > > E.g. the hardening that people want to do for VirtIO drivers may not be at all > > relevant to pKVM. ... > But I think I get what you mean: there is no data transfer whereby the > host is not an endpoint but an intermediary between the guest and some > device. In simple words, things like virtio-net or virtio-blk are out of > scope. Yes, I think that's correct for pKVM-on-x86 use cases (and I > suppose it is correct for pKVM-on-ARM use cases as well). I guess it > means that "guest data attacks" may not be relevant to pKVM, and perhaps > this makes its threat model substantially different from cloud use > cases. Yes. > >>>> +This new type of adversary may be viewed as a more powerful type > >>>> +of external attacker, as it resides locally on the same physical machine > >>>> +-in contrast to a remote network attacker- and has control over the guest > >>>> +kernel communication with most of the HW:: > >>> > >>> IIUC, this last statement doesn't hold true for the pKVM on x86 use case, which > >>> specifically aims to give a "guest" exclusive access to hardware resources. > >> > >> Does it hold for *all* HW resources? If yes, indeed this would make pKVM on > >> x86 considerably different. > > > > Heh, the original says "most", so it doesn't have to hold for all hardware resources, > > just a simple majority. > > Again, pedantic mode on, I find it difficult to agree with the wording > that the guest owns "most of" the HW resources it uses. It controls the > data communication with its hardware device, but other resources (e.g. > CPU time, interrupts, timers, PCI config space, ACPI) are owned by the > host and virtualized by it for the guest. I wasn't saying that the guest owns most resources, I was saying that the *untrusted* host does *not* own most resources that are exposed to the guest. My understanding is that everything in your list is owned by the trusted hypervisor in the pKVM model. What I was pointing out is related to the above discussion about the guest needing access to hardware that is effectively owned by the untrusted host, e.g. network access.
