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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ