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 6714AEB64DB for ; Sat, 17 Jun 2023 18:15:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346385AbjFQSPh (ORCPT ); Sat, 17 Jun 2023 14:15:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43634 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231822AbjFQSPe (ORCPT ); Sat, 17 Jun 2023 14:15:34 -0400 Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3DADD1737 for ; Sat, 17 Jun 2023 11:15:33 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-4f611ac39c5so2499051e87.2 for ; Sat, 17 Jun 2023 11:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf.com; s=google; t=1687025731; x=1689617731; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=7Dsw7nAhARw8huKJiFcVT3g3RXe09FTUVjhq7l/Iznk=; b=VWZAosjutRNS4RszthwOli914gKOptEXZa4eZ5SwV/+PgVaATfd/NAwSbwkp2X/B+B UsWhfOCT6R3PMY+waiHqFwJOIhbTHpzgA8g5DLs8l8nepobX5nR6l/GBRdrXWwLQyf05 IzAD3kEWnvQgMNDBM95vGaMOMKgdhRyD5FOqr6sA5WpKr19y0QX9BVSLIY03cDC9oNxH 8/pRAB1vBtT97ruYFF9PW6Se2JDc1YYWs0dtdypBzTtktYPIbobwAXLH1EYjie2hnvy1 BosMqAPawNTICw1gO9VUaoE2s/6blYmmoYwx0KoIpv2kUV+VcxxkF7uXkbjsE1m7H0p+ n22A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687025731; x=1689617731; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7Dsw7nAhARw8huKJiFcVT3g3RXe09FTUVjhq7l/Iznk=; b=ZPcKzKPWP4NcL6H9CtjHVyb2KGxSi09NoXXRWwwuCbVLwml9pni7mCKcJyGvp3J4Uk fPD3GvHqW6JbvM8wEJRDYlvW6Deb3jGy89x4hsB3TT/4gjmpfy0bXoxYK3UcI8p1K1yh fSRXjMVvhAnefsrDQx+M3iAkxqdGoHGh1hs2zGdpPDYxtGr/lidGYDFOZaazV2apmU6H iabiDMiuHFnFtg0gaib7K0rq8bFDWhKjqSdSj7px5dDB8uX1V4rgrggl7xzNY9tGKG09 9NPIw3Xbn0rFYmGGkwlGU4yaxdcfha26XYFvBJk6HRaQ1QSjhbaP+1MinzYCsZFCfQIT K8sQ== X-Gm-Message-State: AC+VfDxV8WspEM+cuL5ZYyHKOxLF2i12Nz/DOrBM7e1b9x+MknkWNWC1 mojCU7zwisI9o7elZRC7vh83JQ== X-Google-Smtp-Source: ACHHUZ6aSxu1poHVXap/a1Nbx1PeH9YaODmzO7ZFGZ7Lsf9tYpTQaaJmZYzW70eLvrIH2lA9NQHnUw== X-Received: by 2002:a19:5e02:0:b0:4f7:69b9:fa07 with SMTP id s2-20020a195e02000000b004f769b9fa07mr3347470lfb.45.1687025731242; Sat, 17 Jun 2023 11:15:31 -0700 (PDT) Received: from ?IPV6:2a02:a31b:2041:8680:1268:c8b0:5fcc:bf13? ([2a02:a31b:2041:8680:1268:c8b0:5fcc:bf13]) by smtp.gmail.com with ESMTPSA id v5-20020ac25605000000b004f3b3f5751bsm275240lfd.275.2023.06.17.11.15.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 17 Jun 2023 11:15:30 -0700 (PDT) Message-ID: <0fce3bf9-7100-6e4e-297e-32dffc875bcf@semihalf.com> Date: Sat, 17 Jun 2023 20:15:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: Re: [PATCH v2] docs: security: Confidential computing intro and threat model for x86 virtualization Content-Language: en-US To: Allen Webb , Sean Christopherson Cc: Elena Reshetova , Carlos Bilbao , Jason CJ Chen , "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" , "mst@redhat.com" , "tytso@mit.edu" , "jikos@kernel.org" , "joro@8bytes.org" , "leon@kernel.org" , "richard.weinberger@gmail.com" , "lukas@wunner.de" , "jejb@linux.ibm.com" , "cdupontd@redhat.com" , "jasowang@redhat.com" , "sameo@rivosinc.com" , "bp@alien8.de" , "security@kernel.org" , Larry Dewey , android-kvm@google.com, Dmitry Torokhov , Tomasz Nowicki , Grzegorz Jaszczyk , Patryk Duda References: <20230612164727.3935657-1-carlos.bilbao@amd.com> <001aa2ed-2f78-4361-451d-e31a4d4abaa0@semihalf.com> From: Dmytro Maluka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/16/23 17:16, Allen Webb wrote: > That extra context helps, so the hardening is on the side of the guest > kernel since the host kernel isn't trusted? > > My biggest concerns would be around situations where devices have > memory access for things like DMA. In such cases the guest would need > to be protected from the devices so bounce buffers or some limited > shared memory might need to be set up to facilitate these devices > without breaking the goals of pKVM. I'm assuming you are talking about cases when we want a host-owned device, e.g. a TPM from your example, to be able to DMA to the guest memory (please correct me if you mean something different). I think with pKVM it should be already possible to do securely and without extra hardening in the guest (modulo establishing trust between the guest and the TPM, which you mentioned, but that is needed anyway?). The hypervisor in any case ensures protection of the guest memory from the host devices DMA via IOMMU. Also the hypervisor allows the guest to explicitly share its memory pages with the host via a hypercall. Those shared pages, and only those, become accessible by the host devices DMA as well. P.S. I know that on chromebooks the TPM can't possibly do DMA. :) > The minimum starting point for something like this would be a shared > memory region visible to both the guest and the host. Given that it > should be possible to build communication primitives on top, but yes > ideally something like vsock or virtio would just work without > introducing risk of exploitation and typically the hypervisor is > trusted. Maybe this could be modeled as sibling to sibling > virtio/vsock?