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 <[email protected]>
---
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
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 <[email protected]>
---
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
On Thu, 6 Jun 2024 14:06:22 -0400 Rafael Aquini <[email protected]> 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?
On Mon, Jun 10, 2024 at 11:11:39AM -0700, Andrew Morton wrote:
> On Thu, 6 Jun 2024 14:06:22 -0400 Rafael Aquini <[email protected]> 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
On Mon, 10 Jun 2024 14:45:28 -0400 Rafael Aquini <[email protected]> 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 <[email protected]> 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.
On Tue, Jun 11, 2024 at 02:32:39PM -0700, Andrew Morton wrote:
> On Mon, 10 Jun 2024 14:45:28 -0400 Rafael Aquini <[email protected]> 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 <[email protected]> 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
On Tue, 11 Jun 2024 21:35:24 -0400 Rafael Aquini <[email protected]> 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.
On Tue, Jun 11, 2024 at 07:43:12PM -0700, Andrew Morton wrote:
> On Tue, 11 Jun 2024 21:35:24 -0400 Rafael Aquini <[email protected]> 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.