Re: [PATCH 0/4] Handle memmap and mem kernel options in boot stage kaslr

From: Baoquan He
Date: Tue Apr 18 2017 - 07:38:23 EST


On 04/18/17 at 11:47am, Ingo Molnar wrote:
>
> * Baoquan He <bhe@xxxxxxxxxx> 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.

Thanks, Ingo!

I will find a x86_32 system to try allmodconfig.

>
> Please also pick up the fixed/rewritten changelogs from the git log below for the
> next version.

Will do, thanks a lot!

>
> 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.
>