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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D7462C433EF for ; Fri, 19 Nov 2021 23:33:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 077196B0071; Fri, 19 Nov 2021 18:33:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0270D6B0072; Fri, 19 Nov 2021 18:33:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E0A836B0073; Fri, 19 Nov 2021 18:33:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0035.hostedemail.com [216.40.44.35]) by kanga.kvack.org (Postfix) with ESMTP id D3E046B0071 for ; Fri, 19 Nov 2021 18:33:24 -0500 (EST) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 943CB181CA084 for ; Fri, 19 Nov 2021 23:33:14 +0000 (UTC) X-FDA: 78827283108.03.BBEF467 Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) by imf05.hostedemail.com (Postfix) with ESMTP id 847AF5092ED1 for ; Fri, 19 Nov 2021 23:33:11 +0000 (UTC) Received: by mail-qt1-f173.google.com with SMTP id z9so10966561qtj.9 for ; Fri, 19 Nov 2021 15:33:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=YIQtmzLjEsgeZMQMOnkMzRwMWgRyVXZoeNdlFrk18qs=; b=NLLz2U5cbYEoorMYBXQrK8g/0dsQGOOIzTFzpIoM82ai9sEhm8aVRw+/BSYzFL+689 BulZ2pbNGnI/4bphyGwK+LCcpSosFvZ+rw35XZRx6YXpkIQx8YxHYTN+q0oXMOqAVENc XB4JnHls4dkr5k7ZheHEl44EItXxSWqm6lSNgR62w1dbRoTG5C7zEC2oAW/D2bw78pDc zD/7I+T9RhLwq2MRwjtPcowgD2liuh3dxi/fvdWK1tLAharf0byCKhzAKJvZVM/E9sdk fVUUoRlZxW54VP8R/sKiLNvFzSEHme73UtzJ9W/Y3cYmh49+bmuoMo8qaW396gxyiZ79 6rZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=YIQtmzLjEsgeZMQMOnkMzRwMWgRyVXZoeNdlFrk18qs=; b=DfEj3ppiz84SBntT4NRhTIo0vMRx3Gb0LA6XX4wB7eA/azNU+//v5DsUN+od9un3SV Ilmu/6+FmUTB3bopgkuN+2hj7P4bSMR4UE5b4i/EeVGyqHdeVm78kK9R8RXOVbtY2MD8 htLFTfNsp3TgSrkei135aE6PZ2MLVc4C6hhPDrswfqR0B37A0BAiFU55hmB6+g6a2lLe hmHaufdM9j67RQILwpQ4I2Wwk6884hczRPLbAZCp7eeEm5T7HHXGWVYP1MXmouZLMgCh FPZUiLg9wUTokKE1ROQbx+BoSeFHLoJLwV1dFNug0DvEGpxk4UzaQzCvmocAIv2YE5DC fWfg== X-Gm-Message-State: AOAM5327GvH9GgzmsdTQOQYTlFVRqId8AIh91AQxcPhk8Xux2HuudIjG ujHkox04E1kIxMBBOZ6FaN+UtQ== X-Google-Smtp-Source: ABdhPJyxRDjxrzpShk1yUcPpFaeAg/9+/FV8kt7sx9ISnNgpRPG9gnZ2XXj45zOthyEGjNn5VI7NlA== X-Received: by 2002:a05:622a:449:: with SMTP id o9mr10355315qtx.158.1637364793514; Fri, 19 Nov 2021 15:33:13 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-113-129.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.113.129]) by smtp.gmail.com with ESMTPSA id s20sm626369qtc.75.2021.11.19.15.33.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Nov 2021 15:33:12 -0800 (PST) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1moDNY-00CyxZ-6v; Fri, 19 Nov 2021 19:33:12 -0400 Date: Fri, 19 Nov 2021 19:33:12 -0400 From: Jason Gunthorpe To: Sean Christopherson Cc: David Hildenbrand , Chao Peng , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, qemu-devel@nongnu.org, Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Yu Zhang , "Kirill A . Shutemov" , luto@kernel.org, john.ji@intel.com, susie.li@intel.com, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com Subject: Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST Message-ID: <20211119233312.GO876299@ziepe.ca> References: <20211119134739.20218-1-chao.p.peng@linux.intel.com> <20211119134739.20218-2-chao.p.peng@linux.intel.com> <20211119151943.GH876299@ziepe.ca> <20211119194746.GM876299@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 847AF5092ED1 X-Stat-Signature: 3qaotazgxjzwq1zoupe8aopxp4s5tpgy Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=ziepe.ca header.s=google header.b=NLLz2U5c; spf=pass (imf05.hostedemail.com: domain of jgg@ziepe.ca designates 209.85.160.173 as permitted sender) smtp.mailfrom=jgg@ziepe.ca; dmarc=none X-HE-Tag: 1637364791-760094 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Nov 19, 2021 at 10:21:39PM +0000, Sean Christopherson wrote: > On Fri, Nov 19, 2021, Jason Gunthorpe wrote: > > On Fri, Nov 19, 2021 at 07:18:00PM +0000, Sean Christopherson wrote: > > > No ideas for the kernel API, but that's also less concerning since > > > it's not set in stone. I'm also not sure that dedicated APIs for > > > each high-ish level use case would be a bad thing, as the semantics > > > are unlikely to be different to some extent. E.g. for the KVM use > > > case, there can be at most one guest associated with the fd, but > > > there can be any number of VFIO devices attached to the fd. > > > > Even the kvm thing is not a hard restriction when you take away > > confidential compute. > > > > Why can't we have multiple KVMs linked to the same FD if the memory > > isn't encrypted? Sure it isn't actually useful but it should work > > fine. > > Hmm, true, but I want the KVM semantics to be 1:1 even if memory > isn't encrypted. That is policy and it doesn't belong hardwired into the kernel. Your explanation makes me think that the F_SEAL_XX isn't defined properly. It should be a userspace trap door to prevent any new external accesses, including establishing new kvms, iommu's, rdmas, mmaps, read/write, etc. > It's not just avoiding the linked list, there's a trust element as > well. E.g. in the scenario where a device can access a confidential > VM's encrypted private memory, the guest is still the "owner" of the > memory and needs to explicitly grant access to a third party, > e.g. the device or perhaps another VM. Authorization is some other issue - the internal kAPI should be able to indicate it is secured memory and the API user should do whatever dance to gain access to it. Eg for VFIO ask the realm manager to associate the pci_device with the owner realm. Jason