linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Gonda <pgonda@google.com>
To: Sean Christopherson <seanjc@google.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: Thu, 27 Apr 2023 12:47:06 -0600	[thread overview]
Message-ID: <CAMkAt6ohvgj6h=jySx0684MiF7GZt_Q7AZK5uyU2PRKomg=rgw@mail.gmail.com> (raw)
In-Reply-To: <ZEfrjtgGgm1lpadq@google.com>

>
> > +understanding of the subject.
> > +
> > +Overview and terminology
> > +========================
> > +
> > +Confidential Cloud Computing (CoCo) refers to a set of HW and SW
>
> As per Documentation/security/secrets/coco.rst and every discussion I've observed,
> CoCo is Confidential Computing.  "Cloud" is not part of the definition.  That's
> true even if this discussion is restricted to CoCo VMs, e.g. see pKVM.
>
> > +virtualization technologies that allow Cloud Service Providers (CSPs) to
>
> Again, CoCo isn't just for cloud use cases.

Agreed Cloud should not be included in the definition. pKVM may be
considered CoCo and its current usage is protecting secrets on a
single device. CoCo features could be used with-in a single
organization to add extra protection to high value secrets.

>
> > +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.
>
> And for the cloud use case, I very, very strongly object to implying that the goal
> of CoCo is to exclude the CSP from the TCB.  Getting out of the TCB is the goal for
> _some_ CSPs, but it is not a fundamental tenant of CoCo.  This viewpoint is heavily
> tainted by Intel's and AMD's current offerings, which effectively disallow third
> party code for reasons that have nothing to do with security.
>
> https://lore.kernel.org/all/Y+aP8rHr6H3LIf%2Fc@google.com
>

How about phrasing like "CoCo allows its users to pick and choose
which pieces of software system to trust and gives the ability to
attest the state of trusted components"

Maybe some customers want to exclude or attest to the entire CSP infra
and SW. But it seems likely that customers may want to use and trust
some components of a CSP. For instance you may enable CoCo on a
workload but then trust the CSP's IAM implementation to make sure data
only enters those CoCo workloads.

>
> > +Confidential Computing threat model and security objectives
> > +===========================================================
> > +
> > +Confidential Cloud Computing adds a new type of attacker to the above list:
> > +an untrusted and potentially malicious host.
>
> I object to splattering "malicious host" everywhere.  Many people are going to
> read this and interpret "host" as "the CSP", and then make assumptions like
> "CoCo assumes the CSP is malicious!".  AIUI, the vast majority of use cases aren't
> concerned so much about "the CSP" being malicious, but rather they're concerned
> about new attack vectors that come with running code/VMs on a stack that is
> managed by a third party, on hardware that doesn't reside in a secured facility,
> etc.
>
> > +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.

Hmm the doc mentions "untrusted and potentially malicious host." but
seems to take the stance the CoCo requires tech where malicious host
deprivelleging is possible. But as Sean points out there may be valid
CoCo theat models where the host is trusted, or trusted to be benign
like SEV and SEV-ES.

I think this doc could use some more nuance so that less strict
threat-models are supported.

Also in regard to "malicious host" I think we can use this term since
that could be a valid threat. And in general I think cloud customers
are sophisticated enough to understand that a single lone malicious
host is far different than a malicious CSP. CSPs are in general large
organizations with many services of which VMs or "enclaves" are only a
small part.

      parent reply	other threads:[~2023-04-27 18:47 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
2023-04-27 19:06       ` Peter Gonda
2023-04-27 18:47   ` Peter Gonda [this message]

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='CAMkAt6ohvgj6h=jySx0684MiF7GZt_Q7AZK5uyU2PRKomg=rgw@mail.gmail.com' \
    --to=pgonda@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@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=seanjc@google.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).