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 2DB19C43217 for ; Thu, 17 Feb 2022 19:10:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3FA5C6B008C; Thu, 17 Feb 2022 14:10:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3811C6B0092; Thu, 17 Feb 2022 14:10:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1FB358D0001; Thu, 17 Feb 2022 14:10:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 0A33A6B008C for ; Thu, 17 Feb 2022 14:10:05 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id C935E120126 for ; Thu, 17 Feb 2022 19:10:04 +0000 (UTC) X-FDA: 79153211928.02.EA250A6 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf22.hostedemail.com (Postfix) with ESMTP id 032DFC0006 for ; Thu, 17 Feb 2022 19:10:03 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id F3AA3B8244F; Thu, 17 Feb 2022 19:10:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 68A45C340EB; Thu, 17 Feb 2022 19:09:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1645125000; bh=ak4f1IR3JDauRmqw+Ocnj7LciaJgX2pj5SekEDDFUWI=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=lvU0WOO7K9Hu3jpQEoQdykFWOeJkwK5YSzfr3pjVbg1el5417PRg02Pick+MlEGpN MEpDmxkNmZrSTji+4ogBj2o2IbCelGEu036iVOdZXEkPdHdZ2glKe6ogosYUm5F9HT gDM/BdAuWREwPXQ95pWYd4GdFZ3+k/DOUtEbXcTSSBRj9CrZcC43BdffBWtNxM8YeC 6yq8iOdFwmjojXKG9BCONmQDeR8kW5H9TOY63x2JbOZ3SsxVOEuNlnbFSzLO8rRtJ9 B6NnTxNVZnUWBrpO7D/xkCA/CAbXn4aQruPnMT1/fPRsSMe7g5lExjyihShVILWY7G jcgxVgwJMEg+g== Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id 22D2E27C0054; Thu, 17 Feb 2022 14:09:57 -0500 (EST) Received: from imap48 ([10.202.2.98]) by compute5.internal (MEProxy); Thu, 17 Feb 2022 14:09:58 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrjeekgdduudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdetnhgu hicunfhuthhomhhirhhskhhifdcuoehluhhtoheskhgvrhhnvghlrdhorhhgqeenucggtf frrghtthgvrhhnpedthfehtedtvdetvdetudfgueeuhfdtudegvdelveelfedvteelfffg fedvkeegfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpegrnhguhidomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqudduiedukeeh ieefvddqvdeifeduieeitdekqdhluhhtoheppehkvghrnhgvlhdrohhrgheslhhinhhugi drlhhuthhordhush X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3BF2F21E006E; Thu, 17 Feb 2022 14:09:56 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4778-g14fba9972e-fm-20220217.001-g14fba997 Mime-Version: 1.0 Message-Id: <2ca78dcb-61d9-4c9d-baa9-955b6f4298bb@www.fastmail.com> In-Reply-To: <20220217130631.GB32679@chaop.bj.intel.com> References: <20220118132121.31388-1-chao.p.peng@linux.intel.com> <20220118132121.31388-2-chao.p.peng@linux.intel.com> <619547ad-de96-1be9-036b-a7b4e99b09a6@kernel.org> <20220217130631.GB32679@chaop.bj.intel.com> Date: Thu, 17 Feb 2022 11:09:35 -0800 From: "Andy Lutomirski" To: "Chao Peng" Cc: "kvm list" , "Linux Kernel Mailing List" , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, qemu-devel@nongnu.org, "Linux API" , "Paolo Bonzini" , "Jonathan Corbet" , "Sean Christopherson" , "Vitaly Kuznetsov" , "Wanpeng Li" , "Jim Mattson" , "Joerg Roedel" , "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "the arch/x86 maintainers" , "H. Peter Anvin" , "Hugh Dickins" , "Jeff Layton" , "J . Bruce Fields" , "Andrew Morton" , "Yu Zhang" , "Kirill A. Shutemov" , "Nakajima, Jun" , "Dave Hansen" , "Andi Kleen" , "David Hildenbrand" Subject: Re: [PATCH v4 01/12] mm/shmem: Introduce F_SEAL_INACCESSIBLE Content-Type: text/plain X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 032DFC0006 X-Rspam-User: Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=lvU0WOO7; spf=pass (imf22.hostedemail.com: domain of luto@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=luto@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Stat-Signature: xfawestgbzk6f5azhhheeu85xptq9e7p X-HE-Tag: 1645125003-737447 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 Thu, Feb 17, 2022, at 5:06 AM, Chao Peng wrote: > On Fri, Feb 11, 2022 at 03:33:35PM -0800, Andy Lutomirski wrote: >> On 1/18/22 05:21, Chao Peng wrote: >> > From: "Kirill A. Shutemov" >> > >> > Introduce a new seal F_SEAL_INACCESSIBLE indicating the content of >> > the file is inaccessible from userspace through ordinary MMU access >> > (e.g., read/write/mmap). However, the file content can be accessed >> > via a different mechanism (e.g. KVM MMU) indirectly. >> > >> > It provides semantics required for KVM guest private memory support >> > that a file descriptor with this seal set is going to be used as the >> > source of guest memory in confidential computing environments such >> > as Intel TDX/AMD SEV but may not be accessible from host userspace. >> > >> > At this time only shmem implements this seal. >> > >> >> I don't dislike this *that* much, but I do dislike this. F_SEAL_INACCESSIBLE >> essentially transmutes a memfd into a different type of object. While this >> can apparently be done successfully and without races (as in this code), >> it's at least awkward. I think that either creating a special inaccessible >> memfd should be a single operation that create the correct type of object or >> there should be a clear justification for why it's a two-step process. > > Now one justification maybe from Stever's comment to patch-00: for ARM > usage it can be used with creating a normal memfd, (partially)populate > it with initial guest memory content (e.g. firmware), and then > F_SEAL_INACCESSIBLE it just before the first time lunch of the guest in > KVM (definitely the current code needs to be changed to support that). Except we don't allow F_SEAL_INACCESSIBLE on a non-empty file, right? So this won't work. In any case, the whole confidential VM initialization story is a bit buddy. From the earlier emails, it sounds like ARM expects the host to fill in guest memory and measure it. From my recollection of Intel's scheme (which may well be wrong, and I could easily be confusing it with SGX), TDX instead measures what is essentially a transcript of the series of operations that initializes the VM. These are fundamentally not the same thing even if they accomplish the same end goal. For TDX, we unavoidably need an operation (ioctl or similar) that initializes things according to the VM's instructions, and ARM ought to be able to use roughly the same mechanism. Also, if we ever get fancy and teach the page allocator about memory with reduced directmap permissions, it may well be more efficient for userspace to shove data into a memfd via ioctl than it is to mmap it and write the data.