Message-ID: <CAJzde06TP5D1UAko6tJmdPt-0Ja4cnByWEDF0c6KJ4k__WjODg@mail.gmail.com>
Date:   Fri, 16 Jun 2023 09:09:50 -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 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:
> > >> 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.

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 wouldn't
be any availability guarantees, but my understanding is that isn't in
scope for pKVM.

In the case where the host owns a TPM and the guest has to cooperate
with the host to communicate with the TPM. There are schemes for
establishing trust between the TPM and the trusted guest with various
properties (authentication, confidentiality, integrity, etc.). This
does have the downside of additional complexity, but comes with the
benefit of also being resistant to attacks like monitoring the SPI
lines going to the TPM.

Did you have particular situations in mind for resources that would be
owned by the host and needed by the trusted guest?

Powered by blists - more mailing lists