From: Borislav Petkov <bp@alien8.de>
To: Julian Stecklina <js@alien8.de>
Cc: x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
hpa@zytor.com, linux-kernel@vger.kernel.org, jschoenh@amazon.de,
Julian Stecklina <jsteckli@amazon.de>,
Dave Jiang <dave.jiang@intel.com>,
Kees Cook <keescook@chromium.org>, Baoquan He <bhe@redhat.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 2/2] x86/boot: increase maximum number of avoided KASLR regions
Date: Tue, 5 Feb 2019 15:44:41 +0100 [thread overview]
Message-ID: <20190205144441.GS21801@zn.tnic> (raw)
In-Reply-To: <1548866403-13390-2-git-send-email-js@alien8.de>
On Wed, Jan 30, 2019 at 05:40:03PM +0100, Julian Stecklina wrote:
> From: Julian Stecklina <jsteckli@amazon.de>
>
> The boot code has a limit of 4 "non-standard" regions to avoid for
> KASLR. This limit is easy to reach when supplying memmap= parameters to
> the kernel. In this case, KASLR would be disabled.
>
> Increase the limit to avoid turning off KASLR even when the user is
> heavily manipulating the memory map.
>
> Signed-off-by: Julian Stecklina <jsteckli@amazon.de>
> ---
> arch/x86/boot/compressed/kaslr.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
> index 5657e34..f078d60 100644
> --- a/arch/x86/boot/compressed/kaslr.c
> +++ b/arch/x86/boot/compressed/kaslr.c
> @@ -92,8 +92,8 @@ struct mem_vector {
> unsigned long long size;
> };
>
> -/* Only supporting at most 4 unusable memmap regions with kaslr */
> -#define MAX_MEMMAP_REGIONS 4
> +/* Only supporting at most this many unusable memmap regions with kaslr */
> +#define MAX_MEMMAP_REGIONS 16
>
> static bool memmap_too_large;
>
> @@ -213,7 +213,7 @@ static void mem_avoid_memmap(char *str)
> i++;
> }
>
> - /* More than 4 memmaps, fail kaslr */
> + /* Can't store all regions, fail kaslr */
> if ((i >= MAX_MEMMAP_REGIONS) && str)
> memmap_too_large = true;
> }
> --
Lemme add some of the folks from
f28442497b5caf7bf573ade22a7f8d3559e3ef56 to Cc.
It all looks arbitrary to me: first 4 unusable memmap regions, this
patch raises it to 16. Why are we even imposing such a limit?
Hmm.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
next prev parent reply other threads:[~2019-02-05 14:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-30 16:40 [PATCH 1/2] x86/boot: fix KASL when memmap range manipulation is used Julian Stecklina
2019-01-30 16:40 ` [PATCH 2/2] x86/boot: increase maximum number of avoided KASLR regions Julian Stecklina
2019-02-05 14:44 ` Borislav Petkov [this message]
2019-02-06 12:50 ` Julian Stecklina
2019-02-06 14:17 ` Borislav Petkov
2019-02-06 15:29 ` Kees Cook
2019-02-06 17:53 ` Borislav Petkov
2019-02-11 9:09 ` [PATCH 1/2] x86/boot: fix KASL when memmap range manipulation is used Baoquan He
2019-02-11 9:54 ` Julian Stecklina
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=20190205144441.GS21801@zn.tnic \
--to=bp@alien8.de \
--cc=bhe@redhat.com \
--cc=dave.jiang@intel.com \
--cc=hpa@zytor.com \
--cc=js@alien8.de \
--cc=jschoenh@amazon.de \
--cc=jsteckli@amazon.de \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@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.