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

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <45a798dd-af8b-a162-adc5-71237b33b8d1@intel.com>
Date:   Wed, 26 Apr 2023 13:12:43 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Carlos Bilbao <carlos.bilbao@....com>,
        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 12:21, Carlos Bilbao wrote:
>>   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.

That's kinda not the point.

Confidential computing covers a *REALLY* wide swath of technologies,
even on just AMD and Intel: SGX, SEV{,-ES,SNP}, MKTME, TDX.

But this document is talking about one *VERY* *SPECIFIC* thing: VMs
running under SEV-SNP or TDX and in a very specific environment: CSPs.
Also, not even *ALL* CSPs, a subset of CSPs.  You're tossing out a huge
chunk of the confidential computing world without acknowledging it.

I don't have any great suggestions on what you call this subset.  Maybe
you get an ack from the CoVE folks:

> https://lore.kernel.org/all/20230419221716.3603068-1-atishp@rivosinc.com/

and call it
tdx-and-snp-and-cove-at-some-random-unnamed-big-fancy-csps-threat-model.rst.
 Just add an -and-foo each time a new hardware vendor shows up until
someone smarter than us finds a good name.

But I do think the difficulty here is in drawing that "line in the sand"
I was talking about.  You're trying to make the argument that once you
get hardware support for:

1. Increased guest data and state confidentiality from a VMM
2. Better guest data and state integrity in the face of VMM modification
3. More tightly controlled guest interrupt injection
4. Some additional mechanisms to control guest-host page mapping.

... then you need all this *other* stuff that the document talks about.

I think #3 and #4 are really just (SEV and TDX) implementation details.
I can certainly imagine a sane architecture without all of x86's warts
that doesn't care much about #3.

I think I know what #4 is talking about, but it's too handwavy for me to
even offer any improvements.  I actually think #4 is just a subset of
integrity protection: make sure that the same data that the guest puts
in memory at a guest physical address comes back out at that address
later.  SEV and TDX implement that by preventing the host from remapping
guest physical address space willy nilly, but it's just integrity
protection by another name.