linux-kernel - Re: [PATCH 5/5] [RFC] mm: Remove MAP

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

Message-ID: <fcd1afe6-16f6-4a51-8bb4-08ece80337f4@lucifer.local>
Date: Wed, 9 Oct 2024 15:32:46 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: David Hildenbrand <david@...hat.com>, Arnd Bergmann <arnd@...nel.org>,
        linux-mm@...ck.org, "Jason A . Donenfeld" <Jason@...c4.com>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Andreas Larsson <andreas@...sler.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        Christian Brauner <brauner@...nel.org>, Christoph Hellwig <hch@....de>,
        Christophe Leroy <christophe.leroy@...roup.eu>,
        Damien Le Moal <dlemoal@...nel.org>,
        Greg Ungerer <gerg@...ux-m68k.org>, Helge Deller <deller@....de>,
        Kees Cook <kees@...nel.org>,
        "Liam R. Howlett" <Liam.Howlett@...cle.com>,
        Matt Turner <mattst88@...il.com>, Max Filippov <jcmvbkbc@...il.com>,
        Michael Ellerman <mpe@...erman.id.au>, Michal Hocko <mhocko@...e.com>,
        Nicholas Piggin <npiggin@...il.com>,
        Richard Henderson <richard.henderson@...aro.org>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Vladimir Murzin <vladimir.murzin@....com>,
        Vlastimil Babka <vbabka@...e.cz>,
        linux-stm32@...md-mailman.stormreply.com, linux-kernel@...r.kernel.org,
        linux-mips@...r.kernel.org, linux-parisc@...r.kernel.org,
        linuxppc-dev@...ts.ozlabs.org, Linux-Arch <linux-arch@...r.kernel.org>
Subject: Re: [PATCH 5/5] [RFC] mm: Remove MAP_UNINITIALIZED support

On Thu, Sep 26, 2024 at 01:54:09PM +0000, Arnd Bergmann wrote:
> On Thu, Sep 26, 2024, at 08:46, David Hildenbrand wrote:
> > On 25.09.24 23:06, Arnd Bergmann wrote:
> >
> > The first, uncontroversial step could indeed be to make
> > MAP_UNINITIALIZED a nop, but still leave the definitions in mman.h etc
> > around.
> >
> > This is the same we did with MAP_DENYWRITE. There might be some weird
> > user out there, and carelessly reusing the bit could result in trouble.
> > (people might argue that they are not using it with MAP_HUGETLB, so it
> > would work)
> >
> > Going forward and removing MAP_UNINITIALIZED is a bit more
> > controversial, but maybe there really isn't any other user around.
> > Software that is not getting recompiled cannot be really identified by
> > letting it rest in -next only.
> >
> > My take would be to leave MAP_UNINITIALIZED in the headers in some form
> > for documentation purposes.
>
> I don't think there is much point in doing this in multiple
> steps, either we want to break it at compile time or leave
> it silently doing nothing. There is also very little
> difference in practice because applications almost always
> use sys/mman.h instead of linux/mman.h.
>
> FWIW, the main user appears to be the uClibc and uclibc-ng
> malloc() implementation for NOMMU targets:
>
> https://git.uclibc.org/uClibc/commit/libc/stdlib/malloc/malloc.c?id=00673f93826bf1f
>
> Both of these also define this constant itself as 0x4000000
> for all architectures.
>
> There are a few others that I could find with Debian codesearch:
>
> https://sources.debian.org/src/monado/21.0.0+git2905.e26a272c1~dfsg1-2/src/external/tracy/client/tracy_rpmalloc.cpp/?hl=890#L889
> https://sources.debian.org/src/systemtap/5.1-4/testsuite/systemtap.syscall/mmap.c/?hl=224#L224
> https://sources.debian.org/src/fuzzel/1.11.1+ds-1/shm.c/?hl=488#L488
> https://sources.debian.org/src/notcurses/3.0.7+dfsg.1-1/src/lib/fbuf.h/?hl=35#L35
> https://sources.debian.org/src/lmms/1.2.2+dfsg1-6/src/3rdparty/rpmalloc/rpmalloc/rpmalloc/rpmalloc.c/?hl=1753#L1753
>
> All of these will fall back to not passing MAP_UNINITIALIZED
> if it's not defined, which is what happens on glibc and musl.
>
>        Arnd

My point of view on this basis is to rip the bandaid off and get rid. Agree
with DavidH it's worth keeping some kind of documentation that these
existed around so somebody grepping and confused can see what happened...