linux-kernel - Re: [PATCH RFC v7 3/8] security: Export security_inode_init_security_anon for KVM guest

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1bee5078-5cc4-43b7-993c-f1e57a9bf534@redhat.com>
Date: Tue, 22 Apr 2025 18:49:14 +0200
From: David Hildenbrand <david@...hat.com>
To: Shivank Garg <shivankg@....com>, Paul Moore <paul@...l-moore.com>
Cc: seanjc@...gle.com, vbabka@...e.cz, willy@...radead.org,
 akpm@...ux-foundation.org, shuah@...nel.org, pbonzini@...hat.com,
 ackerleytng@...gle.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 11.04.25 08:07, Shivank Garg wrote:
> Hi Paul,
> 
> On 4/10/2025 1:49 AM, Paul Moore wrote:
>> On Tue, Apr 8, 2025 at 7:25 AM Shivank Garg <shivankg@....com> 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.
>>
>> Can you help me understand the timing just a bit more ... do you
>> expect the move to the core MM code to happen during the lifetime of
>> this patchset, or is it just some hand-wavy "future date"?  No worries
>> either way, just trying to understand things a bit better.
> 
> I am not sure about it, any ideas David?

Sorry for the late reply.

Hand-wavy future date after this series. Elliot was working on this, but 
IIRC he now has a new job and might no longer be able to work on this.

Ackerley+Patrick started looking into this, and will likely require it 
for other guest_memfd features (hugetlb support, directmap removal).

-- 
Cheers,

David / dhildenb