Re: [PATCH v9 0/5] x86/KASLR: Add parameter kaslr_boot_mem=nn[KMG]@ss[KMG]

From: Dou Liyang
Date: Wed Mar 28 2018 - 21:47:17 EST


Hi Ingo, Kees, Baoquan and Chao

At 03/12/2018 06:57 PM, Ingo Molnar wrote:
[...]
So there's apparently a mis-design here:

- KASLR needs to be done very early on during bootup: - it's not realistic to
expect KASLR to be done with a booted up kernel, because pointers to various
KASLR-ed objects are already widely spread out in memory.

- But for some unfathomable reason the memory hotplug attribute of memory
regions is not part of the regular memory map but part of late-init ACPI data
structures.

The right solution would be _not_ to fudge the KASLR location, but to provide the
memory hotplug information to early code, preferably via the primary memory map.
KASLR can then make use of it and avoid those regions, just like it avoids other
memory regions already.

In addition to that hardware makers (including virtualized hardware) should also
fix their systems to provide memory hotplug information to early code.


Yes, but before this, can we fix this problem by the following patch which has been sent and reviewed by Kees before[1]. its solution is:

 Extend movable_node option to restrict kernel to be randomized in
 immovable nodes by adding a parameter. this parameter sets up
 the boundaries between the home nodes and other nodes.

My reason is here:

 - What we really want to solve is the KASLR breaks *physical Node
  hotplug*, Keep the decompressed kernel in an immovable node is
  enough.

 - AFAICS, there are not too many systems where physical Node hotplug
actually works in practice, and there mush be one node called *home
  node* which is immovable for storing basic information.

 - the node in modern systems could have double-digit gigabytes memory,
  It can completely satisfy the operation of KASLR.

So, Just restrict kernel to be randomized in the home node, and ignore
other nodes when kernel has the *movable_node* option in the command
line.

Thoughts? may I rebase and resend the patch?

[1] https://lkml.org/lkml/2017/8/3/401

Thanks,

dou