linux-kernel - RE: [PATCH] docs: security: Confidential computing intro and threat model

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]

Message-ID: <DM8PR11MB5750FBFC3635B12A70F35A7AE76A9@DM8PR11MB5750.namprd11.prod.outlook.com>
Date:   Thu, 27 Apr 2023 12:56:25 +0000
From:   "Reshetova, Elena" <elena.reshetova@...el.com>
To:     "jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
        "Christopherson,, Sean" <seanjc@...gle.com>,
        Carlos Bilbao <carlos.bilbao@....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>,
        "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>,
        Andrew Bresticker <abrestic@...osinc.com>,
        Rajnesh Kanwal <rkanwal@...osinc.com>,
        Dylan Reid <dylan@...osinc.com>,
        Ravi Sahita <ravi@...osinc.com>
Subject: RE: [PATCH] docs: security: Confidential computing intro and threat
 model


> On Wed, 2023-04-26 at 13:32 +0000, Reshetova, Elena wrote:
> > > On Mon, Mar 27, 2023, Carlos Bilbao wrote:
> [...]
> > > > +provide stronger security guarantees to their clients (usually
> > > > referred to +as tenants) by excluding all the CSP's
> > > > infrastructure and SW out of the +tenant's Trusted Computing Base
> > > > (TCB).
> > >
> > > This is inaccurate, the provider may still have software and/or
> > > hardware in the TCB.
> >
> > Well, this is the end goal where we want to be, the practical
> > deployment can differ of course. We can rephrase that it "allows to
> > exclude all the CSP's infrastructure and SW out of tenant's TCB."
> 
> That's getting even more inaccurate.  To run  in a Cloud with CoCo you
> usually have to insert some provided code, like OVMF and, for AMD, the
> SVSM.  These are often customized by the CSP to suit the cloud
> infrastructure, so you're running their code.  

Agree, this *can be the case in practice*, but it doesn’t have to be one. Nothing from the
CoCo technology itself prevents tenants in this model to have their own virtual FW.
The fact that CSPs infrastructure might not support this case is a totally different story.

The goal, I think, is to
> make sure you only run code you trust (some of which may come from the
> CSP) in your TCB, which is very different from the statement above.

At the end it would go down to the agreement between a CSP and tenant, i.e.
how much tenants are willing to trust CSP and how much of CSPs code they
would take into their TCB (using proper means of establishing a trust in these
pieces).  This agreement is our of anyone control here and the only thing that 
the CoCo technologies are aiming to provide is to enable all these different
models/agreements, including the ultimate case (if wanted) when tenants could run
without any CSP components in their TCB.

So, let’s fix the wording in the document that it is indeed doesn’t rule out any of
the agreements styles, but the goal of this document is not to describe CoCo
use cases, but to talk about what Linux kernel needs to do assuming there are
tenants who want to make sure they run kernel inside a CoCo VM that is ready
to take the new threat model into account.

Best Regards,
Elena.