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: <ZEmYR0fWl05lGW0d@google.com>
Date:   Wed, 26 Apr 2023 14:33:06 -0700
From:   Sean Christopherson <seanjc@...gle.com>
To:     Carlos Bilbao <carlos.bilbao@....com>
Cc:     Elena Reshetova <elena.reshetova@...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>,
        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, Carlos Bilbao wrote:
> On 4/26/23 2:53 PM, Sean Christopherson wrote:
> > On Wed, Apr 26, 2023, Carlos Bilbao wrote:
> >> On 4/26/23 10:51 AM, Sean Christopherson wrote:
> >>> This document is named confidential-computing.rst, not tdx-and-snp.rst.  Not
> >>> explicitly mentioning SEV doesn't magically warp reality to make descriptions like
> >>> this one from security/secrets/coco.rst disappear:
> >>>
> >>>   Introduction                                                                    
> >>>   ============                                                                    
> >>>                                                                                 
> >>>   Confidential Computing (coco) hardware such as AMD SEV (Secure Encrypted        
> >>>   Virtualization) allows guest owners to inject secrets into the VMs              
> >>>   memory without the host/hypervisor being able to read them.
> >>>
> >>> My complaint about this document being too Intel/AMD centric isn't that it doesn't
> >>> mention other implementations, it's that the doc describes CoCo purely from the
> >>> narrow viewpoint of Intel TDX and AMD SNP, and to be blunt, reads like a press
> >>> release and not an objective overview of CoCo.
> >>
> >> Be specific about the parts of the document that you feel are too
> >> AMD/Intel centric, and we will correct them.
> > 
> > The whole thing?  There aren't specific parts that are too SNP/TDX centric, the
> > entire tone and approach of the document is wrong.  As I responded to Dave, I
> > would feel differently if the document were named tdx-and-snp-threat-model.rst,
> > but this patch proposes a generic confidential-computing.rst and presents the
> > SNP+TDX confidential VM use case as if it's the *only* confidential computing use
> > case.
> 
> What part of us describing the current Linux kernel threat model or
> defining basic concepts of confidential computing is SNP/TDX centric?
> 
> IMHO, simply stating that "the whole thing" is wrong and that you don't
> like the "tone", is not making a good enough case for us to change
> anything, including the name of the document.

I honestly don't know how to respond since you are either unable or unwilling to
see the problems with naming a document "confidential computing" and then talking
only about one very, very specific flavor of confidential computing as if that is
the only flavor of confidential computing.

So if you want to push this doc as is, please add my

Nacked-by: Sean Christopherson <seanjc@...gle.com>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ