From: Shivank Garg <shivankg@amd.com>
To: <seanjc@google.com>, <david@redhat.com>, <vbabka@suse.cz>,
<willy@infradead.org>, <akpm@linux-foundation.org>,
<shuah@kernel.org>, <pbonzini@redhat.com>, <brauner@kernel.org>,
<viro@zeniv.linux.org.uk>
Cc: <ackerleytng@google.com>, <paul@paul-moore.com>,
<jmorris@namei.org>, <serge@hallyn.com>, <pvorel@suse.cz>,
<bfoster@redhat.com>, <tabba@google.com>, <vannapurve@google.com>,
<chao.gao@intel.com>, <bharata@amd.com>, <nikunj@amd.com>,
<michael.day@amd.com>, <yan.y.zhao@intel.com>,
<Neeraj.Upadhyay@amd.com>, <thomas.lendacky@amd.com>,
<michael.roth@amd.com>, <aik@amd.com>, <jgg@nvidia.com>,
<kalyazin@amazon.com>, <peterx@redhat.com>, <shivankg@amd.com>,
<jack@suse.cz>, <rppt@kernel.org>, <hch@infradead.org>,
<cgzones@googlemail.com>, <ira.weiny@intel.com>,
<rientjes@google.com>, <roypat@amazon.co.uk>, <ziy@nvidia.com>,
<matthew.brost@intel.com>, <joshua.hahnjy@gmail.com>,
<rakie.kim@sk.com>, <byungchul@sk.com>, <gourry@gourry.net>,
<kent.overstreet@linux.dev>, <ying.huang@linux.alibaba.com>,
<apopple@nvidia.com>, <chao.p.peng@intel.com>,
<amit@infradead.org>, <ddutile@redhat.com>,
<dan.j.williams@intel.com>, <ashish.kalra@amd.com>,
<gshan@redhat.com>, <jgowans@amazon.com>, <pankaj.gupta@amd.com>,
<papaluri@amd.com>, <yuzhao@google.com>, <suzuki.poulose@arm.com>,
<quic_eberman@quicinc.com>, <aneeshkumar.kizhakeveetil@arm.com>,
<linux-fsdevel@vger.kernel.org>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>,
<linux-security-module@vger.kernel.org>, <kvm@vger.kernel.org>,
<linux-kselftest@vger.kernel.org>, <linux-coco@lists.linux.dev>
Subject: [RFC PATCH v8 1/7] security: Export anon_inode_make_secure_inode for KVM guest_memfd
Date: Wed, 18 Jun 2025 11:29:29 +0000 [thread overview]
Message-ID: <20250618112935.7629-2-shivankg@amd.com> (raw)
In-Reply-To: <20250618112935.7629-1-shivankg@amd.com>
KVM guest_memfd is implementing its own inodes to store metadata for
backing memory using a custom filesystem. This requires the ability to
allocate an anonymous inode with security context using
anon_inode_make_secure_inode().
As guest_memfd currently resides in the KVM module, we need to export this
symbol for use outside the core kernel. In the future, guest_memfd might be
moved to core-mm, at which point the symbols no longer would have to be
exported. When/if that happens is still unclear.
Signed-off-by: Shivank Garg <shivankg@amd.com>
---
The handling of the S_PRIVATE flag for these inodes was discussed
extensively ([1], [2])
My understanding [3], is that because KVM guest_memfd and secretmem
results in user-visible file descriptors, its inodes should not bypass
LSM security checks. Therefore, anon_inode_make_secure_inode() (as
implemented in this patch) correctly clears the S_PRIVATE flag
set by alloc_anon_inode() to ensure proper security policy enforcement.
[1] https://lore.kernel.org/all/b9e5fa41-62fd-4b3d-bb2d-24ae9d3c33da@redhat.com
[2] https://lore.kernel.org/all/cover.1748890962.git.ackerleytng@google.com
[3] https://lore.kernel.org/all/647ab7a4-790f-4858-acf2-0f6bae5b7f99@amd.com
fs/anon_inodes.c | 20 +++++++++++++++++---
include/linux/fs.h | 2 ++
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c
index e51e7d88980a..441fff40b55a 100644
--- a/fs/anon_inodes.c
+++ b/fs/anon_inodes.c
@@ -98,14 +98,26 @@ static struct file_system_type anon_inode_fs_type = {
.kill_sb = kill_anon_super,
};
-static struct inode *anon_inode_make_secure_inode(
+/**
+ * anon_inode_make_secure_inode - allocate an anonymous inode with security context
+ * @sb: [in] Superblock to allocate from
+ * @name: [in] Name of the class of the newfile (e.g., "secretmem")
+ * @context_inode:
+ * [in] Optional parent inode for security inheritance
+ *
+ * The function ensures proper security initialization through the LSM hook
+ * security_inode_init_security_anon().
+ *
+ * Return: Pointer to new inode on success, ERR_PTR on failure.
+ */
+struct inode *anon_inode_make_secure_inode(struct super_block *sb,
const char *name,
const struct inode *context_inode)
{
struct inode *inode;
int error;
- inode = alloc_anon_inode(anon_inode_mnt->mnt_sb);
+ inode = alloc_anon_inode(sb);
if (IS_ERR(inode))
return inode;
inode->i_flags &= ~S_PRIVATE;
@@ -118,6 +130,7 @@ static struct inode *anon_inode_make_secure_inode(
}
return inode;
}
+EXPORT_SYMBOL_GPL(anon_inode_make_secure_inode);
static struct file *__anon_inode_getfile(const char *name,
const struct file_operations *fops,
@@ -132,7 +145,8 @@ static struct file *__anon_inode_getfile(const char *name,
return ERR_PTR(-ENOENT);
if (make_inode) {
- inode = anon_inode_make_secure_inode(name, context_inode);
+ inode = anon_inode_make_secure_inode(anon_inode_mnt->mnt_sb,
+ name, context_inode);
if (IS_ERR(inode)) {
file = ERR_CAST(inode);
goto err;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 96c7925a6551..7ba45be0d7a0 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -3604,6 +3604,8 @@ extern int simple_write_begin(struct file *file, struct address_space *mapping,
extern const struct address_space_operations ram_aops;
extern int always_delete_dentry(const struct dentry *);
extern struct inode *alloc_anon_inode(struct super_block *);
+extern struct inode *anon_inode_make_secure_inode(struct super_block *sb,
+ const char *name, const struct inode *context_inode);
extern int simple_nosetlease(struct file *, int, struct file_lease **, void **);
extern const struct dentry_operations simple_dentry_operations;
--
2.43.0
next prev parent reply other threads:[~2025-06-18 11:30 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-18 11:29 [RFC PATCH v8 0/7] Add NUMA mempolicy support for KVM guest-memfd Shivank Garg
2025-06-18 11:29 ` Shivank Garg [this message]
2025-06-18 11:29 ` [RFC PATCH v8 2/7] KVM: guest_memfd: Use guest mem inodes instead of anonymous inodes Shivank Garg
2025-06-18 11:29 ` [RFC PATCH v8 3/7] mm/filemap: Add mempolicy support to the filemap layer Shivank Garg
2025-06-19 15:08 ` Vlastimil Babka
2025-06-19 16:03 ` Matthew Wilcox
2025-06-20 5:59 ` Shivank Garg
2025-06-20 9:37 ` Vlastimil Babka
2025-06-20 14:34 ` Matthew Wilcox
2025-06-20 14:52 ` Shivank Garg
2025-06-20 14:58 ` Matthew Wilcox
2025-06-20 14:34 ` [PATCH 1/2] filemap: Add a mempolicy argument to filemap_alloc_folio() Matthew Wilcox (Oracle)
2025-06-23 6:13 ` Gupta, Pankaj
2025-06-23 7:19 ` Vlastimil Babka
2025-06-20 14:34 ` [PATCH 2/2] filemap: Add __filemap_get_folio_mpol() Matthew Wilcox (Oracle)
2025-06-20 16:53 ` Matthew Wilcox
2025-06-22 18:43 ` Andrew Morton
2025-06-22 19:02 ` Shivank Garg
2025-06-22 22:16 ` Andrew Morton
2025-06-23 4:18 ` Shivank Garg
2025-06-23 10:01 ` Shivank Garg
2025-06-23 7:16 ` Vlastimil Babka
2025-06-23 9:56 ` Shivank Garg
2025-06-21 18:42 ` kernel test robot
2025-06-23 6:15 ` Gupta, Pankaj
2025-06-23 7:20 ` Vlastimil Babka
2025-06-18 11:29 ` [RFC PATCH v8 4/7] mm/mempolicy: Export memory policy symbols Shivank Garg
2025-06-18 15:12 ` Gregory Price
2025-06-19 11:13 ` Shivank Garg
2025-06-19 16:28 ` Vlastimil Babka
2025-06-18 11:29 ` [RFC PATCH v8 5/7] KVM: guest_memfd: Add slab-allocated inode cache Shivank Garg
2025-06-24 4:16 ` Huang, Ying
2025-06-29 18:25 ` Shivank Garg
2025-06-18 11:29 ` [RFC PATCH v8 6/7] KVM: guest_memfd: Enforce NUMA mempolicy using shared policy Shivank Garg
2025-06-18 11:29 ` [RFC PATCH v8 7/7] KVM: guest_memfd: selftests: Add tests for mmap and NUMA policy support Shivank Garg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250618112935.7629-2-shivankg@amd.com \
--to=shivankg@amd.com \
--cc=Neeraj.Upadhyay@amd.com \
--cc=ackerleytng@google.com \
--cc=aik@amd.com \
--cc=akpm@linux-foundation.org \
--cc=amit@infradead.org \
--cc=aneeshkumar.kizhakeveetil@arm.com \
--cc=apopple@nvidia.com \
--cc=ashish.kalra@amd.com \
--cc=bfoster@redhat.com \
--cc=bharata@amd.com \
--cc=brauner@kernel.org \
--cc=byungchul@sk.com \
--cc=cgzones@googlemail.com \
--cc=chao.gao@intel.com \
--cc=chao.p.peng@intel.com \
--cc=dan.j.williams@intel.com \
--cc=david@redhat.com \
--cc=ddutile@redhat.com \
--cc=gourry@gourry.net \
--cc=gshan@redhat.com \
--cc=hch@infradead.org \
--cc=ira.weiny@intel.com \
--cc=jack@suse.cz \
--cc=jgg@nvidia.com \
--cc=jgowans@amazon.com \
--cc=jmorris@namei.org \
--cc=joshua.hahnjy@gmail.com \
--cc=kalyazin@amazon.com \
--cc=kent.overstreet@linux.dev \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=matthew.brost@intel.com \
--cc=michael.day@amd.com \
--cc=michael.roth@amd.com \
--cc=nikunj@amd.com \
--cc=pankaj.gupta@amd.com \
--cc=papaluri@amd.com \
--cc=paul@paul-moore.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=pvorel@suse.cz \
--cc=quic_eberman@quicinc.com \
--cc=rakie.kim@sk.com \
--cc=rientjes@google.com \
--cc=roypat@amazon.co.uk \
--cc=rppt@kernel.org \
--cc=seanjc@google.com \
--cc=serge@hallyn.com \
--cc=shuah@kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=thomas.lendacky@amd.com \
--cc=vannapurve@google.com \
--cc=vbabka@suse.cz \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
--cc=yan.y.zhao@intel.com \
--cc=ying.huang@linux.alibaba.com \
--cc=yuzhao@google.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.