linux-hardening - Re: [PATCH v4 1/1] exec: seal system mappings

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: <CAJgzZopv+jKmDncYDJEQTymqQ1oRpy8HNpOsmcoM7Chb=uBJzg@mail.gmail.com>
Date: Tue, 21 Jan 2025 10:38:32 -0500
From: enh <enh@...gle.com>
To: "Liam R. Howlett" <Liam.Howlett@...cle.com>, enh <enh@...gle.com>, 
	Jeff Xu <jeffxu@...omium.org>, Pedro Falcato <pedro.falcato@...il.com>, 
	Benjamin Berg <benjamin@...solutions.net>, Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, 
	Kees Cook <kees@...nel.org>, akpm@...ux-foundation.org, jannh@...gle.com, 
	torvalds@...ux-foundation.org, adhemerval.zanella@...aro.org, oleg@...hat.com, 
	linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org, 
	linux-mm@...ck.org, jorgelo@...omium.org, sroettger@...gle.com, 
	ojeda@...nel.org, adobriyan@...il.com, anna-maria@...utronix.de, 
	mark.rutland@....com, linus.walleij@...aro.org, Jason@...c4.com, 
	deller@....de, rdunlap@...radead.org, davem@...emloft.net, hch@....de, 
	peterx@...hat.com, hca@...ux.ibm.com, f.fainelli@...il.com, gerg@...nel.org, 
	dave.hansen@...ux.intel.com, mingo@...nel.org, ardb@...nel.org, 
	mhocko@...e.com, 42.hyeyoo@...il.com, peterz@...radead.org, ardb@...gle.com, 
	rientjes@...gle.com, groeck@...omium.org, mpe@...erman.id.au, 
	Vlastimil Babka <vbabka@...e.cz>, Andrei Vagin <avagin@...il.com>, Dmitry Safonov <0x7f454c46@...il.com>, 
	Mike Rapoport <mike.rapoport@...il.com>, 
	Alexander Mikhalitsyn <aleksandr.mikhalitsyn@...onical.com>
Subject: Re: [PATCH v4 1/1] exec: seal system mappings

On Fri, Jan 17, 2025 at 5:08 PM Liam R. Howlett <Liam.Howlett@...cle.com> wrote:
>
> * enh <enh@...gle.com> [250117 14:35]:
> ...
>
> >
> > as a maintainer of a different linux libc, i've long wanted a "tell me
> > everything there is to know about this vma" syscall rather than having
> > to parse /proc/maps...
> >
>
> You mean an ioctl()-based API to query VMAs from /proc/<pid>/maps?

i wasn't imagining an ioctl(), no, just a regular syscall, but that
would work too.

> Andrii had something like that [1], check out ed5d583a88a92 ("fs/procfs:
> implement efficient VMA querying API for /proc/<pid>/maps")

yeah, that would work for the use cases i've seen too (some of which
are similar to the ones mentioned in the patch description, but other
ones too).

the other motivation we've had that i didn't notice mentioned there is
avoiding the awkward /proc/<pid>/maps behavior when you have too many
vmas to fit all the output into a page.

i'd definitely use this in Android's libc, and several of our
profiling/unwinding libraries.

> Regards,
> Liam
>
> [1]. https://lore.kernel.org/linux-mm/20240627170900.1672542-1-andrii@kernel.org/