linux-kernel - Re: [PATCH] /dev/zero: make private mapping full anonymous mapping

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: <0c7fb1b2-4f08-4017-a27c-cc0cb4da4a93@os.amperecomputing.com>
Date: Wed, 15 Jan 2025 13:29:19 -0800
From: Yang Shi <yang@...amperecomputing.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: arnd@...db.de, gregkh@...uxfoundation.org, Liam.Howlett@...cle.com,
 vbabka@...e.cz, jannh@...gle.com, willy@...radead.org,
 liushixin2@...wei.com, akpm@...ux-foundation.org, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] /dev/zero: make private mapping full anonymous mapping


>> I just thought of named anonymous VMA may help. We can give the private
>> /dev/zero mapping a name, for example, just "/dev/zero". However,
>> "[anon:/dev/zero]" will show up in smaps/maps. We can't keep the device
>> numbers and inode number either, but it seems it can tell the user this
>> mapping comes from /dev/zero, and it also explicitly tells us it is
>> specially treated by kernel. Hopefully setting anon_name is permitted.
> But then that'd require CONFIG_ANON_VMA_NAME unfortunately :(

Yes.

>
> I think this maps thing is the killer here really.
>
> It'd be nice to -specifically- have a means of expressing this kind of VMA,
> we have a means of setting a VMA anon, so maybe we can 'set a VMA to
> /dev/zero' and somehow explicitly know that we've done this and identify
> this special case.
>
> I'm not sure that the .mmap callback is the right place to do this and I"m
> not sure how exactly this would work but this could be workable.

A couple of potential approaches off the top of my head:
   - A new vm flag
   - Use vm_private_data

Both of them have pros and cons. The vm flag is simple enough, but it 
needs to consume one bit for just one usecase. The vm_private_data is a 
void pointer and a lot drivers use it to store driver specific data 
structures, so using the pointer in a generic path (for example, smaps) 
to tell us whether it is /dev/zero is not easy. We may be able to have a 
special encoding to it, for example, set the last bit (the trick is not 
unusual in core mm code).

>
> I agree the actual offset into the zero page is of no relevance and no
> _sane_ user will care, but this way we could put /dev/zero in [s]maps,
> treat this VMA as anon, but also add semantic information about the
> existence of this weird corner case.
>