linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Carlos Bilbao <carlos.bilbao@amd.com>
Cc: Elena Reshetova <elena.reshetova@intel.com>,
	"corbet@lwn.net" <corbet@lwn.net>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"ardb@kernel.org" <ardb@kernel.org>,
	"kraxel@redhat.com" <kraxel@redhat.com>,
	"dovmurik@linux.ibm.com" <dovmurik@linux.ibm.com>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"Dhaval.Giani@amd.com" <Dhaval.Giani@amd.com>,
	"michael.day@amd.com" <michael.day@amd.com>,
	"pavankumar.paluri@amd.com" <pavankumar.paluri@amd.com>,
	"David.Kaplan@amd.com" <David.Kaplan@amd.com>,
	"Reshma.Lal@amd.com" <Reshma.Lal@amd.com>,
	"Jeremy.Powell@amd.com" <Jeremy.Powell@amd.com>,
	"sathyanarayanan.kuppuswamy@linux.intel.com" 
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	"alexander.shishkin@linux.intel.com" 
	<alexander.shishkin@linux.intel.com>,
	"thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"dgilbert@redhat.com" <dgilbert@redhat.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"dinechin@redhat.com" <dinechin@redhat.com>,
	"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
	"berrange@redhat.com" <berrange@redhat.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"tytso@mit.edu" <tytso@mit.edu>,
	"jikos@kernel.org" <jikos@kernel.org>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"leon@kernel.org" <leon@kernel.org>,
	"richard.weinberger@gmail.com" <richard.weinberger@gmail.com>,
	"lukas@wunner.de" <lukas@wunner.de>,
	"jejb@linux.ibm.com" <jejb@linux.ibm.com>,
	"cdupontd@redhat.com" <cdupontd@redhat.com>,
	"jasowang@redhat.com" <jasowang@redhat.com>,
	"sameo@rivosinc.com" <sameo@rivosinc.com>,
	"bp@alien8.de" <bp@alien8.de>,
	"security@kernel.org" <security@kernel.org>,
	Andrew Bresticker <abrestic@rivosinc.com>,
	Rajnesh Kanwal <rkanwal@rivosinc.com>,
	Dylan Reid <dylan@rivosinc.com>, Ravi Sahita <ravi@rivosinc.com>
Subject: Re: [PATCH] docs: security: Confidential computing intro and threat model
Date: Wed, 26 Apr 2023 08:51:43 -0700	[thread overview]
Message-ID: <ZElIjw7Ca6N2mYHe@google.com> (raw)
In-Reply-To: <9fa5ce43-584d-878d-227a-fb458254c00a@amd.com>

On Wed, Apr 26, 2023, Carlos Bilbao wrote:
> Hello Sean,
> 
> On 4/26/23 8:32 AM, Reshetova, Elena wrote:
> >  Hi Sean, 
> > 
> > Thank you for your review! Please see my comments inline. 
> > 
> >> On Mon, Mar 27, 2023, Carlos Bilbao wrote:

...

> >>> More details on the x86-specific solutions can be
> >>> +found in
> >>> +:doc:`Intel Trust Domain Extensions (TDX) </x86/tdx>` and
> >>> +:doc:`AMD Memory Encryption </x86/amd-memory-encryption>`.
> >>
> >> So by the above definition, vanilla SEV and SEV-ES can't be considered CoCo.  SEV
> >> doesn't provide anything besides increased confidentiality of guest memory, and
> >> SEV-ES doesn't provide integrity or validation of physical page assignment.
> >>
> > 
> > Same
> >
> 
> Personally, I think it's reasonable to mention SEV/SEV-ES in the context of
> confidential computing and acknowledge their relevance in this area.
> 
> But there is no mention to SEV or SEV-ES in this draft. And the document we
> reference there covers AMD-SNP, which provides integrity.

...

> >>> +While the traditional hypervisor has unlimited access to guest data and
> >>> +can leverage this access to attack the guest, the CoCo systems mitigate
> >>> +such attacks by adding security features like guest data confidentiality
> >>> +and integrity protection. This threat model assumes that those features
> >>> +are available and intact.
> >>
> >> Again, if you're claiming integrity is a key tenant, then SEV and SEV-ES can't be
> >> considered CoCo.
> 
> Again, nobody mentioned SEV/SEV-ES here.

Yes, somebody did.  Unless your dictionary has a wildly different definition for
"all".

 : +Overview and terminology
 : +========================
 : +
 : +Confidential Cloud Computing (CoCo) refers to a set of HW and SW
 : +virtualization technologies that allow Cloud Service Providers (CSPs) to
 : +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).
 : +
 : +While the concrete implementation details differ between technologies, all
                                                                           ^^^
 : +of these mechanisms provide increased confidentiality and integrity of CoCo
 : +guest memory and execution state (vCPU registers), more tightly controlled
 : +guest interrupt injection, as well as some additional mechanisms to control
 : +guest-host page mapping. More details on the x86-specific solutions can be
 : +found in

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.

  reply	other threads:[~2023-04-26 15:52 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-27 14:18 [PATCH] docs: security: Confidential computing intro and threat model Carlos Bilbao
2023-03-29 10:40 ` Greg KH
2023-03-30 17:32   ` Carlos Bilbao
2023-04-22  3:17   ` Bagas Sanjaya
2023-04-21 21:09 ` Kaplan, David
2023-04-25 13:43   ` Carlos Bilbao
2023-04-25 15:02 ` Sean Christopherson
2023-04-26 13:32   ` Reshetova, Elena
2023-04-26 15:08     ` Carlos Bilbao
2023-04-26 15:51       ` Sean Christopherson [this message]
2023-04-26 19:21         ` Carlos Bilbao
2023-04-26 19:53           ` Sean Christopherson
2023-04-26 20:15             ` Carlos Bilbao
2023-04-26 21:33               ` Sean Christopherson
2023-04-26 22:27                 ` Carlos Bilbao
2023-04-27 12:29                 ` Reshetova, Elena
2023-04-27 14:16                   ` Carlos Bilbao
2023-04-27 15:18                     ` Sean Christopherson
2023-04-27 17:59                       ` Carlos Bilbao
2023-04-26 20:12           ` Dave Hansen
2023-04-26 15:18     ` James Bottomley
2023-04-26 16:17       ` Sean Christopherson
2023-04-27 12:43         ` Reshetova, Elena
2023-04-27 13:18           ` James Bottomley
2023-04-27 15:47             ` Reshetova, Elena
2023-04-27 16:16               ` James Bottomley
2023-04-27 16:46                 ` Randy Dunlap
2023-04-27 17:19             ` Michael S. Tsirkin
2023-04-27 18:27               ` James Bottomley
2023-04-27 12:56       ` Reshetova, Elena
2023-04-26 15:46   ` Dave Hansen
2023-04-26 16:03     ` Sean Christopherson
2023-04-27 19:06       ` Peter Gonda
2023-04-27 18:47   ` Peter Gonda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZElIjw7Ca6N2mYHe@google.com \
    --to=seanjc@google.com \
    --cc=David.Kaplan@amd.com \
    --cc=Dhaval.Giani@amd.com \
    --cc=Jeremy.Powell@amd.com \
    --cc=Reshma.Lal@amd.com \
    --cc=abrestic@rivosinc.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=ardb@kernel.org \
    --cc=berrange@redhat.com \
    --cc=bp@alien8.de \
    --cc=carlos.bilbao@amd.com \
    --cc=cdupontd@redhat.com \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=dgilbert@redhat.com \
    --cc=dinechin@redhat.com \
    --cc=dovmurik@linux.ibm.com \
    --cc=dylan@rivosinc.com \
    --cc=elena.reshetova@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jasowang@redhat.com \
    --cc=jejb@linux.ibm.com \
    --cc=jikos@kernel.org \
    --cc=joro@8bytes.org \
    --cc=kraxel@redhat.com \
    --cc=leon@kernel.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=michael.day@amd.com \
    --cc=mst@redhat.com \
    --cc=pavankumar.paluri@amd.com \
    --cc=ravi@rivosinc.com \
    --cc=richard.weinberger@gmail.com \
    --cc=rkanwal@rivosinc.com \
    --cc=sameo@rivosinc.com \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=security@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).