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

[Baoquan He <bhe@redhat.com>]

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

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