linux-kernel - 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAJgzZopiyhq9Wpu+gxUssoNhQT7tNjiey0JGsKPJAXjraEBRiw@mail.gmail.com>
Date: Wed, 22 Jan 2025 17:29:45 -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 Wed, Jan 22, 2025 at 12:24 PM Liam R. Howlett
<Liam.Howlett@...cle.com> wrote:
>
> * enh <enh@...gle.com> [250121 10:38]:
> > 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.
>
> We are making changes in this area.  Can you elaborate on the 'awkward'
> part?  The locking or the tearing of data?
>
> The way you state the page, it makes me think it's the tearing that is
> the issue?  I think the ioctl would be worse for the possible tearing of
> data.

there are two main styles of use of the /proc/<pid>/maps data i've
seen in userspace:

1. i need to know about _all_ the vmas, so i'm reading the whole file
and stitching it together.
2. i need to know about the vma containing a specific address, so i'm
reading line-by-line looking for a match.

the former is typically just for humans anyway (to be added to a crash
report) -- so the ability to sendfile() or whatever would be something
we could use there (though i've no idea whether that actually solves
the tearing issue) -- so those use cases mostly tend to ignore (or not
notice) the problem.

for the latter, tearing is a bigger problem because what does "not
found" mean? do we try again? how many times do we try? so i think the
ioctl() would solve those problems. plus it would be a lot cheaper,
and in particular not require [or at least "strongly benefit from"]
dynamic memory allocation like parsing a text file does.

> Thanks,
> Liam
>
>