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]
Date:   Thu, 27 Apr 2023 12:43:05 +0000
From:   "Reshetova, Elena" <elena.reshetova@...el.com>
To:     "Christopherson,, Sean" <seanjc@...gle.com>,
        James Bottomley <jejb@...ux.ibm.com>
CC:     Carlos Bilbao <carlos.bilbao@....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>,
        "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, Apr 26, 2023, James Bottomley wrote:
> > 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,
> 
> If by "we" you mean Intel and AMD, then yes, that is probably a true statement.
> But those goals have nothing to do with security.

I disagree from pure security point of view, see below. 

> 
> > > 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.  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.
> 
> Yes.  And taking things a step further, if we were to ask security concious users
> what they would choose to have in their TCB: (a) closed-source firmware written
> by
> a hardware vendor, or (b) open-source software that is provided by CSPs, I am
> betting the overwhelming majority would choose (b).

As I already replied in my earlier message from yesterday, yes, this is the choice
that anyone has and it is free to make this choice. No questions asked. 
(Btw, please note that the above statement is not 100% accurate since the source
code for intel TDX module is at least public). 
However, if as you said the majority choose (b), why do they need to enable the
Confidential cloud computing technologies like TDX or SEV-SNP? 
If they choose (b), then the whole threat model described in this document do not
simply apply to them and they can forget about anything that we try to describe 
here. 

Now from the pure security point of view the choice between (a) and (b) is not so easily
done imo. Usually we take into account many factors that affect the risk/chances
that certain piece of SW has a higher risk of having vulnerabilities. This includes the
size of the codebase, its complexity, its attack surface exposure towards external
interfaces, level of testing, whenever the code is public, code dependency chains, etc.
Smaller codebase with no dependencies and small set of exposed interfaces is usually
easier to review from security point of view given that the code is public. 

Best Regards,
Elena.