diff mbox series

[RFC,v7,3/8] security: Export security_inode_init_security_anon for KVM guest_memfd

Message ID 20250408112402.181574-4-shivankg@amd.com
State New
Headers show
Series Add NUMA mempolicy support for KVM guest-memfd | expand

Commit Message

Shivank Garg April 8, 2025, 11:23 a.m. UTC
KVM guest_memfd is implementing its own inodes to store metadata for
backing memory using a custom filesystem. This requires the ability to
initialize anonymous inode using security_inode_init_security_anon().

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>
---
 security/security.c | 1 +
 1 file changed, 1 insertion(+)

Comments

Christoph Hellwig April 10, 2025, 8:41 a.m. UTC | #1
On Tue, Apr 08, 2025 at 11:23:57AM +0000, Shivank Garg wrote:
> KVM guest_memfd is implementing its own inodes to store metadata for
> backing memory using a custom filesystem. This requires the ability to
> initialize anonymous inode using security_inode_init_security_anon().
> 
> 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.

This really should be a EXPORT_SYMBOL_GPL, if at all.

But you really should look into a new interface in anon_inode.c that
can be reused instead of duplicating anonymouns inode logic in kvm.ko.
Shivank Garg April 11, 2025, 6:51 a.m. UTC | #2
On 4/10/2025 2:11 PM, Christoph Hellwig wrote:
> On Tue, Apr 08, 2025 at 11:23:57AM +0000, Shivank Garg wrote:
>> KVM guest_memfd is implementing its own inodes to store metadata for
>> backing memory using a custom filesystem. This requires the ability to
>> initialize anonymous inode using security_inode_init_security_anon().
>>
>> 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.
> 
> This really should be a EXPORT_SYMBOL_GPL, if at all.
> 
> But you really should look into a new interface in anon_inode.c that
> can be reused instead of duplicating anonymouns inode logic in kvm.ko.
> 

I agree, it makes sense.
I'll use EXPORT_SYMBOL_GPL in next version and look into reusing reusing
existing logic.

Thanks,
Shivank
diff mbox series

Patch

diff --git a/security/security.c b/security/security.c
index fb57e8fddd91..097283bb06a5 100644
--- a/security/security.c
+++ b/security/security.c
@@ -1877,6 +1877,7 @@  int security_inode_init_security_anon(struct inode *inode,
 	return call_int_hook(inode_init_security_anon, inode, name,
 			     context_inode);
 }
+EXPORT_SYMBOL(security_inode_init_security_anon);
 
 #ifdef CONFIG_SECURITY_PATH
 /**