[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181217174149.GD90818@gmail.com>
Date: Mon, 17 Dec 2018 18:41:49 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Chao Fan <fanc.fnst@...fujitsu.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org, bp@...en8.de,
tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
keescook@...omium.org, bhe@...hat.com, msys.mizuma@...il.com,
indou.takao@...fujitsu.com, caoj.fnst@...fujitsu.com
Subject: Re: [PATCH v14 4/5] x86/boot: Parse SRAT address from RSDP and store
immovable memory
* Chao Fan <fanc.fnst@...fujitsu.com> wrote:
> SRAT should be parsed by RSDP to fix the conflict between KASLR
> and memory-hotremove, then find the immovable memory regions and store
> them in an array called immovable_mem[]. With immovable_mem[], KASLR
> can avoid to extract kernel to specific regions.
>
> Since 'RANDOMIZE_BASE' && 'MEMORY_HOTREMOVE' is needed, introduce
> 'CONFIG_EARLY_PARSE_RSDP' to make ifdeffery clear.
>
> Signed-off-by: Chao Fan <fanc.fnst@...fujitsu.com>
> ---
> arch/x86/Kconfig | 12 +++
> arch/x86/boot/compressed/Makefile | 2 +
> arch/x86/boot/compressed/acpi.c | 128 ++++++++++++++++++++++++++++++
> arch/x86/boot/compressed/kaslr.c | 4 -
> arch/x86/boot/compressed/misc.h | 19 +++++
> 5 files changed, 161 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index ba7e3464ee92..333c383478b7 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2149,6 +2149,18 @@ config X86_NEED_RELOCS
> def_bool y
> depends on RANDOMIZE_BASE || (X86_32 && RELOCATABLE)
>
> +config EARLY_SRAT_PARSE
> + bool "Early SRAT table parsing"
> + def_bool y
> + depends on RANDOMIZE_BASE && MEMORY_HOTREMOVE
> + help
> + This option enables early SRAT parsing in compressed boot stage
> + so that memory hot-remove ranges do not overlap with KASLR
> + chosen ranges. Kernel won't be extracted in hot-removable
> + memory, so that make sure memory-hotremove works well with
> + KASLR enabled.
> + Say Y if you want to use both KASLR and memory-hotremove.
So why would we want to make this a config option, instead of enabling it
unconditionally?
How reliable are the hot-removable memory markings in various firmware
versions?
> +/* Compute SRAT table from RSDP. */
> +static struct acpi_table_header *get_acpi_srat_table(void)
> +{
> + acpi_physical_address acpi_table;
> + acpi_physical_address root_table;
> + struct acpi_table_header *header;
> + struct acpi_table_rsdp *rsdp;
> + u32 num_entries;
> + char arg[10];
The '10' is just a magic number attached to a meaningless local variable
name. Please explain the limit in the code, and the role of the variable
if it's non-obvious from the name. Or better, try to find a more obvious
name?
Thanks,
Ingo
Powered by blists - more mailing lists