Message-ID: <DM8PR11MB5750D16B08B769173DCD740AE75AA@DM8PR11MB5750.namprd11.prod.outlook.com>
Date:   Wed, 14 Jun 2023 07:37:50 +0000
From:   "Reshetova, Elena" <elena.reshetova@...el.com>
To:     "Christopherson,, Sean" <seanjc@...gle.com>,
        Carlos Bilbao <carlos.bilbao@....com>,
        "Chen, Jason CJ" <jason.cj.chen@...el.com>
CC:     "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 Mon, Jun 12, 2023, Carlos Bilbao wrote:
> > Kernel developers working on confidential computing for virtualized
> > environments in x86 operate under a set of assumptions regarding the Linux
> 
> No, "x86" isn't special, SNP and TDX and s390's UV are special.  pKVM is similar,
> but (a) it's not as paranoid as SNP and TDX, and (b) the known use case for pKVM
> on x86 is to harden usage of hardware devices, i.e. pKVM x86 "guests" likely
> don't
> have the same "untrusted virtual device" attack surfaces a SNP/TDX/UV guests.

+ Jason Chen to help clarifying the pKVM on x86 case.

My impression was that pKVM on x86 would similarly care about hardening its
pKVM guest kernel against host attacks. Because in security world,
if you try to put smth outside of your TCB (host SW stack in this case),
you automatically need to prevent privilege escalation attacks from 
outside to inside and that implies caring about attacks that host can
do via let's say malicious pci drivers and such.
What prevents host doing such attacks in pKVM case? 

> 
> > +Kernel developers working on confidential computing for virtualized
> > +environments in x86 operate under a set of assumptions regarding the Linux
> 
> I don't think "virtualized environments" is the right description.  IMO, "cloud
> computing environments" or maybe "off-premise environments" more
> accurately
> captures what you want to document, though the latter fails to imply the
> "virtual"
> aspect of things.

Hm.. "cloud computing environments" explicitly implies "cloud", which is what
we were trying to get away from in v2, because it describes a *particular* use case
where CoCo VMs can be used (and probably will be used a lot in practice), but
we don’t want to limit this to just that use case and exclude others. 
"off-premise environments" is so vague imo that I would not know what it means
in this context, if I would be a person new to the topic of CoCo. And as you said
it doesn’t even imply the virtual aspect at all. 

> 
> > +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. 
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? 

> 
> > +Confidential Computing adds a new type of attacker to the above list: a
> 
> This should be qualified as "CoCo for cloud", or whatever sublabel we land on.

Yes, we just need to find this label. If you remember, v1 had the name 
"Confidential Cloud Computing", which you were the first one to complain about ))

> 
> > +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. 

> 
> > +The **Linux kernel CoCo VM security objectives** can be summarized as
> follows:
> > +
> > +1. Preserve the confidentiality and integrity of CoCo guest's private
> > +memory and registers.
> 
> As I complained in v1, this doesn't hold true for all of x86.  My complaint goes
> away if the document is specific to the TDX/SNP/UV threat models, but describing
> the doc as "x86 specific" is misleading, as the threat model isn't x86 specific,
> nor do all confidential compute technologies that run on x86 share these
> objectives,
> e.g. vanilla SEV.

Yes, this brings us back to the naming issue, see below.

> 
> > +well as CoCo technology specific hypercalls, if present. Additionally, the
> > +host in a CoCo system typically controls the process of creating a CoCo
> > +guest: it has a method to load into a guest the firmware and bootloader
> > +images, the kernel image together with the kernel command line. All of this
> > +data should also be considered untrusted until its integrity and
> > +authenticity is established via attestation.
> 
> Attestation is SNP and TDX specific.  AIUI, none of SEV, SEV-ES, or pKVM (which
> doesn't even really exist on x86 yet), have attestation of their own, e.g. the
> proposed pKVM support would rely on Secure Boot of the original "full" host
> kernel.

Agree the last phrase needs to be corrected to apply for pKVM case (was missed
in v2), so propose to have this text instead:

"All of this data should also be considered untrusted until its integrity and
authenticity is established via a CoCo technology-defined process such as attestation
or variants of secure/trusted/authenticated boot."

The goal of the above sentence is only to say that the integrity/authenticity 
must be established via whatever method a concrete technology brings,
otherwise we have a big problem in security. 

> 
> > +CONFIDENTIAL COMPUTING THREAT MODEL FOR X86 VIRTUALIZATION
> > +M:    Elena Reshetova <elena.reshetova@...el.com>
> > +M:    Carlos Bilbao <carlos.bilbao@....com>
> > +S:    Maintained
> > +F:    Documentation/security/x86-confidential-computing.rst
> 
> Throwing "x86" on the name doesn't change my objections, this is still an
> SNP/TDX
> specific doc pretending to be more generic then it actually is.  I don't understand
> the resistance to picking a name that makes it abundantly clear the doc covers a
> very specific niche of confidential computing.

We really don’t pretend to "overgeneric", but since noone else outside of x86 is
interested to help writing this document or becoming a co-maintainer, we cannot
claim covering more than merely describing x86 specific solutions in this space.

But, let’s agree on the name and then we can plug it everywhere in v3.
v1 used "Confidential Cloud Computing"
v2 used "Confidential Computing for virtualized environments" 

You proposed above
"Confidential computing for cloud computing environments "
and
"Confidential Computing for off-premise environments ".

I still don’t get what is wrong with "Confidential Computing for
virtualized environments" name: you mentioned it doesn’t
describe correctly what we want to express, but you didn’t explain
why. Could you please elaborate?

Also, is the name *that* important given that we have already spend
a whole paragraph in v2 explaining what we mean by this name?
We are all tech people here, so we don’t plan to use this name
for marketing campaigns :)

Best Regards,
Elena.

Powered by blists - more mailing lists