Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230327141816.2648615-1-carlos.bilbao@amd.com>
 <ZEfrjtgGgm1lpadq@google.com> <da1c807e-66b7-7e9f-143d-44b6f7389b50@intel.com>
 <ZElLUMDhIZPoG87K@google.com>
In-Reply-To: <ZElLUMDhIZPoG87K@google.com>
From:   Peter Gonda <pgonda@google.com>
Date:   Thu, 27 Apr 2023 13:06:39 -0600
Message-ID: <CAMkAt6qrrxkFEmsa_Df_PKo8pL7g4MhmkXFGQ19KZ-eqcqA61w@mail.gmail.com>
Subject: Re: [PATCH] docs: security: Confidential computing intro and threat model
To:     Sean Christopherson <seanjc@google.com>
Cc:     Dave Hansen <dave.hansen@intel.com>,
        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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Apr 26, 2023 at 10:03=E2=80=AFAM Sean Christopherson <seanjc@google=
.com> wrote:
>
> 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 miti=
gate
> > >> +such attacks by adding security features like guest data confidenti=
ality
> > >> +and integrity protection. This threat model assumes that those feat=
ures
> > >> +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 wha=
t
> > 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 eve=
n
> > 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 ther=
e
> > (with and without integrity protection), as are SEV=3D>SEV-ES=3D>SEV an=
d
> > MKTME=3D>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 a=
chieving
> its stated goal of providing an "architecture-agnostic introduction ... t=
o help
> developers gain a foundational understanding of the subject".  IMO, it do=
es more
> harm than good on that front because it presents Intel's and AMD's viewpo=
ints as
> if they are widely accepted for all of CoCo, and that is just flagrantly =
false.

I think changing this document to what Dave is describing is a more
useful doc rather than tdx-and-snp-threat-model.rst. The tdx and snp
threat models are well described by their respective white papers.

Lets do as Dave suggests and "not quibble about where CoCo starts or
ends", but make some definition of CoCo and its overall goals that way
we can start executing on kernel improvements to match those goals.