From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755737AbdDRJsR (ORCPT ); Tue, 18 Apr 2017 05:48:17 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:34267 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755942AbdDRJr6 (ORCPT ); Tue, 18 Apr 2017 05:47:58 -0400 Date: Tue, 18 Apr 2017 11:47:53 +0200 From: Ingo Molnar To: Baoquan He 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 Message-ID: <20170418094753.q2siun6mkjoneqcn@gmail.com> References: <1492436099-4017-1-git-send-email-bhe@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1492436099-4017-1-git-send-email-bhe@redhat.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Baoquan He 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.