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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9021d861-cde6-a51a-7d8c-b3f67eaa01d8@amd.com>
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ