Christoph Hellwig hch@infradead.org writes:
On Tue, Apr 08, 2025 at 11:23:59AM +0000, Shivank Garg wrote:
From: Ackerley Tng ackerleytng@google.com
Using guest mem inodes allows us to store metadata for the backing memory on the inode. Metadata will be added in a later patch to support HugeTLB pages.
Metadata about backing memory should not be stored on the file, since the file represents a guest_memfd's binding with a struct kvm, and metadata about backing memory is not unique to a specific binding and struct kvm.
Signed-off-by: Ackerley Tng ackerleytng@google.com Signed-off-by: Fuad Tabba tabba@google.com Signed-off-by: Shivank Garg shivankg@amd.com
include/uapi/linux/magic.h | 1 + virt/kvm/guest_memfd.c | 133 +++++++++++++++++++++++++++++++------ 2 files changed, 113 insertions(+), 21 deletions(-)
<snip> +static struct inode *kvm_gmem_inode_make_secure_inode(const char *name, + loff_t size, u64 flags) +{ + const struct qstr qname = QSTR_INIT(name, strlen(name)); + struct inode *inode; + int err; + + inode = alloc_anon_inode(kvm_gmem_mnt->mnt_sb); + if (IS_ERR(inode)) + return inode; + + err = security_inode_init_security_anon(inode, &qname, NULL); + if (err) { + iput(inode); + return ERR_PTR(err); + }
So why do other alloc_anon_inode callers not need security_inode_init_security_anon?
Thanks for this tip!
When I did this refactoring, I was just refactoring anon_inode_create_getfile(), to set up the guest_memfd inode and file in separate stages, and anon_inode_create_getfile() was already using security_inode_init_security_anon().
In the next revision I can remove this call.
Is it too late to remove the call to security_inode_init_security_anon() though? IIUC it is used by LSMs, which means security modules may already be assuming this call?