Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp779045pxb; Tue, 12 Apr 2022 13:14:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxRiQbhC1So1fRo4ebr1lFBkI0ZgipQR+R1fQ7yv6/lqRdsr7ffYUlVCapsFyg76pkXzD3M X-Received: by 2002:a05:6a00:23d2:b0:4fa:f262:719 with SMTP id g18-20020a056a0023d200b004faf2620719mr39972863pfc.4.1649794442214; Tue, 12 Apr 2022 13:14:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649794442; cv=none; d=google.com; s=arc-20160816; b=jhOB1UAfxUtkDAs/3vWygkSCi9KKbPy4fvZZGBL+1tpwMcZpjDHHND+ZQXOjB8VHnh esU7ZMKhnYFw9QDNrGOuLOoHM/wCB9f6YRY8lZ7QglYJqkHGsThTdHWkPi5S2bn8QP0T Ceum6Prc23DPpNfVSn54+cBY7cxup0oeU6Ckaple3LtBiLe28k2NA56HOWRhtIUYuUrG tQWKQKTKeJ0t/7EudErAwtz9k9orj7xP3HBeRv5Pnp0lURIXrbEatauiu5qFZE9dUWT0 R1PgTb7KVz+76KO2uaPCr0G95Frc4XceFWaf8bPblDeQPena0OEjZ/miLFUAT7WbRGu0 st7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=SZ3/Vx+1Q7uH45Ete1zY0f2BZJWVMOSE6BEs5zWCYbs=; b=T2inQYgrJfsO4AqrdmWU6sPoBH5Ne3EZK87nbJ7MWQaXGkYTz6RZPpiFM9aGiFTHTh QQU01YwKC/Dxw93EkP46u2YByZKLIuh7tMEGKpNpBB+r7hFdLK/Soz7YeI5OijfnZLtl oiUbWuVoi4QnFaVPQ7Bdi6C/lwz6JjTBwIu7U6pEMesIyNeS+mT5QgobOjInhwNgyn7t qq/imSMyFBbphDoQdziFHoFJw+HUgZY/Du8vKkmQROsRLUfvpeuuJBGpfAT0CSviwAJE VZzJJnaT/V2nUOVzUhdYEvidz6GFT+3TzRd91QSYNvQqO7b2EPPn6AQonMa4roL5V4h/ qX6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@shutemov-name.20210112.gappssmtp.com header.s=20210112 header.b=7DIUdDw1; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id k63-20020a628442000000b004fabe29f82bsi2047918pfd.316.2022.04.12.13.13.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 13:14:02 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@shutemov-name.20210112.gappssmtp.com header.s=20210112 header.b=7DIUdDw1; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 763265C366; Tue, 12 Apr 2022 12:59:22 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347637AbiDKPLK (ORCPT + 99 others); Mon, 11 Apr 2022 11:11:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35364 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234367AbiDKPLI (ORCPT ); Mon, 11 Apr 2022 11:11:08 -0400 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 31C4D2AE10 for ; Mon, 11 Apr 2022 08:08:53 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id u7so10107508lfs.8 for ; Mon, 11 Apr 2022 08:08:53 -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=KlWQNPGdN91RHAvtUQnWjqh61mp3E9Pn4XT3vjIUNO4KkBTERV7+NNsu/IJOsZHzw3 d9QYondPWDPPAP8R7d8GROndfA33yHLU2/Zq6MyFeKvZi7DYLcHNSEULdlRC2j2YE2fo k2dP5uLzgcONVDt/jpSB7SR8Q1Eg6OjoIheipOJe1IM8y5aIGFZ3zRArQuUtaLo1OgcV jOfCzliMH2ZVYO4TJQBM0uRc7IrzoYzD3PJu6wdW5MCuSqZBJ0qfJwvRB2FXmtnHyffD LbM0jSZTvN5NeSKaeTV0683PswwmiqmXI+nb4AEAqSChF+vIOlYM2/Tcr12rTd3aV8Dm TK9A== X-Gm-Message-State: AOAM5334JXv9A/Pu8PqsFM5gexOhOrM35dBH0s6wHPjtfrh2i7bMF8wB iDKqwhPXkOiYS3MvJr8YNSyJiw== 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-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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