Message-ID: <ZInLlkXsgnej9ZpT@google.com>
Date:   Wed, 14 Jun 2023 07:15:50 -0700
From:   Sean Christopherson <seanjc@...gle.com>
To:     Elena Reshetova <elena.reshetova@...el.com>
Cc:     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>
Subject: Re: [PATCH v2] docs: security: Confidential computing intro and
 threat model for x86 virtualization

On Wed, Jun 14, 2023, Elena Reshetova wrote:
> > > +The specific details of the CoCo security manager vastly diverge between
> > > +technologies. For example, in some cases, it will be implemented in HW
> > > +while in others it may be pure SW. In some cases, such as for the
> > > +`Protected kernel-based virtual machine (pKVM) <https://github.com/intel-
> > staging/pKVM-IA>`,
> > > +the CoCo security manager is a small, isolated and highly privileged
> > > +(compared to the rest of SW running on the host) part of a traditional
> > > +VMM.
> > 
> > I say that "virtualized environments" isn't a good description because
> > while pKVM does utilize hardware virtualization, my understanding is that
> > the primary use cases for pKVM don't have the same threat model as SNP/TDX,
> > e.g. IIUC many (most?  all?) pKVM guests don't require network access.
> 
> 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 again I will let Jason to reply on this since he knows details. 
> 
> But what you are saying more generally here and above is that you don’t want
> pKVM case included into this threat model, did I understand you correctly? 

More or less.  I think the threat models for pKVM versus TDX/SNP are different
enough that accurately capturing the nuances and novelties of the TDX/SNP threat
model will be unnecessarily difficult if you also try to lump in pKVM.  E.g. pKVM
is intended to run on portable client hardware, likely without memory encryption,
versus TDX/SNP being almost exclusively server oriented with the hardware being
owned and hosted by a third party that is benign (perhaps trusted even), but not
necessarily physically isolated enough to satisfy the end user's security
requirements.

One of the points I (and others) was trying to get across in v1 feedback is that
security requirements for CoCo are not the same across all use cases, and that
there are subtle but meaningful differences even when use cases are built on common
underlying technology.  In other words, describing the TDX/SNP threat model with
sufficient detail and nuance is difficult enough without throwing pKVM into the
mix.

And I don't see any need to formally document pKVM's threat model right *now*.
pKVM on x86 is little more than a proposal at this point, and while I would love
to see documentation for pKVM on ARM's threat model, that obviously doesn't belong
in a doc that's x86 specific.

> > > +potentially misbehaving host (which can also include some part of a
> > > +traditional VMM or all of it), which is typically placed outside of the
> > > +CoCo VM TCB due to its large SW attack surface. It is important to note
> > > +that this doesn’t imply that the host or VMM are intentionally
> > > +malicious, but that there exists a security value in having a small CoCo
> > > +VM TCB. 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.

Powered by blists - more mailing lists