From: Chao Fan <fanc.fnst@cn.fujitsu.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: <linux-kernel@vger.kernel.org>, <x86@kernel.org>, <bp@alien8.de>,
<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>,
<keescook@chromium.org>, <bhe@redhat.com>,
<msys.mizuma@gmail.com>, <indou.takao@jp.fujitsu.com>,
<caoj.fnst@cn.fujitsu.com>
Subject: Re: [PATCH v14 1/5] x86/boot: Introduce get_acpi_rsdp() to parse RSDP in cmdline from KEXEC
Date: Tue, 18 Dec 2018 09:27:04 +0800 [thread overview]
Message-ID: <20181218012704.GB31775@localhost.localdomain> (raw)
In-Reply-To: <20181217172510.GA90818@gmail.com>
On Mon, Dec 17, 2018 at 06:25:10PM +0100, Ingo Molnar wrote:
>
>* Chao Fan <fanc.fnst@cn.fujitsu.com> wrote:
>
>> Memory information in SRAT is necessary to fix the conflict between
>> KASLR and memory-hotremove.
>>
>> ACPI SRAT (System/Static Resource Affinity Table) shows the details
>> about memory ranges, including ranges of memory provided by hot-added
>> memory devices. SRAT is introduced by Root System Description
>> Pointer(RSDP), so RSDP should be found firstly.
>>
>> When booting form KEXEC/EFI/BIOS, the methods to find RSDP
>> are different. When booting from KEXEC, 'acpi_rsdp' may have been
>> added to cmdline, so parse cmdline to find RSDP.
>
>What is the nature of the basic conflict? Should the kernel only allow
>hot-removing memory ranges that are explicitly marked as such in the
>SRAT? I presume that's already so, correct? Or should the kernel avoiding
>KASLR-randomizing into hot-removable memory areas?
The basic conflict is the kernel avoiding KASLR-randomizing into
hot-removable memory areas.
>
>Some minor nits:
>
>> Signed-off-by: Chao Fan <fanc.fnst@cn.fujitsu.com>
>> ---
>> arch/x86/boot/compressed/acpi.c | 30 ++++++++++++++++++++++++++++++
>> 1 file changed, 30 insertions(+)
>> create mode 100644 arch/x86/boot/compressed/acpi.c
>>
>> diff --git a/arch/x86/boot/compressed/acpi.c b/arch/x86/boot/compressed/acpi.c
>> new file mode 100644
>> index 000000000000..44f19546c169
>> --- /dev/null
>> +++ b/arch/x86/boot/compressed/acpi.c
>> @@ -0,0 +1,30 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +#define BOOT_CTYPE_H
>> +#include "misc.h"
>> +#include "error.h"
>> +
>> +#include <linux/efi.h>
>> +#include <linux/numa.h>
>> +#include <linux/acpi.h>
>> +#include <asm/efi.h>
>> +
>> +/* Max length of 64-bit hex address string is 18, prefix "0x" + 16 hex digits */
>> +#define MAX_ADDRESS_LENGTH 18
>
>I'd suggest adding the +1 for the string termination \0 as well, and use
>that below.
>
>Also, 'max address length' is way too generic (and hence pretty
>meaningless) - how about MAX_HEX_ADDRESS_STRING_LEN or so?
OK, I will change the name and add the \0.
Thanks,
Chao Fan
>
>> +
>> +static acpi_physical_address get_acpi_rsdp(void)
>> +{
>> +#ifdef CONFIG_KEXEC
>> + char val[MAX_ADDRESS_LENGTH+1];
>> + unsigned long long res;
>> + int len;
>> +
>> + len = cmdline_find_option("acpi_rsdp", val, MAX_ADDRESS_LENGTH+1);
>> + if (len > 0) {
>> + char *e;
>> +
>> + val[len] = '\0';
>> + return (acpi_physical_address)simple_strtoull(val, &e, 16);
>
>'return' is not a function - no need for the parenthesis.
>
>Thanks,
>
> Ingo
>
>
next prev parent reply other threads:[~2018-12-18 1:27 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-14 9:30 [PATCH v14 0/5] x86/boot/KASLR: Parse ACPI table and limit KASLR to choosing immovable memory Chao Fan
2018-12-14 9:30 ` [PATCH v14 1/5] x86/boot: Introduce get_acpi_rsdp() to parse RSDP in cmdline from KEXEC Chao Fan
2018-12-17 17:25 ` Ingo Molnar
2018-12-17 18:31 ` Thomas Gleixner
2018-12-17 18:48 ` Ingo Molnar
2018-12-18 1:27 ` Chao Fan [this message]
2018-12-18 11:28 ` Borislav Petkov
2018-12-19 1:18 ` Chao Fan
2018-12-14 9:30 ` [PATCH v14 2/5] x86/boot: Introduce efi_get_rsdp_addr() to find RSDP from EFI table Chao Fan
2018-12-17 17:30 ` Ingo Molnar
2018-12-17 17:36 ` Ingo Molnar
2018-12-25 7:43 ` Chao Fan
2018-12-17 18:32 ` Thomas Gleixner
2018-12-17 18:49 ` Ingo Molnar
2018-12-18 1:45 ` Chao Fan
2018-12-14 9:30 ` [PATCH v14 3/5] x86/boot: Introduce bios_get_rsdp_addr() to search RSDP in memory Chao Fan
2018-12-17 17:38 ` Ingo Molnar
2018-12-18 2:28 ` Chao Fan
2018-12-14 9:30 ` [PATCH v14 4/5] x86/boot: Parse SRAT address from RSDP and store immovable memory Chao Fan
2018-12-17 17:41 ` Ingo Molnar
2018-12-18 3:17 ` Chao Fan
2018-12-14 9:30 ` [PATCH v14 5/5] x86/boot/KASLR: Limit KASLR to extracting kernel in " Chao Fan
2018-12-17 17:43 ` Ingo Molnar
2018-12-18 2:49 ` Chao Fan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181218012704.GB31775@localhost.localdomain \
--to=fanc.fnst@cn.fujitsu.com \
--cc=bhe@redhat.com \
--cc=bp@alien8.de \
--cc=caoj.fnst@cn.fujitsu.com \
--cc=hpa@zytor.com \
--cc=indou.takao@jp.fujitsu.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=msys.mizuma@gmail.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.