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 DE73FC433EF for ; Mon, 11 Apr 2022 15:08:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 276246B0072; Mon, 11 Apr 2022 11:08:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1FEC76B0073; Mon, 11 Apr 2022 11:08:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0786D6B0074; Mon, 11 Apr 2022 11:08:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0185.hostedemail.com [216.40.44.185]) by kanga.kvack.org (Postfix) with ESMTP id EA5756B0072 for ; Mon, 11 Apr 2022 11:08:53 -0400 (EDT) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A9C9BA867B for ; Mon, 11 Apr 2022 15:08:53 +0000 (UTC) X-FDA: 79344930546.31.379A3D5 Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by imf07.hostedemail.com (Postfix) with ESMTP id 1F0B940004 for ; Mon, 11 Apr 2022 15:08:52 +0000 (UTC) Received: by mail-lf1-f43.google.com with SMTP id y32so27204840lfa.6 for ; Mon, 11 Apr 2022 08:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=SZ3/Vx+1Q7uH45Ete1zY0f2BZJWVMOSE6BEs5zWCYbs=; b=7DIUdDw1bDVY/1pX9CrYKqoUnxn4Af2165TByD3u5HZ0iXmIdkyeDLerqJVS4ILYb2 sr8EaHNWEoVQlow3SdmLYTkP5xN8dgvPftKQlE2GzWppJ9Nm1Jc8ZkbxJeZp/XQcv+bm CkITSbBdcYbYkEIbRjUo+wMmeMYCl/ckl8Eyh5jpmDByZr90ijXMmjL2GuwmjJqoSc6X 41HpTTObRQn2DziTHtTZKAPeR3G4oO4JnMRiHaWm+nxgPN2SgqBjtuDslRAMsgbobCqJ zrEUAd863LfUu4IdojsoK+HRzJ1QfBeJabFS3cJ9rTqFAAPFDxSzIUbnYMV1zoLxx+KI BBkg== 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=SZ3/Vx+1Q7uH45Ete1zY0f2BZJWVMOSE6BEs5zWCYbs=; b=k71+7fnTWwQjSl23rN1DwIKV3rX98xhb7hZkD8Jj44NTZoudjssFWdg8FiO3YSVY2D YTCYArNV1Q9jSQSOmxbM9+Ub+OT2NTh77+tlnV2UmRJgNz15YF8BOk7AeanH2QPZCCnc dIS1oRt5dpp+Zts33L49O49QlVjCYLDJ+16Ps7jMDdDgFvxHtLZ+A06/2eq2uRPt5Hrq TYpk9mX0gBRCPHZUBSDdBI7aba+s80khjgf74PIx2NS2EXvo9Gp8wUQ97GIaJF1Fbtxi rFG7rfeNTxHnffVGuKmIjLUVoyGze1rURAAmBBYjeE5cRiiEXq8mWpMyKtXh4NW7Ko/b GR5A== X-Gm-Message-State: AOAM532lzRa8T3++MaV9FvsghVlwhuGxjAjExJcmadiAN5n/E03fXQen O8DUvMQOsxegIvgVNX06XhWCNg== X-Google-Smtp-Source: ABdhPJwVzRe0aqmUWVOSiTlNptfcMMnBCa3LaWdYU4CM/MHAyK3juuV+XEpH4cZF1tu2LetUDByrEw== X-Received: by 2002:a05:6512:3f29:b0:450:ac79:77dd with SMTP id y41-20020a0565123f2900b00450ac7977ddmr21705662lfa.301.1649689731304; Mon, 11 Apr 2022 08:08:51 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id t2-20020a05651c204200b0024b4bc5d324sm1197193ljo.79.2022.04.11.08.08.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Apr 2022 08:08:50 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id 41CC4103CE0; Mon, 11 Apr 2022 18:10:23 +0300 (+03) Date: Mon, 11 Apr 2022 18:10:23 +0300 From: "Kirill A. Shutemov" To: Chao Peng Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, qemu-devel@nongnu.org, Paolo Bonzini , Jonathan Corbet , Sean Christopherson , 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 , Mike Rapoport , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , "Kirill A . Shutemov" , luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, david@redhat.com Subject: Re: [PATCH v5 01/13] mm/memfd: Introduce MFD_INACCESSIBLE flag Message-ID: <20220411151023.4nx34pxyg5amj44m@box.shutemov.name> References: <20220310140911.50924-1-chao.p.peng@linux.intel.com> <20220310140911.50924-2-chao.p.peng@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220310140911.50924-2-chao.p.peng@linux.intel.com> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 1F0B940004 X-Rspam-User: Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=shutemov-name.20210112.gappssmtp.com header.s=20210112 header.b=7DIUdDw1; dmarc=none; spf=none (imf07.hostedemail.com: domain of kirill@shutemov.name has no SPF policy when checking 209.85.167.43) smtp.mailfrom=kirill@shutemov.name X-Stat-Signature: kqie6oasmhh4hqai4c6j1xzm9ppxtkm6 X-HE-Tag: 1649689732-837651 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, Mar 10, 2022 at 10:08:59PM +0800, Chao Peng wrote: > From: "Kirill A. Shutemov" > > Introduce a new memfd_create() flag indicating the content of the > created memfd 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 flag 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. > > Since page migration/swapping is not yet supported for such usages > so these pages are currently marked as UNMOVABLE and UNEVICTABLE > which makes them behave like long-term pinned pages. > > The flag can not coexist with MFD_ALLOW_SEALING, future sealing is > also impossible for a memfd created with this flag. > > At this time only shmem implements this flag. > > Signed-off-by: Kirill A. Shutemov > Signed-off-by: Chao Peng > --- > include/linux/shmem_fs.h | 7 +++++ > include/uapi/linux/memfd.h | 1 + > mm/memfd.c | 26 +++++++++++++++-- > mm/shmem.c | 57 ++++++++++++++++++++++++++++++++++++++ > 4 files changed, 88 insertions(+), 3 deletions(-) > > diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h > index e65b80ed09e7..2dde843f28ef 100644 > --- a/include/linux/shmem_fs.h > +++ b/include/linux/shmem_fs.h > @@ -12,6 +12,9 @@ > > /* inode in-kernel data */ > > +/* shmem extended flags */ > +#define SHM_F_INACCESSIBLE 0x0001 /* prevent ordinary MMU access (e.g. read/write/mmap) to file content */ > + > struct shmem_inode_info { > spinlock_t lock; > unsigned int seals; /* shmem seals */ > @@ -24,6 +27,7 @@ struct shmem_inode_info { > struct shared_policy policy; /* NUMA memory alloc policy */ > struct simple_xattrs xattrs; /* list of xattrs */ > atomic_t stop_eviction; /* hold when working on inode */ > + unsigned int xflags; /* shmem extended flags */ > struct inode vfs_inode; > }; > AFAICS, only two bits of 'flags' are used. And that's very strange that VM_ flags are used for the purpose. My guess that someone was lazy to introduce new constants for this. I think we should fix this: introduce SHM_F_LOCKED and SHM_F_NORESERVE alongside with SHM_F_INACCESSIBLE and stuff them all into info->flags. It also makes shmem_file_setup_xflags() go away. -- Kirill A. Shutemov