[PATCH] mm: mmap: allow for the maximum number of bits for randomizing mmap_base by default

[PATCH] mm: mmap: allow for the maximum number of bits for randomizing mmap_base by default

[Rafael Aquini]

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/

Signed-off-by: Rafael Aquini <aquini@redhat.com>
---
 arch/Kconfig | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/Kconfig b/arch/Kconfig
index 975dd22a2dbd..b142f0752dc5 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1046,10 +1046,21 @@ config ARCH_MMAP_RND_BITS_MAX
 config ARCH_MMAP_RND_BITS_DEFAULT
 	int
 
+config FORCE_MAX_MMAP_RND_BITS
+	bool "Force maximum number of bits to use for ASLR of mmap base address"
+	default n
+	help
+	  ARCH_MMAP_RND_BITS and ARCH_MMAP_RND_COMPAT_BITS represent the number
+	  of bits to use for ASLR and if no custom value is assigned (EXPERT)
+	  then the architercure's lower bound (minimum) value is assumed.
+	  This toggle changes that default assumption to assume the arch upper
+	  bound (maximum) value instead.
+
 config ARCH_MMAP_RND_BITS
 	int "Number of bits to use for ASLR of mmap base address" if EXPERT
 	range ARCH_MMAP_RND_BITS_MIN ARCH_MMAP_RND_BITS_MAX
 	default ARCH_MMAP_RND_BITS_DEFAULT if ARCH_MMAP_RND_BITS_DEFAULT
+	default ARCH_MMAP_RND_BITS_MAX if FORCE_MAX_MMAP_RND_BITS
 	default ARCH_MMAP_RND_BITS_MIN
 	depends on HAVE_ARCH_MMAP_RND_BITS
 	help
@@ -1084,6 +1095,7 @@ config ARCH_MMAP_RND_COMPAT_BITS
 	int "Number of bits to use for ASLR of mmap base address for compatible applications" if EXPERT
 	range ARCH_MMAP_RND_COMPAT_BITS_MIN ARCH_MMAP_RND_COMPAT_BITS_MAX
 	default ARCH_MMAP_RND_COMPAT_BITS_DEFAULT if ARCH_MMAP_RND_COMPAT_BITS_DEFAULT
+	default ARCH_MMAP_RND_COMPAT_BITS_MAX if FORCE_MAX_MMAP_RND_BITS
 	default ARCH_MMAP_RND_COMPAT_BITS_MIN
 	depends on HAVE_ARCH_MMAP_RND_COMPAT_BITS
 	help
-- 
2.45.1

[PATCH v2] mm: mmap: allow for the maximum number of bits for randomizing mmap_base by default

[Rafael Aquini]

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/

Signed-off-by: Rafael Aquini <aquini@redhat.com>
---
v2: fix "architercure" typo in config's help text

 arch/Kconfig | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/Kconfig b/arch/Kconfig
index 975dd22a2dbd..25ec91ac923a 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1046,10 +1046,21 @@ config ARCH_MMAP_RND_BITS_MAX
 config ARCH_MMAP_RND_BITS_DEFAULT
 	int
 
+config FORCE_MAX_MMAP_RND_BITS
+	bool "Force maximum number of bits to use for ASLR of mmap base address"
+	default n
+	help
+	  ARCH_MMAP_RND_BITS and ARCH_MMAP_RND_COMPAT_BITS represent the number
+	  of bits to use for ASLR and if no custom value is assigned (EXPERT)
+	  then the architecture's lower bound (minimum) value is assumed.
+	  This toggle changes that default assumption to assume the arch upper
+	  bound (maximum) value instead.
+
 config ARCH_MMAP_RND_BITS
 	int "Number of bits to use for ASLR of mmap base address" if EXPERT
 	range ARCH_MMAP_RND_BITS_MIN ARCH_MMAP_RND_BITS_MAX
 	default ARCH_MMAP_RND_BITS_DEFAULT if ARCH_MMAP_RND_BITS_DEFAULT
+	default ARCH_MMAP_RND_BITS_MAX if FORCE_MAX_MMAP_RND_BITS
 	default ARCH_MMAP_RND_BITS_MIN
 	depends on HAVE_ARCH_MMAP_RND_BITS
 	help
@@ -1084,6 +1095,7 @@ config ARCH_MMAP_RND_COMPAT_BITS
 	int "Number of bits to use for ASLR of mmap base address for compatible applications" if EXPERT
 	range ARCH_MMAP_RND_COMPAT_BITS_MIN ARCH_MMAP_RND_COMPAT_BITS_MAX
 	default ARCH_MMAP_RND_COMPAT_BITS_DEFAULT if ARCH_MMAP_RND_COMPAT_BITS_DEFAULT
+	default ARCH_MMAP_RND_COMPAT_BITS_MAX if FORCE_MAX_MMAP_RND_BITS
 	default ARCH_MMAP_RND_COMPAT_BITS_MIN
 	depends on HAVE_ARCH_MMAP_RND_COMPAT_BITS
 	help
-- 
2.45.1

Re: [PATCH v2] mm: mmap: allow for the maximum number of bits for randomizing mmap_base by default

[Andrew Morton]

On Thu,  6 Jun 2024 14:06:22 -0400 Rafael Aquini <aquini@redhat.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?

I assume a cc:stable is appropriate?

Re: [PATCH v2] mm: mmap: allow for the maximum number of bits for randomizing mmap_base by default

[Rafael Aquini]

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@redhat.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.

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

-- Rafael

Re: [PATCH v2] mm: mmap: allow for the maximum number of bits for randomizing mmap_base by default

[Andrew Morton]

On Mon, 10 Jun 2024 14:45:28 -0400 Rafael Aquini <aquini@redhat.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@redhat.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.

Re: [PATCH v2] mm: mmap: allow for the maximum number of bits for randomizing mmap_base by default

[Rafael Aquini]

On Tue, Jun 11, 2024 at 02:32:39PM -0700, Andrew Morton wrote:
> On Mon, 10 Jun 2024 14:45:28 -0400 Rafael Aquini <aquini@redhat.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@redhat.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?

Correct. The patch doesn't fix it by default but provides a way for users
to adjust these settings at buildtime. Users are still expected/required to 
take action, though.

> Shouldn't we make this the default (at least for 32-bit) so the
> regressed kernels are fixed simply by applying this patch?
> 

That is a fair take, indeed. I guess we could do something like

 config FORCE_MAX_MMAP_RND_BITS
        bool "Force maximum number of bits to use for ASLR of mmap base address"
-       default n
+       default y if !64BIT


> > Lemme know if you want me refreshing the patch to amend these bits.
> 
> Is OK, I can update things.

Thank you!

-- Rafael

Re: [PATCH v2] mm: mmap: allow for the maximum number of bits for randomizing mmap_base by default

[Andrew Morton]

On Tue, 11 Jun 2024 21:35:24 -0400 Rafael Aquini <aquini@redhat.com> wrote:

> > Shouldn't we make this the default (at least for 32-bit) so the
> > regressed kernels are fixed simply by applying this patch?
> > 
> 
> That is a fair take, indeed. I guess we could do something like
> 
>  config FORCE_MAX_MMAP_RND_BITS
>         bool "Force maximum number of bits to use for ASLR of mmap base address"
> -       default n
> +       default y if !64BIT

"something like" != "exhaustively tested" ;)

I'll toss that in there, but please do let me know when it is suitable
for an upstream merge.

I also added cc:stable.

Re: [PATCH v2] mm: mmap: allow for the maximum number of bits for randomizing mmap_base by default

[Rafael Aquini]

On Tue, Jun 11, 2024 at 07:43:12PM -0700, Andrew Morton wrote:
> On Tue, 11 Jun 2024 21:35:24 -0400 Rafael Aquini <aquini@redhat.com> wrote:
> 
> > > Shouldn't we make this the default (at least for 32-bit) so the
> > > regressed kernels are fixed simply by applying this patch?
> > > 
> > 
> > That is a fair take, indeed. I guess we could do something like
> > 
> >  config FORCE_MAX_MMAP_RND_BITS
> >         bool "Force maximum number of bits to use for ASLR of mmap base address"
> > -       default n
> > +       default y if !64BIT
> 
> "something like" != "exhaustively tested" ;)
> 
> I'll toss that in there, but please do let me know when it is suitable
> for an upstream merge.
>

The follow-up patch does work as intended:

  [raquini@optiplex-lnx linux]$ make ARCH=i386 defconfig
  *** Default configuration is based on 'i386_defconfig'
  #
  # configuration written to .config
  #
  [raquini@optiplex-lnx linux]$ grep MMAP_RND_BITS .config
  CONFIG_ARCH_MMAP_RND_BITS_MIN=8
  CONFIG_ARCH_MMAP_RND_BITS_MAX=16
  CONFIG_HAVE_ARCH_MMAP_RND_BITS=y
  # CONFIG_FORCE_MAX_MMAP_RND_BITS is not set
  CONFIG_ARCH_MMAP_RND_BITS=8
  
  [raquini@optiplex-lnx linux]$ patch -Np1 < patch.diff 
  patching file arch/Kconfig
  [raquini@optiplex-lnx linux]$ make ARCH=i386 defconfig
  *** Default configuration is based on 'i386_defconfig'
  #
  # configuration written to .config
  #
  [raquini@optiplex-lnx linux]$ grep MMAP_RND_BITS .config
  CONFIG_ARCH_MMAP_RND_BITS_MIN=8
  CONFIG_ARCH_MMAP_RND_BITS_MAX=16
  CONFIG_HAVE_ARCH_MMAP_RND_BITS=y
  CONFIG_FORCE_MAX_MMAP_RND_BITS=y
  CONFIG_ARCH_MMAP_RND_BITS=16

 
> I also added cc:stable.
>

Thank you, Andrew.