From: Ingo Molnar <mingo@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: Yinghai Lu <yinghai@kernel.org>, Borislav Petkov <bp@suse.de>,
Baoquan He <bhe@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "x86@kernel.org" <x86@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
"H.J. Lu" <hjl.tools@gmail.com>,
Dmitry Vyukov <dvyukov@google.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v9 5/5] x86/KASLR: Allow randomization below load address
Date: Fri, 17 Jun 2016 10:47:51 +0200 [thread overview]
Message-ID: <20160617084751.GB4791@gmail.com> (raw)
In-Reply-To: <1464216334-17200-6-git-send-email-keescook@chromium.org>
* Kees Cook <keescook@chromium.org> wrote:
> From: Yinghai Lu <yinghai@kernel.org>
>
> Currently the physical randomization's lower boundary is the original
> kernel load address. For bootloaders that load kernels into very high
> memory (e.g. kexec), this means randomization takes place in a very small
> window at the top of memory, ignoring the large region of physical memory
> below the load address.
>
> Since mem_avoid is already correctly tracking the regions that must be
> avoided, this patch changes the minimum address to whatever is less:
> 512M (to conservatively avoid unknown things in lower memory) or the
> load address. Now, for example, if the kernel is loaded at 8G, [512M,
> 8G) will be added into possible physical memory positions.
>
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> [kees: rewrote changelog, refactor to use min()]
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> arch/x86/boot/compressed/kaslr.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
> index d0a823df183b..304c5c369aff 100644
> --- a/arch/x86/boot/compressed/kaslr.c
> +++ b/arch/x86/boot/compressed/kaslr.c
> @@ -492,7 +492,7 @@ void choose_random_location(unsigned long input,
> unsigned long output_size,
> unsigned long *virt_addr)
> {
> - unsigned long random_addr;
> + unsigned long random_addr, min_addr;
>
> /* By default, keep output position unchanged. */
> *virt_addr = *output;
> @@ -517,8 +517,11 @@ void choose_random_location(unsigned long input,
> /* Record the various known unsafe memory ranges. */
> mem_avoid_init(input, input_size, *output);
>
> + /* Low end should be the smaller of 512M or initial location. */
> + min_addr = min(*output, 512UL << 20);
> +
> /* Walk e820 and find a random address. */
> - random_addr = find_random_phys_addr(*output, output_size);
> + random_addr = find_random_phys_addr(min_addr, output_size);
> if (!random_addr) {
> warn("KASLR disabled: could not find suitable E820 region!");
> } else {
There's no explanation in the code or in the changelog of why 512M was picked as
the lower limit.
Thanks,
Ingo
next prev parent reply other threads:[~2016-06-17 8:47 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-25 22:45 [PATCH v9 0/5] x86/KASLR: Randomize virtual address separately Kees Cook
2016-05-25 22:45 ` [PATCH v9 1/5] x86/boot: Refuse to build with data relocations Kees Cook
2016-06-17 12:22 ` [tip:x86/boot] " tip-bot for Kees Cook
2016-06-26 11:01 ` tip-bot for Kees Cook
2016-05-25 22:45 ` [PATCH v9 2/5] x86/KASLR: Clarify identity map interface Kees Cook
2016-06-17 12:22 ` [tip:x86/boot] " tip-bot for Kees Cook
2016-06-26 11:02 ` tip-bot for Kees Cook
2016-05-25 22:45 ` [PATCH v9 3/5] x86/KASLR: Randomize virtual address separately Kees Cook
2016-06-17 8:20 ` Ingo Molnar
2016-06-17 8:35 ` Ingo Molnar
2016-06-17 12:22 ` [tip:x86/boot] " tip-bot for Baoquan He
2016-06-26 11:02 ` tip-bot for Baoquan He
2016-05-25 22:45 ` [PATCH v9 4/5] x86/KASLR: Add physical address randomization >4G Kees Cook
2016-06-17 12:23 ` [tip:x86/boot] x86/KASLR: Extend kernel image physical address randomization to addresses larger than 4G tip-bot for Kees Cook
2016-06-26 11:02 ` tip-bot for Kees Cook
2016-05-25 22:45 ` [PATCH v9 5/5] x86/KASLR: Allow randomization below load address Kees Cook
2016-06-17 8:47 ` Ingo Molnar [this message]
2016-06-17 15:44 ` Kees Cook
2016-06-17 18:44 ` Yinghai Lu
2016-06-17 12:23 ` [tip:x86/boot] x86/KASLR: Allow randomization below the " tip-bot for Yinghai Lu
2016-06-26 11:03 ` tip-bot for Yinghai Lu
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=20160617084751.GB4791@gmail.com \
--to=mingo@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=aryabinin@virtuozzo.com \
--cc=bhe@redhat.com \
--cc=bp@suse.de \
--cc=dvyukov@google.com \
--cc=hjl.tools@gmail.com \
--cc=hpa@zytor.com \
--cc=jpoimboe@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yinghai@kernel.org \
/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.