| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 26 Apr 2023 14:21:05 -0500
From: Carlos Bilbao <carlos.bilbao@....com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Elena Reshetova <elena.reshetova@...el.com>,
"corbet@....net" <corbet@....net>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"ardb@...nel.org" <ardb@...nel.org>,
"kraxel@...hat.com" <kraxel@...hat.com>,
"dovmurik@...ux.ibm.com" <dovmurik@...ux.ibm.com>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"Dhaval.Giani@....com" <Dhaval.Giani@....com>,
"michael.day@....com" <michael.day@....com>,
"pavankumar.paluri@....com" <pavankumar.paluri@....com>,
"David.Kaplan@....com" <David.Kaplan@....com>,
"Reshma.Lal@....com" <Reshma.Lal@....com>,
"Jeremy.Powell@....com" <Jeremy.Powell@....com>,
"sathyanarayanan.kuppuswamy@...ux.intel.com"
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
"alexander.shishkin@...ux.intel.com"
<alexander.shishkin@...ux.intel.com>,
"thomas.lendacky@....com" <thomas.lendacky@....com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"dgilbert@...hat.com" <dgilbert@...hat.com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"dinechin@...hat.com" <dinechin@...hat.com>,
"linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
"berrange@...hat.com" <berrange@...hat.com>,
"mst@...hat.com" <mst@...hat.com>, "tytso@....edu" <tytso@....edu>,
"jikos@...nel.org" <jikos@...nel.org>,
"joro@...tes.org" <joro@...tes.org>,
"leon@...nel.org" <leon@...nel.org>,
"richard.weinberger@...il.com" <richard.weinberger@...il.com>,
"lukas@...ner.de" <lukas@...ner.de>,
"jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
"cdupontd@...hat.com" <cdupontd@...hat.com>,
"jasowang@...hat.com" <jasowang@...hat.com>,
"sameo@...osinc.com" <sameo@...osinc.com>,
"bp@...en8.de" <bp@...en8.de>,
"security@...nel.org" <security@...nel.org>,
Andrew Bresticker <abrestic@...osinc.com>,
Rajnesh Kanwal <rkanwal@...osinc.com>,
Dylan Reid <dylan@...osinc.com>,
Ravi Sahita <ravi@...osinc.com>
Subject: Re: [PATCH] docs: security: Confidential computing intro and threat
model
On 4/26/23 10:51 AM, Sean Christopherson wrote:
> On Wed, Apr 26, 2023, Carlos Bilbao wrote:
>> Hello Sean,
>>
>> On 4/26/23 8:32 AM, Reshetova, Elena wrote:
>>> Hi Sean,
>>>
>>> Thank you for your review! Please see my comments inline.
>>>
>>>> On Mon, Mar 27, 2023, Carlos Bilbao wrote:
>
> ...
>
>>>>> 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.
>>>>
>>>
>>> Same
>>>
>>
>> Personally, I think it's reasonable to mention SEV/SEV-ES in the context of
>> confidential computing and acknowledge their relevance in this area.
>>
>> But there is no mention to SEV or SEV-ES in this draft. And the document we
>> reference there covers AMD-SNP, which provides integrity.
>
> ...
>
>>>>> +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.
>>
>> Again, nobody mentioned SEV/SEV-ES here.
>
> Yes, somebody did. Unless your dictionary has a wildly different definition for
> "all".
>
> : +Overview and terminology
> : +========================
> : +
> : +Confidential Cloud Computing (CoCo) refers to a set of HW and SW
> : +virtualization technologies that allow Cloud Service Providers (CSPs) to
> : +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).
> : +
> : +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, as well as some additional mechanisms to control
> : +guest-host page mapping. More details on the x86-specific solutions can be
> : +found in
>
> This document is named confidential-computing.rst, not tdx-and-snp.rst. Not
> explicitly mentioning SEV doesn't magically warp reality to make descriptions like
> this one from security/secrets/coco.rst disappear:
>
> Introduction
> ============
>
> Confidential Computing (coco) hardware such as AMD SEV (Secure Encrypted
> Virtualization) allows guest owners to inject secrets into the VMs
> memory without the host/hypervisor being able to read them.
>
> My complaint about this document being too Intel/AMD centric isn't that it doesn't
> mention other implementations, it's that the doc describes CoCo purely from the
> narrow viewpoint of Intel TDX and AMD SNP, and to be blunt, reads like a press
> release and not an objective overview of CoCo.
Be specific about the parts of the document that you feel are too
AMD/Intel centric, and we will correct them.
Thanks,
Carlos
Powered by blists - more mailing lists