linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Carlos Bilbao <carlos.bilbao@amd.com>,
	corbet@lwn.net, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, ardb@kernel.org, kraxel@redhat.com,
	dovmurik@linux.ibm.com, elena.reshetova@intel.com,
	dave.hansen@linux.intel.com, Dhaval.Giani@amd.com,
	michael.day@amd.com, pavankumar.paluri@amd.com,
	David.Kaplan@amd.com, Reshma.Lal@amd.com, Jeremy.Powell@amd.com,
	sathyanarayanan.kuppuswamy@linux.intel.com,
	alexander.shishkin@linux.intel.com, thomas.lendacky@amd.com,
	tglx@linutronix.de, dgilbert@redhat.com,
	gregkh@linuxfoundation.org, dinechin@redhat.com,
	linux-coco@lists.linux.dev, berrange@redhat.com, mst@redhat.com,
	tytso@mit.edu, jikos@kernel.org, joro@8bytes.org,
	leon@kernel.org, richard.weinberger@gmail.com, lukas@wunner.de,
	jejb@linux.ibm.com, cdupontd@redhat.com, jasowang@redhat.com,
	sameo@rivosinc.com, bp@alien8.de, security@kernel.org
Subject: Re: [PATCH] docs: security: Confidential computing intro and threat model
Date: Wed, 26 Apr 2023 09:03:28 -0700	[thread overview]
Message-ID: <ZElLUMDhIZPoG87K@google.com> (raw)
In-Reply-To: <da1c807e-66b7-7e9f-143d-44b6f7389b50@intel.com>

On Wed, Apr 26, 2023, Dave Hansen wrote:
> On 4/25/23 08:02, Sean Christopherson wrote:
> >> +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.
> 
> This document is clearly trying to draw a line in the sand and say:
> 
> 	CoCo on one side, non-CoCo on the other
> 
> I think it's less important to name that line than it is to realize what
> we need to do on one side versus the other.
> 
> For instance, if the system doesn't have strong guest memory
> confidentiality protection, then it's kinda silly to talk about the
> guest's need to defend against "CoCo guest data attacks".
> 
> Sure, the mitigations for "CoCo guest data attacks" are pretty sane even
> without all this CoCo jazz. But if your goal is to mitigate damage that
> a VMM out of the TCB can do, then they don't do much if there isn't
> VMM->guest memory confidentiality in the first place.
> 
> So, sure, CoCo implementations exist along a continuum.  SGX is in there
> (with and without integrity protection), as are SEV=>SEV-ES=>SEV and
> MKTME=>TDX.
> 
> This document is making the case that the kernel should go to some new
> (and extraordinary) lengths to defend itself against ... something.

Then name the document something other than confidential-computing.rst, e.g.
tdx-and-snp-threat-model.rst.  Because this doc isn't remotely close to achieving
its stated goal of providing an "architecture-agnostic introduction ... to help
developers gain a foundational understanding of the subject".  IMO, it does more
harm than good on that front because it presents Intel's and AMD's viewpoints as
if they are widely accepted for all of CoCo, and that is just flagrantly false.

 : In order to effectively engage with the linux-coco mailing list and contribute
 : to ongoing kernel efforts, one must have a thorough familiarity with these
 : concepts.  Add a concise, architecture-agnostic introduction and threat model
 : to provide a reference for ongoing design discussions and to help developers
 : gain a foundational understanding of the subject.

  reply	other threads:[~2023-04-26 16:03 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
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 [this message]
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=ZElLUMDhIZPoG87K@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=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@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dgilbert@redhat.com \
    --cc=dinechin@redhat.com \
    --cc=dovmurik@linux.ibm.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=richard.weinberger@gmail.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).