lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e91f1c4a-5319-49dd-93fb-16275ed8607f@amd.com>
Date: Fri, 11 Apr 2025 12:21:35 +0530
From: Shivank Garg <shivankg@....com>
To: Christoph Hellwig <hch@...radead.org>
Cc: seanjc@...gle.com, david@...hat.com, vbabka@...e.cz, willy@...radead.org,
 akpm@...ux-foundation.org, shuah@...nel.org, pbonzini@...hat.com,
 ackerleytng@...gle.com, paul@...l-moore.com, jmorris@...ei.org,
 serge@...lyn.com, pvorel@...e.cz, bfoster@...hat.com, tabba@...gle.com,
 vannapurve@...gle.com, chao.gao@...el.com, bharata@....com, nikunj@....com,
 michael.day@....com, yan.y.zhao@...el.com, Neeraj.Upadhyay@....com,
 thomas.lendacky@....com, michael.roth@....com, aik@....com, jgg@...dia.com,
 kalyazin@...zon.com, peterx@...hat.com, linux-fsdevel@...r.kernel.org,
 linux-mm@...ck.org, linux-kernel@...r.kernel.org,
 linux-security-module@...r.kernel.org, kvm@...r.kernel.org,
 linux-kselftest@...r.kernel.org, linux-coco@...ts.linux.dev
Subject: Re: [PATCH RFC v7 3/8] security: Export
 security_inode_init_security_anon for KVM guest_memfd



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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ