powerpc: arch_mmap_rnd() uses hard-coded values, (23-PAGE_SHIFT) for
32-bit and (30-PAGE_SHIFT) for 64-bit, to generate the random offset
for the mmap base address.
This value represents a compromise between increased
ASLR effectiveness and avoiding address-space fragmentation.
Replace it with a Kconfig option, which is sensibly bounded, so that
platform developers may choose where to place this compromise.
Keep default values as new minimums.
This patch makes sure that now powerpc mmap arch_mmap_rnd() approach
is similar to other ARCHs like x86, arm64 and arm.
Cc: Alexander Graf <redacted>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <redacted>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Alistair Popple <redacted>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Vitaly Bordug <redacted>
Cc: Scott Wood <oss@buserror.net>
Cc: Kumar Gala <redacted>
Cc: Daniel Cashman <redacted>
Signed-off-by: Bhupesh Sharma <redacted>
Reviewed-by: Kees Cook <keescook at chromium.org>
---
Changes since v1:
v1 can be seen here (https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-February/153594.html)
- No functional change in this patch.
- Added R-B from Kees.
- Dropped PATCH 2/2 from v1 as recommended by Kees Cook.
arch/powerpc/Kconfig | 34 ++++++++++++++++++++++++++++++++++
arch/powerpc/mm/mmap.c | 7 ++++---
2 files changed, 38 insertions(+), 3 deletions(-)
@@ -22,6 +22,38 @@ config MMUbooldefaulty+configARCH_MMAP_RND_BITS_MIN+default5ifPPC_256K_PAGES&&32BIT+default12ifPPC_256K_PAGES&&64BIT+default7ifPPC_64K_PAGES&&32BIT+default14ifPPC_64K_PAGES&&64BIT+default9ifPPC_16K_PAGES&&32BIT+default16ifPPC_16K_PAGES&&64BIT+default11ifPPC_4K_PAGES&&32BIT+default18ifPPC_4K_PAGES&&64BIT++# max bits determined by the following formula:+# VA_BITS - PAGE_SHIFT - 4+# for e.g for 64K page and 64BIT = 48 - 16 - 4 = 28+configARCH_MMAP_RND_BITS_MAX+default10ifPPC_256K_PAGES&&32BIT+default26ifPPC_256K_PAGES&&64BIT+default12ifPPC_64K_PAGES&&32BIT+default28ifPPC_64K_PAGES&&64BIT+default14ifPPC_16K_PAGES&&32BIT+default30ifPPC_16K_PAGES&&64BIT+default16ifPPC_4K_PAGES&&32BIT+default32ifPPC_4K_PAGES&&64BIT++configARCH_MMAP_RND_COMPAT_BITS_MIN+default5ifPPC_256K_PAGES+default7ifPPC_64K_PAGES+default9ifPPC_16K_PAGES+default11++configARCH_MMAP_RND_COMPAT_BITS_MAX+default16+configHAVE_SETUP_PER_CPU_AREAdef_boolPPC64
@@ -60,11 +60,12 @@ unsigned long arch_mmap_rnd(void){unsignedlongrnd;-/* 8MB for 32bit, 1GB for 64bit */+#ifdef CONFIG_COMPATif(is_32bit_task())-rnd=get_random_long()%(1<<(23-PAGE_SHIFT));+rnd=get_random_long()&((1UL<<mmap_rnd_compat_bits)-1);else-rnd=get_random_long()%(1UL<<(30-PAGE_SHIFT));+#endif+rnd=get_random_long()&((1UL<<mmap_rnd_bits)-1);returnrnd<<PAGE_SHIFT;}
On Thu, Feb 2, 2017 at 9:11 PM, Bhupesh Sharma [off-list ref] wrote:
powerpc: arch_mmap_rnd() uses hard-coded values, (23-PAGE_SHIFT) for
32-bit and (30-PAGE_SHIFT) for 64-bit, to generate the random offset
for the mmap base address.
This value represents a compromise between increased
ASLR effectiveness and avoiding address-space fragmentation.
Replace it with a Kconfig option, which is sensibly bounded, so that
platform developers may choose where to place this compromise.
Keep default values as new minimums.
This patch makes sure that now powerpc mmap arch_mmap_rnd() approach
is similar to other ARCHs like x86, arm64 and arm.
Cc: Alexander Graf <redacted>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <redacted>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Alistair Popple <redacted>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Vitaly Bordug <redacted>
Cc: Scott Wood <oss@buserror.net>
Cc: Kumar Gala <redacted>
Cc: Daniel Cashman <redacted>
Signed-off-by: Bhupesh Sharma <redacted>
Reviewed-by: Kees Cook <keescook at chromium.org>
This " at " should be "@", but otherwise, yay v2! :)
-Kees
--
Kees Cook
Pixel Security
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2017-02-07 02:27:51
Bhupesh Sharma [off-list ref] writes:
powerpc: arch_mmap_rnd() uses hard-coded values, (23-PAGE_SHIFT) for
32-bit and (30-PAGE_SHIFT) for 64-bit, to generate the random offset
for the mmap base address.
This value represents a compromise between increased
ASLR effectiveness and avoiding address-space fragmentation.
Replace it with a Kconfig option, which is sensibly bounded, so that
platform developers may choose where to place this compromise.
Keep default values as new minimums.
This patch makes sure that now powerpc mmap arch_mmap_rnd() approach
is similar to other ARCHs like x86, arm64 and arm.
Cc: Alexander Graf <redacted>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <redacted>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Alistair Popple <redacted>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Vitaly Bordug <redacted>
Cc: Scott Wood <oss@buserror.net>
Cc: Kumar Gala <redacted>
Cc: Daniel Cashman <redacted>
Signed-off-by: Bhupesh Sharma <redacted>
Reviewed-by: Kees Cook <keescook at chromium.org>
---
Changes since v1:
v1 can be seen here (https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-February/153594.html)
- No functional change in this patch.
- Added R-B from Kees.
- Dropped PATCH 2/2 from v1 as recommended by Kees Cook.
Thanks for v2.
But I replied to your v1 with some comments, did you see them?
cheers
On Sat, Feb 4, 2017 at 6:13 AM, Kees Cook [off-list ref] wrote:
On Thu, Feb 2, 2017 at 9:11 PM, Bhupesh Sharma [off-list ref] wrote:
quoted
powerpc: arch_mmap_rnd() uses hard-coded values, (23-PAGE_SHIFT) for
32-bit and (30-PAGE_SHIFT) for 64-bit, to generate the random offset
for the mmap base address.
This value represents a compromise between increased
ASLR effectiveness and avoiding address-space fragmentation.
Replace it with a Kconfig option, which is sensibly bounded, so that
platform developers may choose where to place this compromise.
Keep default values as new minimums.
This patch makes sure that now powerpc mmap arch_mmap_rnd() approach
is similar to other ARCHs like x86, arm64 and arm.
Cc: Alexander Graf <redacted>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <redacted>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Alistair Popple <redacted>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Vitaly Bordug <redacted>
Cc: Scott Wood <oss@buserror.net>
Cc: Kumar Gala <redacted>
Cc: Daniel Cashman <redacted>
Signed-off-by: Bhupesh Sharma <redacted>
Reviewed-by: Kees Cook <keescook at chromium.org>
This " at " should be "@", but otherwise, yay v2! :)
Hi Michael,
On Tue, Feb 7, 2017 at 7:57 AM, Michael Ellerman [off-list ref] wrote:
Bhupesh Sharma [off-list ref] writes:
quoted
powerpc: arch_mmap_rnd() uses hard-coded values, (23-PAGE_SHIFT) for
32-bit and (30-PAGE_SHIFT) for 64-bit, to generate the random offset
for the mmap base address.
This value represents a compromise between increased
ASLR effectiveness and avoiding address-space fragmentation.
Replace it with a Kconfig option, which is sensibly bounded, so that
platform developers may choose where to place this compromise.
Keep default values as new minimums.
This patch makes sure that now powerpc mmap arch_mmap_rnd() approach
is similar to other ARCHs like x86, arm64 and arm.
Cc: Alexander Graf <redacted>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <redacted>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Alistair Popple <redacted>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Vitaly Bordug <redacted>
Cc: Scott Wood <oss@buserror.net>
Cc: Kumar Gala <redacted>
Cc: Daniel Cashman <redacted>
Signed-off-by: Bhupesh Sharma <redacted>
Reviewed-by: Kees Cook <keescook at chromium.org>
---
Changes since v1:
v1 can be seen here (https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-February/153594.html)
- No functional change in this patch.
- Added R-B from Kees.
- Dropped PATCH 2/2 from v1 as recommended by Kees Cook.
Thanks for v2.
But I replied to your v1 with some comments, did you see them?
I have replied to your comments on the original thread.
Please share your views and if possible share your test results on the
PPC setups you might have at your end.
Thanks,
Bhupesh