From: Michael Ellerman <patch-notifications@ellerman.id.au>
To: Michael Ellerman <mpe@ellerman.id.au>, linuxppc-dev@ozlabs.org
Cc: bhsharma@redhat.com, keescook@chromium.org,
kernel-hardening@lists.openwall.com
Subject: [kernel-hardening] Re: [v2] powerpc/mm: Add support for runtime configuration of ASLR limits
Date: Sun, 23 Apr 2017 21:53:21 +1000 (AEST) [thread overview]
Message-ID: <3w9nt9601Wz9s2P@ozlabs.org> (raw)
In-Reply-To: <1492698980-19510-1-git-send-email-mpe@ellerman.id.au>
On Thu, 2017-04-20 at 14:36:20 UTC, Michael Ellerman wrote:
> Add powerpc support for mmap_rnd_bits and mmap_rnd_compat_bits, which are two
> sysctls that allow a user to configure the number of bits of randomness used for
> ASLR.
>
> Because of the way the Kconfig for ARCH_MMAP_RND_BITS is defined, we have to
> construct at least the MIN value in Kconfig, vs in a header which would be more
> natural. Given that we just go ahead and do it all in Kconfig.
>
> At least according to the code (the documentation makes no mention of it), the
> value is defined as the number of bits of randomisation *of the page*, not the
> address. This makes some sense, with larger page sizes more of the low bits are
> forced to zero, which would reduce the randomisation if we didn't take the
> PAGE_SIZE into account. However it does mean the min/max values have to change
> depending on the PAGE_SIZE in order to actually limit the amount of address
> space consumed by the randomisation.
>
> The result of that is that we have to define the default values based on both
> 32-bit vs 64-bit, but also the configured PAGE_SIZE. Furthermore now that we
> have 128TB address space support on Book3S, we also have to take that into
> account.
>
> Finally we can wire up the value in arch_mmap_rnd().
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
> Reviewed-by: Kees Cook <keescook@chromium.org>
> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/9fea59bd7ca541e5d0851f0b6dbca8
cheers
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <patch-notifications@ellerman.id.au>
To: Michael Ellerman <mpe@ellerman.id.au>, linuxppc-dev@ozlabs.org
Cc: bhsharma@redhat.com, keescook@chromium.org,
kernel-hardening@lists.openwall.com
Subject: Re: [v2] powerpc/mm: Add support for runtime configuration of ASLR limits
Date: Sun, 23 Apr 2017 21:53:21 +1000 (AEST) [thread overview]
Message-ID: <3w9nt9601Wz9s2P@ozlabs.org> (raw)
In-Reply-To: <1492698980-19510-1-git-send-email-mpe@ellerman.id.au>
On Thu, 2017-04-20 at 14:36:20 UTC, Michael Ellerman wrote:
> Add powerpc support for mmap_rnd_bits and mmap_rnd_compat_bits, which are two
> sysctls that allow a user to configure the number of bits of randomness used for
> ASLR.
>
> Because of the way the Kconfig for ARCH_MMAP_RND_BITS is defined, we have to
> construct at least the MIN value in Kconfig, vs in a header which would be more
> natural. Given that we just go ahead and do it all in Kconfig.
>
> At least according to the code (the documentation makes no mention of it), the
> value is defined as the number of bits of randomisation *of the page*, not the
> address. This makes some sense, with larger page sizes more of the low bits are
> forced to zero, which would reduce the randomisation if we didn't take the
> PAGE_SIZE into account. However it does mean the min/max values have to change
> depending on the PAGE_SIZE in order to actually limit the amount of address
> space consumed by the randomisation.
>
> The result of that is that we have to define the default values based on both
> 32-bit vs 64-bit, but also the configured PAGE_SIZE. Furthermore now that we
> have 128TB address space support on Book3S, we also have to take that into
> account.
>
> Finally we can wire up the value in arch_mmap_rnd().
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
> Reviewed-by: Kees Cook <keescook@chromium.org>
> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/9fea59bd7ca541e5d0851f0b6dbca8
cheers
next prev parent reply other threads:[~2017-04-23 11:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-20 14:36 [kernel-hardening] [PATCH v2] powerpc/mm: Add support for runtime configuration of ASLR limits Michael Ellerman
2017-04-20 14:36 ` Michael Ellerman
2017-04-20 20:08 ` [kernel-hardening] " Kees Cook
2017-04-20 20:08 ` Kees Cook
2017-04-21 5:51 ` [kernel-hardening] " Aneesh Kumar K.V
2017-04-21 5:51 ` Aneesh Kumar K.V
2017-04-21 6:49 ` [kernel-hardening] " Bhupesh Sharma
2017-04-21 6:49 ` Bhupesh Sharma
2017-04-23 11:53 ` Michael Ellerman [this message]
2017-04-23 11:53 ` [v2] " Michael Ellerman
2017-04-24 1:02 ` [kernel-hardening] Re: [PATCH v2] " Balbir Singh
2017-04-24 1:02 ` Balbir Singh
2017-04-24 14:29 ` [kernel-hardening] " Michael Ellerman
2017-04-24 17:56 ` Kees Cook
2017-04-24 22:44 ` Michael Ellerman
2017-04-24 22:44 ` Michael Ellerman
2017-04-25 0:56 ` Balbir Singh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3w9nt9601Wz9s2P@ozlabs.org \
--to=patch-notifications@ellerman.id.au \
--cc=bhsharma@redhat.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=mpe@ellerman.id.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.