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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <l7pexkoo7t7p5u6gobgc46lxvpgpe2lywaqwa4b6vjddt3ccnq@mh6x72cxfhyv>
Date: Wed, 22 Jan 2025 12:23:32 -0500
From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
To: enh <enh@...gle.com>
Cc: 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

* 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.

Thanks,
Liam