From: Ingo Molnar <mingo@kernel.org>
To: Baoquan He <bhe@redhat.com>
Cc: linux-kernel@vger.kernel.org, keescook@chromium.org,
dave.jiang@intel.com, dan.j.williams@intel.com, hpa@zytor.com,
tglx@linutronix.de, dyoung@redhat.com
Subject: Re: [PATCH 0/4] Handle memmap and mem kernel options in boot stage kaslr
Date: Tue, 18 Apr 2017 11:47:53 +0200 [thread overview]
Message-ID: <20170418094753.q2siun6mkjoneqcn@gmail.com> (raw)
In-Reply-To: <1492436099-4017-1-git-send-email-bhe@redhat.com>
* Baoquan He <bhe@redhat.com> wrote:
> People reported kernel panic occurs during system boots up with mem boot option.
> After checking code, several problems are found about memmap= and mem= in boot stage
> kaslr.
>
> *) In commit f28442497b5c ("x86/boot: Fix KASLR and memmap= collision"), only one memmap
> entry is considered and only the last one if multiple memmap entries are specified.
>
> *) mem= and memmap=nn[KMG] are not considered yet. They are used to limit max address
> of system. Kernel can't be randomized to be above the limit.
>
> *) kernel-parameters.txt doesn't tell the updated behaviour of memmap=.
>
> This patchset tries to solve above issues.
>
> Baoquan He (4):
> param: Move function next_arg to lib/cmdline.c for later reuse
> KASLR: Parse all memmap entries in cmdline
> KASLR: Handle memory limit specified by memmap and mem option
> doc: Update description about memmap option in kernel-parameter.txt
>
> Documentation/admin-guide/kernel-parameters.txt | 9 ++
> arch/x86/boot/compressed/cmdline.c | 2 +-
> arch/x86/boot/compressed/kaslr.c | 161 ++++++++++++++----------
> arch/x86/boot/string.c | 8 ++
> include/linux/kernel.h | 1 +
> kernel/params.c | 52 --------
> lib/cmdline.c | 57 +++++++++
> 7 files changed, 172 insertions(+), 118 deletions(-)
I ported this series to tip:x86/boot (please post future versions against that),
and beyond a trivial conflict with e820entry => e820_entry, it fails to build on
32-bit allmodconfig:
ld: -r and -shared may not be used together
scripts/Makefile.build:294: recipe for target 'arch/x86/boot/compressed/kaslr.o' failed
... which could be due to bad relocations, but I've not dug any further.
Please also pick up the fixed/rewritten changelogs from the git log below for the
next version.
Thanks,
Ingo
====================>
Documentation/kernel-parameters.txt: Update 'memmap=' option description
In commit:
9710f581bb4c ("x86, mm: Let "memmap=" take more entries one time")
... 'memmap=' was changed to adopt multiple, comma delimited values in a
single entry, so update the related description.
In the special case of only specifying size value without an offset,
like memmap=nn[KMG], memmap behaves similarly to mem=nn[KMG], so update
it too here.
Furthermore, for memmap=nn[KMG]$ss[KMG], an escape character needs be added
before '$' for some bootloaders. E.g in grub2, if we specify memmap=100M$5G
as suggested by the documentation, "memmap=100MG" gets passed to the kernel.
Clarify all this.
----
KASLR: Handle memory limit specified by memmap and mem option
Option mem= will limit the max address a system can use and any memory
region above the limit will be removed.
Furthermore, memmap=nn[KMG] which has no offset specified has the same
behaviour as mem=.
KASLR needs to consider this when choosing the random position for
decompressing the kernel.
This patch implements that.
----
KASLR: Parse all memmap entries in cmdline
In commit:
f28442497b5c ("x86/boot: Fix KASLR and memmap= collision")
... the memmap= option is parsed so that KASLR can avoid those reserved
regions. It uses cmdline_find_option() to get the value if memmap=
is specified, however the problem is that cmdline_find_option() can only
find the last entry if multiple memmap entries are provided. This
is not correct.
In this patch, the whole cmdline will be scanned to search each
memmap, all of them will be parsed and handled.
----
boot/param: Move next_arg() function to lib/cmdline.c for later reuse
next_arg() will be used to parse boot parameters in the x86/boot/compressed code,
so move it to lib/cmdline.c for better code reuse.
No change in functionality.
next prev parent reply other threads:[~2017-04-18 9:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-17 13:34 [PATCH 0/4] Handle memmap and mem kernel options in boot stage kaslr Baoquan He
2017-04-17 13:34 ` [PATCH 1/4] param: Move function next_arg to lib/cmdline.c for later reuse Baoquan He
2017-04-18 12:51 ` [tip:x86/boot] boot/param: Move next_arg() function " tip-bot for Baoquan He
2017-04-18 20:17 ` [PATCH 1/4] param: Move function next_arg " Kees Cook
2017-04-17 13:34 ` [PATCH 2/4] KASLR: Parse all memmap entries in cmdline Baoquan He
2017-04-18 20:22 ` Kees Cook
2017-04-18 22:52 ` Baoquan He
2017-04-18 23:32 ` Kees Cook
2017-04-19 0:07 ` Baoquan He
2017-04-17 13:34 ` [PATCH 3/4] KASLR: Handle memory limit specified by memmap and mem option Baoquan He
2017-04-18 20:36 ` Kees Cook
2017-04-18 23:12 ` Baoquan He
2017-04-19 0:50 ` Baoquan He
2017-04-19 0:59 ` Baoquan He
2017-04-17 13:34 ` [PATCH 4/4] doc: Update description about memmap option in kernel-parameter.txt Baoquan He
2017-04-18 9:47 ` Ingo Molnar [this message]
2017-04-18 11:38 ` [PATCH 0/4] Handle memmap and mem kernel options in boot stage kaslr Baoquan He
2017-04-18 12:51 ` Ingo Molnar
2017-04-19 0:09 ` Baoquan He
2017-04-20 13:59 ` Baoquan He
2017-04-24 2:46 ` Baoquan He
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=20170418094753.q2siun6mkjoneqcn@gmail.com \
--to=mingo@kernel.org \
--cc=bhe@redhat.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dyoung@redhat.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox