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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 18 Apr 2017 11:47:53 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Baoquan He <bhe@...hat.com>
Cc:     linux-kernel@...r.kernel.org, keescook@...omium.org,
        dave.jiang@...el.com, dan.j.williams@...el.com, hpa@...or.com,
        tglx@...utronix.de, dyoung@...hat.com
Subject: Re: [PATCH 0/4] Handle memmap and mem kernel options in boot stage
 kaslr

* Baoquan He <bhe@...hat.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.