Message-ID: <4bde30cd-3ec6-bacd-5d92-1b52489a8c48@infradead.org>
Date:   Wed, 14 Jun 2023 08:06:06 -0700
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Carlos Bilbao <carlos.bilbao@....com>, corbet@....net
Cc:     linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        ardb@...nel.org, kraxel@...hat.com, dovmurik@...ux.ibm.com,
        elena.reshetova@...el.com, dave.hansen@...ux.intel.com,
        Dhaval.Giani@....com, michael.day@....com,
        pavankumar.paluri@....com, David.Kaplan@....com,
        Reshma.Lal@....com, Jeremy.Powell@....com,
        sathyanarayanan.kuppuswamy@...ux.intel.com,
        alexander.shishkin@...ux.intel.com, thomas.lendacky@....com,
        tglx@...utronix.de, dgilbert@...hat.com,
        gregkh@...uxfoundation.org, dinechin@...hat.com,
        linux-coco@...ts.linux.dev, berrange@...hat.com, mst@...hat.com,
        tytso@....edu, jikos@...nel.org, joro@...tes.org, leon@...nel.org,
        richard.weinberger@...il.com, lukas@...ner.de, jejb@...ux.ibm.com,
        cdupontd@...hat.com, jasowang@...hat.com, sameo@...osinc.com,
        bp@...en8.de, seanjc@...gle.com, security@...nel.org,
        Larry Dewey <larry.dewey@....com>
Subject: Re: [PATCH v2] docs: security: Confidential computing intro and
 threat model for x86 virtualization

Hi Carlos,

On 6/14/23 06:55, Carlos Bilbao wrote:
> Hello Randy,
> 
> On 6/12/23 17:43, Randy Dunlap wrote:
>> Hi--
>>
>> On 6/12/23 09:47, 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.
>>>
>>> Reviewed-by: Larry Dewey <larry.dewey@....com>
>>> Reviewed-by: David Kaplan <david.kaplan@....com>
>>> Co-developed-by: Elena Reshetova <elena.reshetova@...el.com>
>>> Signed-off-by: Elena Reshetova <elena.reshetova@...el.com>
>>> Signed-off-by: Carlos Bilbao <carlos.bilbao@....com>
>>> ---
>>>
>>> ---
>>>   Documentation/security/index.rst              |   1 +
>>>   .../security/x86-confidential-computing.rst   | 298 ++++++++++++++++++
>>>   MAINTAINERS                                   |   6 +
>>>   3 files changed, 305 insertions(+)
>>>   create mode 100644 Documentation/security/x86-confidential-computing.rst
>>>

>>> diff --git a/Documentation/security/x86-confidential-computing.rst b/Documentation/security/x86-confidential-computing.rst
>>> new file mode 100644
>>> index 000000000000..5c52b8888089
>>> --- /dev/null
>>> +++ b/Documentation/security/x86-confidential-computing.rst
>>> @@ -0,0 +1,298 @@
>>> +======================================================
>>> +Confidential Computing in Linux for x86 virtualization
>>> +======================================================
>>> +
>>> +.. contents:: :local:
>>> +
>>> +By: Elena Reshetova <elena.reshetova@...el.com> and Carlos Bilbao <carlos.bilbao@....com>
>>> +

>>> +The basic CoCo guest layout includes the host, guest, the interfaces that
>>> +communicate guest and host, a platform capable of supporting CoCo VMs, and
>>> +a trusted intermediary between the guest VM and the underlying platform
>>> +that acts as a security manager. The host-side virtual machine monitor
>>> +(VMM) typically consists of a subset of traditional VMM features and
>>> +is still in charge of the guest lifecycle, i.e. create or destroy a CoCo
>>> +VM, manage its access to system resources, etc. However, since it
>>> +typically stays out of CoCo VM TCB, its access is limited to preserve the
>>
>>                                                         to preserving the
>> ?
> 
> I think that using "preserving" and "preserve" here may result in two
> different interpretations:
> 
> "limited to preserve the security objectives" suggests that the limited
> access is enforced to preserve the security guarantees. In other words, the
> act of limiting access itself, particularly from the VMM, helps to maintain
> the security objectives. This is what we want to say.
> 
> "limited to preserving the security objectives" suggests that the access of
> the VMM is limited to the components that allow the VMM to preserve the
> security objectives.
> 
> Hope that makes sense?

Yes, I get it, thanks.

>>
>>> +security objectives.
>>> +
>>> +In the following diagram, the "<--->" lines represent bi-directional
>>> +communication channels or interfaces between the CoCo security manager and
>>> +the rest of the components (data flow for guest, host, hardware) ::
>>> +
>>> +    +-------------------+      +-----------------------+
>>> +    | CoCo guest VM     |<---->|                       |
>>> +    +-------------------+      |                       |
>>> +      | Interfaces |           | CoCo security manager |
>>> +    +-------------------+      |                       |
>>> +    | Host VMM          |<---->|                       |
>>> +    +-------------------+      |                       |
>>> +                               |                       |
>>> +    +--------------------+     |                       |
>>> +    | CoCo platform      |<--->|                       |
>>> +    +--------------------+     +-----------------------+
>>> +
>>> +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.
>>> +

>>> +Confidential Computing threat model and its security objectives
>>> +===============================================================
>>> +
>>> +Confidential Computing adds a new type of attacker to the above list: a
>>> +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’t 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 guest
>>
>> Hyphens (dashes) are not normally used for a parenthetical phrase AFAIK.
> 
> Yes, parentheses would be more appropriate.
> 
>>
>>> +kernel communication with most of the HW::
>>
>> I would prefer to capitalize "kernel" above.
> 
> I'm not sure I follow, we don't capitalize kernel elsewhere, why here?
> 

My mistake in reading. :(



Thanks.

-- 
~Randy

Powered by blists - more mailing lists