Re: [PATCH] docs: security: Confidential computing intro and threat model

[Sean Christopherson]

On Mon, Mar 27, 2023, Carlos Bilbao wrote:
> +Kernel developers working on confidential computing for the cloud operate
> +under a set of assumptions regarding the Linux kernel threat model that
> +differ from the traditional view. In order to effectively engage with the
> +linux-coco mailing list and contribute to its initiatives, one must have a
> +thorough familiarity with these concepts. This document provides a concise,
> +architecture-agnostic introduction to help developers gain a foundational

Heh, vendor agnostic maybe, but certainly not architecture agnostic.

> +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.

> +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@xxxxxxxxxx

> +While the concrete implementation details differ between technologies, all
> +of these mechanisms provide increased confidentiality and integrity of CoCo
> +guest memory and execution state (vCPU registers), more tightly controlled
> +guest interrupt injection,

This is highly dependent on how "interrupt" is defined, and how "controlled" is
defined.

> as well as some additional mechanisms to control guest-host page mapping.

This is flat out wrong for SNP for any reasonable definition of "page mapping".
SNP has _zero_ "control" over page tables, which is most people think of when they
see "page mapping".

> More details on the x86-specific solutions can be
> +found in
> +:doc:`Intel Trust Domain Extensions (TDX) </x86/tdx>` and
> +:doc:`AMD Memory Encryption </x86/amd-memory-encryption>`.

So by the above definition, vanilla SEV and SEV-ES can't be considered CoCo.  SEV
doesn't provide anything besides increased confidentiality of guest memory, and
SEV-ES doesn't provide integrity or validation of physical page assignment.

> +The basic CoCo layout includes the host, guest, the interfaces that
> +communicate guest and host, a platform capable of supporting CoCo,

CoCo VMs...

> and an intermediary between the guest virtual machine (VM) and the
> underlying platform that acts as security manager::

Having an intermediary is very much an implementation detail.

> +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.

> +The **Linux kernel CoCo security objectives** can be summarized as follows:
> +
> +1. Preserve the confidentiality and integrity of CoCo guest private memory.

So, registers are fair game?

> +2. Prevent privileged escalation from a host into a CoCo guest Linux kernel.
> +
> +The above security objectives result in two primary **Linux kernel CoCo
> +assets**:
> +
> +1. Guest kernel execution context.
> +2. Guest kernel private memory.

...

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7f86d02cb427..4a16727bf7f9 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5307,6 +5307,12 @@ S:	Orphan
>  W:	http://accessrunner.sourceforge.net/
>  F:	drivers/usb/atm/cxacru.c
>  
> +CONFIDENTIAL COMPUTING THREAT MODEL

This is not generic CoCo documentation, it's specific to CoCo VMs.  E.g. SGX is
most definitely considered a CoCo feature, and it has no dependencies whatsoever
on virtualization.

> +M:	Elena Reshetova <elena.reshetova@xxxxxxxxx>
> +M:	Carlos Bilbao <carlos.bilbao@xxxxxxx>

I would love to see an M: or R: entry for someone that is actually _using_ CoCo.

IMO, this document is way too Intel/AMD centric.