RE: [PATCH v3] docs: security: Confidential computing intro and threat model for x86 virtualization

[Reshetova, Elena]

> On Tue, Jul 11, 2023 at 09:12:57AM -0500, Carlos Bilbao wrote:
> > Kernel developers working on confidential computing for virtualized
> > environments in x86 operate under a set of assumptions regarding the Linux
> > kernel threat model that differs from the traditional view. Historically,
> > the Linux threat model acknowledges attackers residing in userspace, as
> > well as a limited set of external attackers that are able to interact with
> > the kernel through networking or limited HW-specific exposed interfaces
> > (e.g. USB, thunderbolt). The goal of this document is to explain additional
> > attack vectors that arise in the virtualized confidential computing space
> > and discuss the proposed protection mechanisms for the Linux kernel.
> 
> When you have a "and" in a changelog text, that's a huge hint that it
> needs to be split up into multiple patches.
> 
> And that's the case here, you want to do two things, describe your crazy
> model of different attack vectors AND propose new ways to protect from
> them.

Actually if you read the full doc we are not proposing *yet* any *concrete* new
mechanisms of protecting against these attack vectors that would require
kernel patches. These are indeed going to come later with the code changes
as you highlight below. What we *do* discuss below is high-level mitigation
strategies that wont make sense to include in the actual patches, because
some of these mitigations wont need *any* new patches to linux. For example,
the first attack we have is " Guest malicious configuration", where the
misbehaving host modifies one of the guest's configuration (kernel binary, 
command line, etc). The general mitigation for this attack vector is a way 
to authenticate/attest this configuration and it is mostly transparent for the
kernel. So, we either need to drop this attack description fully form the doc
(and this would result in questions from people not familiar with CoCo: why
do you try to harden the kernel apis when you don’t describe how kernel
binary integrity is protected), or we leave it in for an overall picture to provide
context and justify the overall reasoning. 

That said we can rewrite the sentence that you commented upon not to create
confusion (I do agree it can be misinterpreted the way you pointed out):

"The goal of this document is to explain additional
attack vectors that arise in the virtualized confidential computing space,
as well as highlight the overall mitigation strategies that can used
to address them.
The concrete mechanisms, if determined needed for Linux,
will be described in the future extensions of this document, together with the
code that implements them".

Does this address your concern? 

Best Regards,
Elena