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;
Date:   Tue, 13 Jun 2023 10:03:02 -0700
In-Reply-To: <20230612164727.3935657-1-carlos.bilbao@amd.com>
Mime-Version: 1.0
References: <20230612164727.3935657-1-carlos.bilbao@amd.com>
Message-ID: <ZIihRqZljMaMRGcK@google.com>
Subject: Re: [PATCH v2] docs: security: Confidential computing intro and
 threat model for x86 virtualization
From:   Sean Christopherson <seanjc@google.com>
To:     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,
        Larry Dewey <larry.dewey@amd.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Jun 12, 2023, Carlos Bilbao wrote:
> Kernel developers working on confidential computing for virtualized
> environments in x86 operate under a set of assumptions regarding the Linu=
x

No, "x86" isn't special, SNP and TDX and s390's UV are special.  pKVM is si=
milar,
but (a) it's not as paranoid as SNP and TDX, and (b) the known use case for=
 pKVM
on x86 is to harden usage of hardware devices, i.e. pKVM x86 "guests" likel=
y don't
have the same "untrusted virtual device" attack surfaces a SNP/TDX/UV guest=
s.

> +Kernel developers working on confidential computing for virtualized
> +environments in x86 operate under a set of assumptions regarding the Lin=
ux

I don't think "virtualized environments" is the right description.  IMO, "c=
loud
computing environments" or maybe "off-premise environments" more accurately
captures what you want to document, though the latter fails to imply the "v=
irtual"
aspect of things.

> +The specific details of the CoCo security manager vastly diverge between
> +technologies. For example, in some cases, it will be implemented in HW
> +while in others it may be pure SW. In some cases, such as for the
> +`Protected kernel-based virtual machine (pKVM) <https://github.com/intel=
-staging/pKVM-IA>`,
> +the CoCo security manager is a small, isolated and highly privileged
> +(compared to the rest of SW running on the host) part of a traditional
> +VMM.

I say that "virtualized environments" isn't a good description because whil=
e pKVM
does utilize hardware virtualization, my understanding is that the primary =
use
cases for pKVM don't have the same threat model as SNP/TDX, e.g. IIUC many =
(most?
all?) pKVM guests don't require network access.

> +Confidential Computing adds a new type of attacker to the above list: a

This should be qualified as "CoCo for cloud", or whatever sublabel we land =
on.

> +potentially misbehaving host (which can also include some part of a
> +traditional VMM or all of it), which is typically placed outside of the
> +CoCo VM TCB due to its large SW attack surface. It is important to note
> +that this doesn=E2=80=99t imply that the host or VMM are intentionally
> +malicious, but that there exists a security value in having a small CoCo
> +VM TCB. This new type of adversary may be viewed as a more powerful type
> +of external attacker, as it resides locally on the same physical machine
> +-in contrast to a remote network attacker- and has control over the gues=
t
> +kernel communication with most of the HW::

IIUC, this last statement doesn't hold true for the pKVM on x86 use case, w=
hich
specifically aims to give a "guest" exclusive access to hardware resources.

> +The **Linux kernel CoCo VM security objectives** can be summarized as fo=
llows:
> +
> +1. Preserve the confidentiality and integrity of CoCo guest's private
> +memory and registers.

As I complained in v1, this doesn't hold true for all of x86.  My complaint=
 goes
away if the document is specific to the TDX/SNP/UV threat models, but descr=
ibing
the doc as "x86 specific" is misleading, as the threat model isn't x86 spec=
ific,
nor do all confidential compute technologies that run on x86 share these ob=
jectives,
e.g. vanilla SEV.

> +well as CoCo technology specific hypercalls, if present. Additionally, t=
he
> +host in a CoCo system typically controls the process of creating a CoCo
> +guest: it has a method to load into a guest the firmware and bootloader
> +images, the kernel image together with the kernel command line. All of t=
his
> +data should also be considered untrusted until its integrity and
> +authenticity is established via attestation.

Attestation is SNP and TDX specific.  AIUI, none of SEV, SEV-ES, or pKVM (w=
hich
doesn't even really exist on x86 yet), have attestation of their own, e.g. =
the
proposed pKVM support would rely on Secure Boot of the original "full" host=
 kernel.

> +CONFIDENTIAL COMPUTING THREAT MODEL FOR X86 VIRTUALIZATION
> +M:    Elena Reshetova <elena.reshetova@intel.com>
> +M:    Carlos Bilbao <carlos.bilbao@amd.com>
> +S:    Maintained
> +F:    Documentation/security/x86-confidential-computing.rst

Throwing "x86" on the name doesn't change my objections, this is still an S=
NP/TDX
specific doc pretending to be more generic then it actually is.  I don't un=
derstand
the resistance to picking a name that makes it abundantly clear the doc cov=
ers a
very specific niche of confidential computing.