linux-kernel - Re: [PATCH v2] mm: mmap: allow for the maximum number of bits for randomizing mmap

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: <20240611143239.ab8e4d96289a748ae1f8a480@linux-foundation.org>
Date: Tue, 11 Jun 2024 14:32:39 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Rafael Aquini <aquini@...hat.com>
Cc: linux-kernel@...r.kernel.org, Arnd Bergmann <arnd@...db.de>, Heiko
 Carstens <hca@...ux.ibm.com>, Petr Mladek <pmladek@...e.com>, Mike Rapoport
 <rppt@...nel.org>, Paul McKenney <paulmck@...nel.org>, Samuel Holland
 <samuel.holland@...ive.com>
Subject: Re: [PATCH v2] mm: mmap: allow for the maximum number of bits for
 randomizing mmap_base by default

On Mon, 10 Jun 2024 14:45:28 -0400 Rafael Aquini <aquini@...hat.com> wrote:

> On Mon, Jun 10, 2024 at 11:11:39AM -0700, Andrew Morton wrote:
> > On Thu,  6 Jun 2024 14:06:22 -0400 Rafael Aquini <aquini@...hat.com> wrote:
> > 
> > > An ASLR regression was noticed [1] and tracked down to file-mapped areas
> > > being backed by THP in recent kernels. The 21-bit alignment constraint
> > > for such mappings reduces the entropy for randomizing the placement of
> > > 64-bit library mappings and breaks ASLR completely for 32-bit libraries.
> > > 
> > > The reported issue is easily addressed by increasing vm.mmap_rnd_bits
> > > and vm.mmap_rnd_compat_bits. This patch just provides a simple way to
> > > set ARCH_MMAP_RND_BITS and ARCH_MMAP_RND_COMPAT_BITS to their maximum
> > > values allowed by the architecture at build time.
> > > 
> > > [1] https://zolutal.github.io/aslrnt/
> > 
> > Are we able to identify a Fixes: target for this?
> >
> 
> Sure, it would be:
> 
>  Fixes: 1854bc6e2420 ("mm/readahead: Align file mappings for non-DAX")
>  
> > I assume a cc:stable is appropriate?
> > 
> 
> Andrew, I admit I was somewhat hesitant on adding the Fixes: and the stable CC
> to this patch because I didn't really think of it as a "fix" for the given 
> commit, but just as a simple way to toggle ARCH_MMAP_RND{,_COMPAT}_BITS 
> to maximum allowed at build time.
> 
> I don't disagree with doing it, though, if you think it might be appropriate.

Well, "breaks completely" is motivational!

But does the patch fix this, by default?  Doesn't the user have to take
some action (set FORCE_MAX_MMAP_RND_BITS) to fix the breakage? 
Shouldn't we make this the default (at least for 32-bit) so the
regressed kernels are fixed simply by applying this patch?

> Lemme know if you want me refreshing the patch to amend these bits.

Is OK, I can update things.