Christoph Hellwig <h...@infradead.org> writes:
> On Tue, Apr 08, 2025 at 11:23:59AM +0000, Shivank Garg wrote:
>> From: Ackerley Tng <ackerley...@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 <ackerley...@google.com>
>> Signed-off-by: Fuad Tabba <ta...@google.com>
>> Signed-off-by: Shivank Garg <shiva...@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?
