[RESEND] [PATCH 1/2] x86/mm: Add an option to change the padding used for the physical memory mapping.

[RESEND] [PATCH 1/2] x86/mm: Add an option to change the padding used for the physical memory mapping.

[Masayoshi Mizuma]

From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>

There are some exceptional cases that the padding used for the physical
memory mapping section is not enough.

For example of the cases:
- As Baoquan reported in the following, SGI UV system.
  https://lkml.org/lkml/2017/9/7/87
- Each node of physical memory layout has huge space for hotplug.
  For exapmle of the layout:
    SRAT: Node 6 PXM 4 [mem 0x100000000000-0x13ffffffffff] hotplug
    SRAT: Node 7 PXM 5 [mem 0x140000000000-0x17ffffffffff] hotplug
    SRAT: Node 2 PXM 6 [mem 0x180000000000-0x1bffffffffff] hotplug
    SRAT: Node 3 PXM 7 [mem 0x1c0000000000-0x1fffffffffff] hotplug

We can increase the padding by CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING,
however, the available entropy is decreased if the padding is increased.
So the config change is not very good for the other most of systems.
And, the needed padding size depends on the system environment, for
example physical memory layout, so the kernel option is better than
changing the config.

Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
---
 arch/x86/mm/kaslr.c | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index 61db77b..8c7b4f6 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -33,6 +33,9 @@
 
 #define TB_SHIFT 40
 
+#define MAX_PADDING_L4 63
+#define MAX_PADDING_L5 32767
+
 /*
  * The end address could depend on more configuration options to make the
  * highest amount of space for randomization available, but that's too hard
@@ -40,6 +43,7 @@
  */
 static const unsigned long vaddr_end = CPU_ENTRY_AREA_BASE;
 
+static int __initdata rand_mem_physical_padding = CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING;
 /*
  * Memory regions randomized by KASLR (except modules that use a separate logic
  * earlier during boot). The list is ordered based on virtual addresses. This
@@ -69,6 +73,20 @@ static inline bool kaslr_memory_enabled(void)
 	return kaslr_enabled() && !IS_ENABLED(CONFIG_KASAN);
 }
 
+static int __init rand_mem_physical_padding_setup(char *str)
+{
+	int max_padding = pgtable_l5_enabled() ? MAX_PADDING_L5 : MAX_PADDING_L4;
+
+	get_option(&str, &rand_mem_physical_padding);
+	if (rand_mem_physical_padding < 0)
+		rand_mem_physical_padding = 0;
+	else if (rand_mem_physical_padding > max_padding)
+		rand_mem_physical_padding = max_padding;
+
+	return 0;
+}
+early_param("rand_mem_physical_padding", rand_mem_physical_padding_setup);
+
 /* Initialize base and padding for each memory region randomized with KASLR */
 void __init kernel_randomize_memory(void)
 {
@@ -102,7 +120,7 @@ void __init kernel_randomize_memory(void)
 	 */
 	BUG_ON(kaslr_regions[0].base != &page_offset_base);
 	memory_tb = DIV_ROUND_UP(max_pfn << PAGE_SHIFT, 1UL << TB_SHIFT) +
-		CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING;
+		rand_mem_physical_padding;
 
 	/* Adapt phyiscal memory region size based on available memory */
 	if (memory_tb < kaslr_regions[0].size_tb)
-- 
2.18.0

[RESEND] [PATCH 2/2] docs: kernel-parameters.txt: document rand_mem_physical_padding parameter

[Masayoshi Mizuma]

From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>

This kernel parameter allows to change the padding used for the physical
memory mapping section when KASLR memory is enabled.

For some systems, the default value, CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING,
is not enough. The option is useful to adjust the padding size to work
around such issue.

Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
---
 Documentation/admin-guide/kernel-parameters.txt | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 533ff5c..d977091 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3382,6 +3382,13 @@
 	ramdisk_size=	[RAM] Sizes of RAM disks in kilobytes
 			See Documentation/blockdev/ramdisk.txt.
 
+	rand_mem_physical_padding=
+			[KNL] Define the padding size in terabytes
+			used for the physical memory mapping section
+			when KASLR memory is enabled.
+			The default value is
+			CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING.
+
 	ras=option[,option,...]	[KNL] RAS-specific options
 
 		cec_disable	[X86]
-- 
2.18.0

Re: [RESEND] [PATCH 1/2] x86/mm: Add an option to change the padding used for the physical memory mapping.

[Baoquan He]

Hi Masa,

On 08/21/18 at 09:24am, Masayoshi Mizuma wrote:
> From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
> 
> There are some exceptional cases that the padding used for the physical
> memory mapping section is not enough.
> 
> For example of the cases:
> - As Baoquan reported in the following, SGI UV system.
>   https://lkml.org/lkml/2017/9/7/87
> - Each node of physical memory layout has huge space for hotplug.
>   For exapmle of the layout:
>     SRAT: Node 6 PXM 4 [mem 0x100000000000-0x13ffffffffff] hotplug
>     SRAT: Node 7 PXM 5 [mem 0x140000000000-0x17ffffffffff] hotplug
>     SRAT: Node 2 PXM 6 [mem 0x180000000000-0x1bffffffffff] hotplug
>     SRAT: Node 3 PXM 7 [mem 0x1c0000000000-0x1fffffffffff] hotplug
> 
> We can increase the padding by CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING,
> however, the available entropy is decreased if the padding is increased.
> So the config change is not very good for the other most of systems.
> And, the needed padding size depends on the system environment, for
> example physical memory layout, so the kernel option is better than
> changing the config.
> 
> Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
> ---
>  arch/x86/mm/kaslr.c | 20 +++++++++++++++++++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
> index 61db77b..8c7b4f6 100644
> --- a/arch/x86/mm/kaslr.c
> +++ b/arch/x86/mm/kaslr.c
> @@ -33,6 +33,9 @@
>  
>  #define TB_SHIFT 40

I think this fix makes sense. Since we usually compiled in hotplug code
by default, while may not really hot plug a memory board on most of
systems. However on those systems which really need do hot plug, and
might plug memory board onto physical position above 10TB, this will
cause issues.

One tiny concern is that we have below definition for 5-level, means we
can only have 4PB of system RAM for now. Not sure if one day it will be
enlarged to 32PB as Documentation/x86/x86_64/mm.txt tell.

# define MAX_PHYSMEM_BITS       (pgtable_l5_enabled() ? 52 : 46)

Otherwise this patchset looks good to me.

Thanks
Baoquan

>  
> +#define MAX_PADDING_L4 63
> +#define MAX_PADDING_L5 32767
> +
>  /*
>   * The end address could depend on more configuration options to make the
>   * highest amount of space for randomization available, but that's too hard
> @@ -40,6 +43,7 @@
>   */
>  static const unsigned long vaddr_end = CPU_ENTRY_AREA_BASE;
>  
> +static int __initdata rand_mem_physical_padding = CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING;
>  /*
>   * Memory regions randomized by KASLR (except modules that use a separate logic
>   * earlier during boot). The list is ordered based on virtual addresses. This
> @@ -69,6 +73,20 @@ static inline bool kaslr_memory_enabled(void)
>  	return kaslr_enabled() && !IS_ENABLED(CONFIG_KASAN);
>  }
>  
> +static int __init rand_mem_physical_padding_setup(char *str)
> +{
> +	int max_padding = pgtable_l5_enabled() ? MAX_PADDING_L5 : MAX_PADDING_L4;
> +
> +	get_option(&str, &rand_mem_physical_padding);
> +	if (rand_mem_physical_padding < 0)
> +		rand_mem_physical_padding = 0;
> +	else if (rand_mem_physical_padding > max_padding)
> +		rand_mem_physical_padding = max_padding;
> +
> +	return 0;
> +}
> +early_param("rand_mem_physical_padding", rand_mem_physical_padding_setup);
> +
>  /* Initialize base and padding for each memory region randomized with KASLR */
>  void __init kernel_randomize_memory(void)
>  {
> @@ -102,7 +120,7 @@ void __init kernel_randomize_memory(void)
>  	 */
>  	BUG_ON(kaslr_regions[0].base != &page_offset_base);
>  	memory_tb = DIV_ROUND_UP(max_pfn << PAGE_SHIFT, 1UL << TB_SHIFT) +
> -		CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING;
> +		rand_mem_physical_padding;
>  
>  	/* Adapt phyiscal memory region size based on available memory */
>  	if (memory_tb < kaslr_regions[0].size_tb)
> -- 
> 2.18.0
> 

Re: [RESEND] [PATCH 1/2] x86/mm: Add an option to change the padding used for the physical memory mapping.

[Masayoshi Mizuma]

Hi Baoquan,

On 08/21/2018 10:51 AM, Baoquan He wrote:
> Hi Masa,
> 
> On 08/21/18 at 09:24am, Masayoshi Mizuma wrote:
>> From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
>>
>> There are some exceptional cases that the padding used for the physical
>> memory mapping section is not enough.
>>
>> For example of the cases:
>> - As Baoquan reported in the following, SGI UV system.
>>   https://lkml.org/lkml/2017/9/7/87
>> - Each node of physical memory layout has huge space for hotplug.
>>   For exapmle of the layout:
>>     SRAT: Node 6 PXM 4 [mem 0x100000000000-0x13ffffffffff] hotplug
>>     SRAT: Node 7 PXM 5 [mem 0x140000000000-0x17ffffffffff] hotplug
>>     SRAT: Node 2 PXM 6 [mem 0x180000000000-0x1bffffffffff] hotplug
>>     SRAT: Node 3 PXM 7 [mem 0x1c0000000000-0x1fffffffffff] hotplug
>>
>> We can increase the padding by CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING,
>> however, the available entropy is decreased if the padding is increased.
>> So the config change is not very good for the other most of systems.
>> And, the needed padding size depends on the system environment, for
>> example physical memory layout, so the kernel option is better than
>> changing the config.
>>
>> Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
>> ---
>>  arch/x86/mm/kaslr.c | 20 +++++++++++++++++++-
>>  1 file changed, 19 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
>> index 61db77b..8c7b4f6 100644
>> --- a/arch/x86/mm/kaslr.c
>> +++ b/arch/x86/mm/kaslr.c
>> @@ -33,6 +33,9 @@
>>  
>>  #define TB_SHIFT 40
> 
> I think this fix makes sense. Since we usually compiled in hotplug code
> by default, while may not really hot plug a memory board on most of
> systems. However on those systems which really need do hot plug, and
> might plug memory board onto physical position above 10TB, this will
> cause issues.
> 
> One tiny concern is that we have below definition for 5-level, means we
> can only have 4PB of system RAM for now. Not sure if one day it will be
> enlarged to 32PB as Documentation/x86/x86_64/mm.txt tell.
> 
> # define MAX_PHYSMEM_BITS       (pgtable_l5_enabled() ? 52 : 46)

Thank you for pointing it out.
I will change the max padding as follows and post v2 patch.

static int __init rand_mem_physical_padding_setup(char *str)
{
       int max_padding = (1 <<(MAX_PHYSMEM_BITS - TB_SHIFT)) - 1;

> Otherwise this patchset looks good to me.

Thank you for your review!

- Masa

> 
> Thanks
> Baoquan
> 
>>  
>> +#define MAX_PADDING_L4 63
>> +#define MAX_PADDING_L5 32767
>> +
>>  /*
>>   * The end address could depend on more configuration options to make the
>>   * highest amount of space for randomization available, but that's too hard
>> @@ -40,6 +43,7 @@
>>   */
>>  static const unsigned long vaddr_end = CPU_ENTRY_AREA_BASE;
>>  
>> +static int __initdata rand_mem_physical_padding = CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING;
>>  /*
>>   * Memory regions randomized by KASLR (except modules that use a separate logic
>>   * earlier during boot). The list is ordered based on virtual addresses. This
>> @@ -69,6 +73,20 @@ static inline bool kaslr_memory_enabled(void)
>>  	return kaslr_enabled() && !IS_ENABLED(CONFIG_KASAN);
>>  }
>>  
>> +static int __init rand_mem_physical_padding_setup(char *str)
>> +{
>> +	int max_padding = pgtable_l5_enabled() ? MAX_PADDING_L5 : MAX_PADDING_L4;
>> +
>> +	get_option(&str, &rand_mem_physical_padding);
>> +	if (rand_mem_physical_padding < 0)
>> +		rand_mem_physical_padding = 0;
>> +	else if (rand_mem_physical_padding > max_padding)
>> +		rand_mem_physical_padding = max_padding;
>> +
>> +	return 0;
>> +}
>> +early_param("rand_mem_physical_padding", rand_mem_physical_padding_setup);
>> +
>>  /* Initialize base and padding for each memory region randomized with KASLR */
>>  void __init kernel_randomize_memory(void)
>>  {
>> @@ -102,7 +120,7 @@ void __init kernel_randomize_memory(void)
>>  	 */
>>  	BUG_ON(kaslr_regions[0].base != &page_offset_base);
>>  	memory_tb = DIV_ROUND_UP(max_pfn << PAGE_SHIFT, 1UL << TB_SHIFT) +
>> -		CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING;
>> +		rand_mem_physical_padding;
>>  
>>  	/* Adapt phyiscal memory region size based on available memory */
>>  	if (memory_tb < kaslr_regions[0].size_tb)
>> -- 
>> 2.18.0
>>