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 AA63CC433F5 for ; Fri, 19 Nov 2021 22:22:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 24E616B0071; Fri, 19 Nov 2021 17:21:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1FDA96B0072; Fri, 19 Nov 2021 17:21:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C6BC6B0073; Fri, 19 Nov 2021 17:21:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0171.hostedemail.com [216.40.44.171]) by kanga.kvack.org (Postfix) with ESMTP id F12666B0071 for ; Fri, 19 Nov 2021 17:21:54 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id B7B6B8913B for ; Fri, 19 Nov 2021 22:21:44 +0000 (UTC) X-FDA: 78827102928.29.C651D95 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by imf13.hostedemail.com (Postfix) with ESMTP id 0F7D21052675 for ; Fri, 19 Nov 2021 22:21:42 +0000 (UTC) Received: by mail-pl1-f170.google.com with SMTP id b11so9154639pld.12 for ; Fri, 19 Nov 2021 14:21:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=BWddyG3YL6k7bG+TnBK28e//6M0bIbW4TSIkWYmJ/v8=; b=EuwLBJL7d8Z1+TfWgCR5KtCvEV67f5PIxvqG3aTGsd/eshhsU8erJhoGf0qFXRBYNK ojHHmODuu2mFpfgcCH9Mh7DUEoaZ86X30XwStlGJZNYWsNn9NL94sEru/vUg5Nbj4Ygk rg0O9yS0UoSLKIy+BYbkKCS7p6NG7AJKpFjEP2DFQyX8BBbyhzRWp+wRYVub/WiG1a4H EGDfKcdqN4CON4UFuLc4/wDhL1EAWBW4K279192TaFlRQ297QMSEKJ5/s8gtUr82qbLh G3wDAbAF+/UYwO1h3h+UwsxOj6qLscYU/yF0iX9FS4zA7l58NfcA9DyBK+/NK/quciN+ kONA== 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=BWddyG3YL6k7bG+TnBK28e//6M0bIbW4TSIkWYmJ/v8=; b=sJgIIdQqy07YRQ8Svd0hsezTCThcwheQuVsziwBoLl9si827gv3zwsyWGJaefBLBW/ hHBGo3xiRm59079zX5Y4/3Z9iGyNNXaT/FmsnnEc10N3YSHP5aO6962ABFXI2WVFJwo5 fsADNXMgDnrfPm7hYrl3Mt9pg2rZr3FIm5S5ROybxczD+Ug2ZMxVknJE8w/45RXZKPDt w+JLPl+9JR15GQgMXGsQ0YoCFkOgnijnD47TeaNHDQuQdSrVPhLebc7f4acUmy986Qtc 6vxTLg8wCpDMQGxPGh+okcZSJpu3i8u4DCWiHMEoXRM2BvtbfnRUulZOUOYqGPUhhMxN FSzA== X-Gm-Message-State: AOAM531VuWeepAzb9a7CrE9val1L5Ut5JkMskyhB05N/lgTKFfsNYeuI djNqJLjQDCwe53O3V+7DiSZ+Hg== X-Google-Smtp-Source: ABdhPJw5pCQ1lvi4R7CtbDaQGcOJnt0PSBvoK0mJGOtw9m+Psi5Ckwf4h+0YLOW3oeLbqYaNToVYnQ== X-Received: by 2002:a17:90b:1c81:: with SMTP id oo1mr3963147pjb.171.1637360503250; Fri, 19 Nov 2021 14:21:43 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id w17sm601647pfu.58.2021.11.19.14.21.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Nov 2021 14:21:42 -0800 (PST) Date: Fri, 19 Nov 2021 22:21:39 +0000 From: Sean Christopherson To: Jason Gunthorpe 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: 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: <20211119194746.GM876299@ziepe.ca> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 0F7D21052675 X-Stat-Signature: nm4jzf649uhcx8yrqsj9g9zs7xh8t7o5 Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=EuwLBJL7; spf=pass (imf13.hostedemail.com: domain of seanjc@google.com designates 209.85.214.170 as permitted sender) smtp.mailfrom=seanjc@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1637360502-978670 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, 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. Encrypting memory with a key that isn't available to the host is necessary to (mostly) remove the host kernel from the guest's TCB, but it's not necessary to remove host userspace from the TCB. KVM absolutely can and should be able to do that without relying on additional hardware/firmware. Ignoring attestation and whether or not the guest fully trusts the host kernel, there's value in preventing a buggy or compromised userspace from attacking/corrupting the guest by remapping guest memory or by mapping the same memory into multiple guests. > Supporting only one thing is just a way to avoid having a linked list > of clients to broadcast invalidations too - for instance by using a > standard notifier block... 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. That said, I'm certainly not dead set on having "guest" in the name, nor am I opposed to implementing multi-consumer support from the get-go so we don't end up with a mess later on. > Also, how does dirty tracking work on this memory? For KVM usage, KVM would provide the dirty bit info. No idea how VFIO or other use cases would work.