linux-kernel - Re: [PATCH 00/16] mm: Introduce MAP_BELOW

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: <pzxlpwxbrs3pali53bogsorwebi45ayqivxmpeagrhvdh7zt4u@ybsa2vnkze7v>
Date: Thu, 29 Aug 2024 15:36:43 -0400
From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Charlie Jenkins <charlie@...osinc.com>, Arnd Bergmann <arnd@...db.de>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>, Michael Ellerman <mpe@...erman.id.au>,
        Nicholas Piggin <npiggin@...il.com>,
        Christophe Leroy <christophe.leroy@...roup.eu>,
        Naveen N Rao <naveen@...nel.org>, Muchun Song <muchun.song@...ux.dev>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
        Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>, Huacai Chen <chenhuacai@...nel.org>,
        WANG Xuerui <kernel@...0n.name>, Russell King <linux@...linux.org.uk>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        "James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
        Helge Deller <deller@....de>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        Gerald Schaefer <gerald.schaefer@...ux.ibm.com>,
        Heiko Carstens <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        Sven Schnelle <svens@...ux.ibm.com>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        Rich Felker <dalias@...c.org>,
        John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
        "David S. Miller" <davem@...emloft.net>,
        Andreas Larsson <andreas@...sler.com>, Shuah Khan <shuah@...nel.org>,
        Alexandre Ghiti <alexghiti@...osinc.com>, linux-arch@...r.kernel.org,
        linux-kernel@...r.kernel.org, Palmer Dabbelt <palmer@...osinc.com>,
        linux-riscv@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org,
        linuxppc-dev@...ts.ozlabs.org, linux-mm@...ck.org,
        loongarch@...ts.linux.dev, linux-mips@...r.kernel.org,
        linux-parisc@...r.kernel.org, linux-s390@...r.kernel.org,
        linux-sh@...r.kernel.org, sparclinux@...r.kernel.org,
        linux-kselftest@...r.kernel.org
Subject: Re: [PATCH 00/16] mm: Introduce MAP_BELOW_HINT

* Dave Hansen <dave.hansen@...el.com> [240829 12:54]:
> On 8/28/24 13:15, Charlie Jenkins wrote:
> > A way to restrict mmap() to return LAM compliant addresses in an entire
> > address space also doesn't have to be mutually exclusive with this flag.
> > This flag allows for the greatest degree of control from applications.
> > I don't believe there is additionally performance saving that could be
> > achieved by having this be on a per address space basis.
> 
> I agree with you in general.  The MAP_BELOW_HINT _is_ the most flexible.
>  But it's also rather complicated.

There is a (seldom used?) feature of mmap_min_addr, it seems like we
could have an mmap_max_addr.  Would something like that work for your
use case?  Perhaps it would be less intrusive to do something in this
way?  I haven't looked at it in depth and this affects all address
spaces as well (new allocations only).

There is a note on mmap_min_addr about applications that require the
lower addresses, would this mean we'll now have a note about upper
limits?

I really don't understand why you need this at all, to be honest.  If
you know the upper limit you could just MAP_FIXED map a huge guard at
the top of your address space then do whatever you want with those bits.

This will create an entry in the vma tree that no one else will be able
to use, and you can do this in any process you want, for as many bits as
you want.

> 
> My _hope_ would be that a per-address-space property could share at
> least some infrastructure with what x86/LAM and arm/TBI do to the
> address space.  Basically put the restrictions in place for purely
> software reasons instead of the mostly hardware reasons for LAM/TBI.
> 
> Lorenzo also raised some very valid points about a having a generic
> address-restriction ABI.  I'm certainly not discounting those concerns.
> It's not something that can be done lightly.

Yes, I am concerned about supporting this (probably forever) and dancing
around special code that may cause issues, perhaps on an arch that few
have for testing.  I already have so many qemu images for testing, some
of which no longer have valid install media - and basically none of them
use the same code in this area (or have special cases already).  I think
you understand what we are dealing with considering your comments in
your cover letter.

Thanks,
Liam