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 5/5] x86/boot/KASLR: Limit KASLR to extracting kernel in immovable memory
Date: Tue, 18 Dec 2018 10:49:52 +0800 [thread overview]
Message-ID: <20181218024951.GA10386@localhost.localdomain> (raw)
In-Reply-To: <20181217174324.GE90818@gmail.com>
On Mon, Dec 17, 2018 at 06:43:24PM +0100, Ingo Molnar wrote:
>
>* Chao Fan <fanc.fnst@cn.fujitsu.com> wrote:
>
>> KASLR randomly chooses some positions which may locate in movable
>> memory regions. It will break memory hotplug feature and make the
>> movable memory chosen by KASLR practically immovable.
>>
>> The solution is to limit KASLR to choose memory regions in immovable
>> node according to SRAT tables.
>> When CONFIG_EARLY_PARSE_RSDP is enabled, walk through SRAT to get the
>> information of immovable memory so that KASLR knows where should be
>> chosen for randomization.
>>
>> Rename process_mem_region() as __process_mem_region() and name new
>> function as process_mem_region().
>>
>> Signed-off-by: Chao Fan <fanc.fnst@cn.fujitsu.com>
>> ---
>> arch/x86/boot/compressed/kaslr.c | 75 +++++++++++++++++++++++++++-----
>> 1 file changed, 64 insertions(+), 11 deletions(-)
>
>Ok, I like this basic approach of automatically detecing memory areas we
>should not KASLR into - it's far better than earlier iterations.
Thanks,
>
>> +++ b/arch/x86/boot/compressed/kaslr.c
>> @@ -97,6 +97,11 @@ static bool memmap_too_large;
>> /* Store memory limit specified by "mem=nn[KMG]" or "memmap=nn[KMG]" */
>> static unsigned long long mem_limit = ULLONG_MAX;
>>
>> +#ifdef CONFIG_EARLY_SRAT_PARSE
>> +/* The immovable memory regions */
>> +extern struct mem_vector immovable_mem[MAX_NUMNODES*2];
>> +#endif
>
>What logic is the maximum size of this array based on?
>
Oh, sorry for that, I ever explained for that, I would add
more comments in next PATCH.
See arch/x86/mm/numa_internal.h:
struct numa_meminfo {
int nr_blks;
struct numa_memblk blk[NR_NODE_MEMBLKS];
};
In arch/x86/include/asm/numa.h:
#define NR_NODE_MEMBLKS (MAX_NUMNODES*2)
That means the memory in one node may be devided into 1 or 2 memory
regions(Also I saw that in the dmesg).
So think about how many regions we need to store the immovable memory.
The worst condition is:
1. There are MAX_NUMANODES nodes on this machine.
2. In SRAT table, every node is devided into 2 memory regions.
3. All of them are immovable.
So MAX_NUMNODES*2 is the biggest amount.
Thanks,
Chao Fan
>Thanks,
>
> Ingo
>
>
prev parent reply other threads:[~2018-12-18 2:50 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
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 [this message]
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=20181218024951.GA10386@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.