From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1568BC77B73 for ; Thu, 27 Apr 2023 17:21:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243906AbjD0RU6 (ORCPT ); Thu, 27 Apr 2023 13:20:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32850 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243741AbjD0RUz (ORCPT ); Thu, 27 Apr 2023 13:20:55 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3F5CA4C03 for ; Thu, 27 Apr 2023 10:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1682616002; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aPZaawwQwmja+K3dcGcTuaq8agrRF4dPj3IVyzF/XkQ=; b=hrnFYJl8rrIIf/fkaiSiUHas72VAoaSbbPr1Y+8m1qE2l5YGE5koRuS7+weFC4+yPPCLUI bwNeohM7qVRHvrFGK7Fb59yOdA2zOxtxvssO/+h3pnLhZTchALEtzIBktPrVFCMGa+bMsu rDaR2de0dKalckxl5SYYvTiI5Ok9nYg= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-515-xZkJf_KzMzajX84VG0-D0Q-1; Thu, 27 Apr 2023 13:20:00 -0400 X-MC-Unique: xZkJf_KzMzajX84VG0-D0Q-1 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-3f1763fac8bso56309505e9.1 for ; Thu, 27 Apr 2023 10:20:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682615999; x=1685207999; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=aPZaawwQwmja+K3dcGcTuaq8agrRF4dPj3IVyzF/XkQ=; b=T9uh0yLZFWktDXM5ksyzGK/lECzXdcc9LzGygyXRLNV6Ez+OQfRcvTRZGcdKu3Yjn+ oETDJdpMW9YEo1AS2k3ReAbofOv8EogfhwgfgVAmTkisb+N/i80+4BmPOeNdDLGpaeae Jg0tEdHkQDwzHquftNTuvv2tkKDbB5Zz+BZ/7YiGWwoDq9xOqlVQhFbAvZb75arT1zk6 fh6gB/rsdjg/ZasRgFv0GRtW/7myEONKEsMgbMqxcNBNH2R5iXkjHMgzDJ4wxNGtx50Z 7YVR4+Sl6VSk9VXBowIh58NUfPsBmm6a8OvQ15PUE5Dp75Avxp9AYtoLY1mk1WNUOZ+2 Sl9w== X-Gm-Message-State: AC+VfDww3Co2coS46+VxzrdiwVyVuluIQESL0gW4WwT0VNAh6aoFQ2tu v/YzEig55GiJMATbgbf5uElEegv6uekwNpaGfEAQwe5svyWxnaT2a55OXHpOr8AlaHUFWxeXOQm JncVAYsYq0sq25wPX7Cxcb9Xo X-Received: by 2002:a1c:7211:0:b0:3f1:728a:1881 with SMTP id n17-20020a1c7211000000b003f1728a1881mr2052010wmc.31.1682615999325; Thu, 27 Apr 2023 10:19:59 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ70FFgxaq7kngAV3kmqtfIdd11f8yMp/CFv4NyF+1cHylAzDbnw4IznX9hsPqVdLe7DOiNRfg== X-Received: by 2002:a1c:7211:0:b0:3f1:728a:1881 with SMTP id n17-20020a1c7211000000b003f1728a1881mr2051980wmc.31.1682615998938; Thu, 27 Apr 2023 10:19:58 -0700 (PDT) Received: from redhat.com ([2.52.19.183]) by smtp.gmail.com with ESMTPSA id n20-20020a7bc5d4000000b003f17b96793dsm25084430wmk.37.2023.04.27.10.19.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Apr 2023 10:19:58 -0700 (PDT) Date: Thu, 27 Apr 2023 13:19:52 -0400 From: "Michael S. Tsirkin" To: James Bottomley Cc: "Reshetova, Elena" , "Christopherson, , Sean" , Carlos Bilbao , "corbet@lwn.net" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "ardb@kernel.org" , "kraxel@redhat.com" , "dovmurik@linux.ibm.com" , "dave.hansen@linux.intel.com" , "Dhaval.Giani@amd.com" , "michael.day@amd.com" , "pavankumar.paluri@amd.com" , "David.Kaplan@amd.com" , "Reshma.Lal@amd.com" , "Jeremy.Powell@amd.com" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "alexander.shishkin@linux.intel.com" , "thomas.lendacky@amd.com" , "tglx@linutronix.de" , "dgilbert@redhat.com" , "gregkh@linuxfoundation.org" , "dinechin@redhat.com" , "linux-coco@lists.linux.dev" , "berrange@redhat.com" , "tytso@mit.edu" , "jikos@kernel.org" , "joro@8bytes.org" , "leon@kernel.org" , "richard.weinberger@gmail.com" , "lukas@wunner.de" , "cdupontd@redhat.com" , "jasowang@redhat.com" , "sameo@rivosinc.com" , "bp@alien8.de" , "security@kernel.org" , Andrew Bresticker , Rajnesh Kanwal , Dylan Reid , Ravi Sahita Subject: Re: [PATCH] docs: security: Confidential computing intro and threat model Message-ID: <20230427131542-mutt-send-email-mst@kernel.org> References: <20230327141816.2648615-1-carlos.bilbao@amd.com> <7502e1af0615c08167076ff452fc69ebf316c730.camel@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 27, 2023 at 09:18:08AM -0400, James Bottomley wrote: > I think the problem is that the tenor of the document is that the CSP > should be seen as the enemy of the tenant. Whereas all CSP's want to be > seen as the partner of the tenant (admittedly so they can upsell > services). In particular, even if you adopt (b) there are several > reasons why you'd use confidential computing: > > 1. Protection from other tenants who break containment in the cloud. > These tenants could exfiltrate data from Non-CoCo VMs, but likely > would be detected before they had time to launch an attack using > vulnerabilities in the current linux device drivers. > 2. Legal data security.  There's a lot of value in a CSP being able > to make the legal statement that it does not have access to a > customer data because of CoCo. > 3. Insider threats (bribe a CSP admin employee).  This one might get > as far as trying to launch an attack on a CoCo VM, but having > checks at the CSP to detect and defeat this would work instead of > every insider threat having to be defeated inside the VM. And generally, all these are instances of adopting a zero trust architecture, right? Many CSPs have no need to access VM memory so they would rather not have the ability. -- MST