Message-ID: <CAJzde04DSeVcMCVTN_3SFUVoKszL1YUbX9eHq6Y0QKtX16xCDA@mail.gmail.com>
Date:   Fri, 16 Jun 2023 10:16:03 -0500
From:   Allen Webb <allenwebb@...gle.com>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     Dmytro Maluka <dmy@...ihalf.com>,
        Elena Reshetova <elena.reshetova@...el.com>,
        Carlos Bilbao <carlos.bilbao@....com>,
        Jason CJ Chen <jason.cj.chen@...el.com>,
        "corbet@....net" <corbet@....net>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "ardb@...nel.org" <ardb@...nel.org>,
        "kraxel@...hat.com" <kraxel@...hat.com>,
        "dovmurik@...ux.ibm.com" <dovmurik@...ux.ibm.com>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "Dhaval.Giani@....com" <Dhaval.Giani@....com>,
        "michael.day@....com" <michael.day@....com>,
        "pavankumar.paluri@....com" <pavankumar.paluri@....com>,
        "David.Kaplan@....com" <David.Kaplan@....com>,
        "Reshma.Lal@....com" <Reshma.Lal@....com>,
        "Jeremy.Powell@....com" <Jeremy.Powell@....com>,
        "sathyanarayanan.kuppuswamy@...ux.intel.com" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        "alexander.shishkin@...ux.intel.com" 
        <alexander.shishkin@...ux.intel.com>,
        "thomas.lendacky@....com" <thomas.lendacky@....com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "dgilbert@...hat.com" <dgilbert@...hat.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "dinechin@...hat.com" <dinechin@...hat.com>,
        "linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
        "berrange@...hat.com" <berrange@...hat.com>,
        "mst@...hat.com" <mst@...hat.com>, "tytso@....edu" <tytso@....edu>,
        "jikos@...nel.org" <jikos@...nel.org>,
        "joro@...tes.org" <joro@...tes.org>,
        "leon@...nel.org" <leon@...nel.org>,
        "richard.weinberger@...il.com" <richard.weinberger@...il.com>,
        "lukas@...ner.de" <lukas@...ner.de>,
        "jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
        "cdupontd@...hat.com" <cdupontd@...hat.com>,
        "jasowang@...hat.com" <jasowang@...hat.com>,
        "sameo@...osinc.com" <sameo@...osinc.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "security@...nel.org" <security@...nel.org>,
        Larry Dewey <larry.dewey@....com>, android-kvm@...gle.com,
        Dmitry Torokhov <dtor@...gle.com>,
        Tomasz Nowicki <tn@...ihalf.com>,
        Grzegorz Jaszczyk <jaz@...ihalf.com>,
        Patryk Duda <pdk@...ihalf.com>
Subject: Re: [PATCH v2] docs: security: Confidential computing intro and
 threat model for x86 virtualization

On Fri, Jun 16, 2023 at 9:42 AM Sean Christopherson <seanjc@...gle.com> wrote:
>
> On Fri, Jun 16, 2023, Allen Webb wrote:
> > On Fri, Jun 16, 2023 at 8:56 AM Sean Christopherson <seanjc@...gle.com> 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.
> > >
> > > 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.
> >
> > The network case isn't a great example because it is common for user
> > space applications not to trust the network and to use verification
> > schemes like TLS where trust of the network is not required, so the
> > trusted guest could use these strategies when needed.
>
> There's a bit of context/history that isn't captured here.  The network being
> untrusted isn't new/novel in the SNP/TDX threat model, what's new is that the
> network *device* is untrusted.
>
> In the SNP/TDX world, the NIC is likely to be a synthetic, virtual device that is
> provided by the untrusted VMM.  Pre-SNP/TDX, input from the device, i.e. the VMM,
> is trusted; the guest still needs to use e.g. TLS to secure network traffic, but
> the device configuration and whatnot is fully trusted.  When the VMM is no longer
> trusted, the device itself is no longer trusted.
>
> To address that, the folks working on SNP and TDX started posting patches[1][2]
> to harden kernel drivers against bad device configurations and whanot, but without
> first getting community buy-in on this new threat model, which led us here[3].
>
> There is no equivalent in existing userspace applications, because userspace's
> memory is not private, i.e. the kernel doesn't need to do Iago attacks to compromise
> userspace, the kernel can simply read whatever memory it wants.
>
> And for pKVM, my understanding is that devices and configuration information that
> are exposed to the guest are trusted and/or verified in some way, i.e. the points
> of contention that led to this doc don't necessarily apply to the pKVM use case.

That extra context helps, so the hardening is on the side of the guest
kernel since the host kernel isn't trusted?

My biggest concerns would be around situations where devices have
memory access for things like DMA. In such cases the guest would need
to be protected from the devices so bounce buffers or some limited
shared memory might need to be set up to facilitate these devices
without breaking the goals of pKVM.

The minimum starting point for something like this would be a shared
memory region visible to both the guest and the host. Given that it
should be possible to build communication primitives on top, but yes
ideally something like vsock or virtio would just work without
introducing risk of exploitation and typically the hypervisor is
trusted. Maybe this could be modeled as sibling to sibling
virtio/vsock?

>
> [1] https://lore.kernel.org/linux-iommu/20210603004133.4079390-1-ak@linux.intel.com
> [2] https://lore.kernel.org/all/20230119170633.40944-1-alexander.shishkin@linux.intel.com
> [3] https://lore.kernel.org/lkml/DM8PR11MB57505481B2FE79C3D56C9201E7CE9@DM8PR11MB5750.namprd11.prod.outlook.com

Powered by blists - more mailing lists