Re: [PATCH v2] docs: security: Confidential computing intro and threat model for x86 virtualization

[Dmytro Maluka]

On 6/16/23 15:56, Sean Christopherson wrote:
> 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:
>>>>>> +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.

Heh, no. Most of these resources are owned by the untrusted host, that's
the point.

Basically for two reasons: 1. we want to keep the trusted hypervisor as
simple as possible. 2. we don't need availability guarantees.

The trusted hypervisor owns only: 2nd-stage MMU, IOMMU, VMCS (or its
counterparts on non-Intel), physical PCI config space (merely for
controlling a few critical registers like BARs and MSI address
registers), perhaps a few more things that don't come to my mind now.

The untrusted host schedules its guests on physical CPUs (i.e. the
host's L1 vCPUs are 1:1 mapped onto pCPUs), while the trusted hypervisor
has no scheduling, it only handles vmexits from the host and guests. The
untrusted host fully controls the physical interrupt controllers (I
think we realize that is not perfectly fine, but here we are), etc.
 
> 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.