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;
Message-ID: <da1c807e-66b7-7e9f-143d-44b6f7389b50@intel.com>
Date:   Wed, 26 Apr 2023 08:46:33 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Subject: Re: [PATCH] docs: security: Confidential computing intro and threat
 model
Content-Language: en-US
To:     Sean Christopherson <seanjc@google.com>,
        Carlos Bilbao <carlos.bilbao@amd.com>
Cc:     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
References: <20230327141816.2648615-1-carlos.bilbao@amd.com>
 <ZEfrjtgGgm1lpadq@google.com>
From:   Dave Hansen <dave.hansen@intel.com>
In-Reply-To: <ZEfrjtgGgm1lpadq@google.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.
Those defenses don't make much sense unless we've crossed that line in
the sand.

So, let's not quibble about where CoCo starts or ends, but let's _do_
make a list of things that we need before we do all the nonsense that
this doc suggests.

You're totally right that this doc forgot to mention guest registers
(whoops).