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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 16 Jun 2023 06:56:17 -0700
From:   Sean Christopherson <seanjc@...gle.com>
To:     Dmytro Maluka <dmy@...ihalf.com>
Cc:     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>,
        Allen Webb <allenwebb@...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, 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.