arm64: mm: account for hotplug memory when randomizing the linear region

PATCH Applied Ard Biesheuvel 5 participants 13 messages Oct 14, 2020 – Nov 13, 2020 arm64

Share & tools

Ard Biesheuvel

author

2020-10-14 08:20 UTC #0 lore raw

PATCH 1/1 arm64: mm: account for hotplug memory when randomizing the linear region

As a hardening measure, we currently randomize the placement of physical memory inside the linear region when KASLR is in effect. Since the random offset at which to place the available physical memory inside the linear region is chosen early at boot, it is based on the memblock description of memory, which does not cover hotplug memory. The consequence of this is that the randomization offset may be chosen such that any hotplugged memory located above memblock_end_of_DRAM() that appears later is pushed off the end of the linear region, where it cannot be accessed.

So let's limit this randomization of the linear region to ensure that this can no longer happen, by using the CPU's addressable PA range instead. As it is guaranteed that no hotpluggable memory will appear that falls outside of that range, we can safely put this PA range sized window anywhere in the linear region.

Cc Anshuman Khandual <[email protected]>

Cc Catalin Marinas <[email protected]>

Cc Will Deacon <[email protected]>

Cc Steven Price <[email protected]>

Cc Robin Murphy <[email protected]>

Signed-off-by Ard Biesheuvel <[email protected]>

---
Related to discussion here:
https://lore.kernel.org/linux-arm-kernel/[email protected]/

 arch/arm64/mm/init.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

arch/arm64/mm/init.c +7 -4

index 0b393c275be0..af1b4ed2daa8 100644
@@ -350,13 +350,16 @@ void __init arm64_memblock_init(void)
 
 	if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
 		extern u16 memstart_offset_seed;
-		u64 range = linear_region_size -
-			    (memblock_end_of_DRAM() - memblock_start_of_DRAM());
+		u64 mmfr0 = read_cpuid(ID_AA64MMFR0_EL1);
+		int parange = cpuid_feature_extract_unsigned_field(
+					mmfr0, ID_AA64MMFR0_PARANGE_SHIFT);
+		s64 range = linear_region_size -
+			    BIT(id_aa64mmfr0_parange_to_phys_shift(parange));
 
 		/*
 		 * If the size of the linear region exceeds, by a sufficient
-		 * margin, the size of the region that the available physical
-		 * memory spans, randomize the linear region as well.
+		 * margin, the size of the region that the physical memory can
+		 * span, randomize the linear region as well.
 		 */
 		if (memstart_offset_seed > 0 && range >= ARM64_MEMSTART_ALIGN) {
 			range /= ARM64_MEMSTART_ALIGN;

Signature · 6 lines

2.17.1

_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Will Deacon

maintainer

2020-10-15 10:48 UTC #1 lore raw

Quoted 22 lines · Ard Biesheuvel

As a hardening measure, we currently randomize the placement of physical memory inside the linear region when KASLR is in effect. Since the random offset at which to place the available physical memory inside the linear region is chosen early at boot, it is based on the memblock description of memory, which does not cover hotplug memory. The consequence of this is that the randomization offset may be chosen such that any hotplugged memory located above memblock_end_of_DRAM() that appears later is pushed off the end of the linear region, where it cannot be accessed.
So let's limit this randomization of the linear region to ensure that this can no longer happen, by using the CPU's addressable PA range instead. As it is guaranteed that no hotpluggable memory will appear that falls outside of that range, we can safely put this PA range sized window anywhere in the linear region.
Cc Anshuman Khandual <[email protected]>
Cc Catalin Marinas <[email protected]>
Cc Will Deacon <[email protected]>
Cc Steven Price <[email protected]>
Cc Robin Murphy <[email protected]>
Signed-off-by Ard Biesheuvel <[email protected]>

Quoted 3 lines

---
Related to discussion here:
https://lore.kernel.org/linux-arm-kernel/[email protected]/

Anshuman, can you fold this one into your series, please?

Will

_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Anshuman Khandual

2020-10-16 10:29 UTC #2 lore raw

Quoted 27 lines · Will Deacon

Quoted 22 lines · Ard Biesheuvel
As a hardening measure, we currently randomize the placement of physical memory inside the linear region when KASLR is in effect. Since the random offset at which to place the available physical memory inside the linear region is chosen early at boot, it is based on the memblock description of memory, which does not cover hotplug memory. The consequence of this is that the randomization offset may be chosen such that any hotplugged memory located above memblock_end_of_DRAM() that appears later is pushed off the end of the linear region, where it cannot be accessed.
So let's limit this randomization of the linear region to ensure that this can no longer happen, by using the CPU's addressable PA range instead. As it is guaranteed that no hotpluggable memory will appear that falls outside of that range, we can safely put this PA range sized window anywhere in the linear region.
Cc Anshuman Khandual <[email protected]>
Cc Catalin Marinas <[email protected]>
Cc Will Deacon <[email protected]>
Cc Steven Price <[email protected]>
Cc Robin Murphy <[email protected]>
Signed-off-by Ard Biesheuvel <[email protected]>
Quoted 3 lines
---
Related to discussion here:
https://lore.kernel.org/linux-arm-kernel/[email protected]/

Quoted 1 line

Anshuman, can you fold this one into your series, please?

Sure, will do.

_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Ard Biesheuvel

author

2020-10-17 12:41 UTC #3 lore raw

In reply to Ard Biesheuvel

Quoted 45 lines · Ard Biesheuvel

As a hardening measure, we currently randomize the placement of physical memory inside the linear region when KASLR is in effect. Since the random offset at which to place the available physical memory inside the linear region is chosen early at boot, it is based on the memblock description of memory, which does not cover hotplug memory. The consequence of this is that the randomization offset may be chosen such that any hotplugged memory located above memblock_end_of_DRAM() that appears later is pushed off the end of the linear region, where it cannot be accessed.
So let's limit this randomization of the linear region to ensure that this can no longer happen, by using the CPU's addressable PA range instead. As it is guaranteed that no hotpluggable memory will appear that falls outside of that range, we can safely put this PA range sized window anywhere in the linear region.
Cc Anshuman Khandual <[email protected]>
Cc Catalin Marinas <[email protected]>
Cc Will Deacon <[email protected]>
Cc Steven Price <[email protected]>
Cc Robin Murphy <[email protected]>
Signed-off-by Ard Biesheuvel <[email protected]>
---
Related to discussion here:
https://lore.kernel.org/linux-arm-kernel/[email protected]/
 arch/arm64/mm/init.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)
arch/arm64/mm/init.c +5 -2
index 0b393c275be0..af1b4ed2daa8 100644
@@ -350,13 +350,16 @@ void __init arm64_memblock_init(void)
 
        if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
                extern u16 memstart_offset_seed;
-               u64 range = linear_region_size -
-                           (memblock_end_of_DRAM() - memblock_start_of_DRAM());
+               u64 mmfr0 = read_cpuid(ID_AA64MMFR0_EL1);
+               int parange = cpuid_feature_extract_unsigned_field(
+                                       mmfr0, ID_AA64MMFR0_PARANGE_SHIFT);
+               s64 range = linear_region_size -
+                           BIT(id_aa64mmfr0_parange_to_phys_shift(parange));

arch/arm64/mm/init.c void __init arm64_memblock_init(void) · line 365

Quoted 10 lines

arch/arm64/mm/init.c +2 -2

 
                /*
                 * If the size of the linear region exceeds, by a sufficient
-                * margin, the size of the region that the available physical
-                * memory spans, randomize the linear region as well.
+                * margin, the size of the region that the physical memory can
+                * span, randomize the linear region as well.
                 */
                if (memstart_offset_seed > 0 && range >= ARM64_MEMSTART_ALIGN) {
                        range /= ARM64_MEMSTART_ALIGN;

The comparison here should be modified to read

range >= (s64)ARM64_MEMSTART_ALIGN

or the LHS will get promoted to u64, which will yield the wrong result.

_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Catalin Marinas

maintainer Applied

2020-11-10 19:14 UTC #4 lore raw

In reply to Ard Biesheuvel

Quoted 11 lines · Ard Biesheuvel

As a hardening measure, we currently randomize the placement of physical memory inside the linear region when KASLR is in effect. Since the random offset at which to place the available physical memory inside the linear region is chosen early at boot, it is based on the memblock description of memory, which does not cover hotplug memory. The consequence of this is that the randomization offset may be chosen such that any hotplugged memory located above memblock_end_of_DRAM() that appears later is pushed off the end of the linear region, where it cannot be accessed.
[...]

Applied to arm64 (for-next/mem-hotplug), thanks!

[1/1] arm64: mm: account for hotplug memory when randomizing the linear region

      https://git.kernel.org/arm64/c/97d6786e0669

Signature · 1 line

Catalin

Anshuman Khandual

2020-11-11 03:49 UTC #5 lore raw

Quoted 11 lines · Catalin Marinas

Quoted 10 lines · Ard Biesheuvel
As a hardening measure, we currently randomize the placement of physical memory inside the linear region when KASLR is in effect. Since the random offset at which to place the available physical memory inside the linear region is chosen early at boot, it is based on the memblock description of memory, which does not cover hotplug memory. The consequence of this is that the randomization offset may be chosen such that any hotplugged memory located above memblock_end_of_DRAM() that appears later is pushed off the end of the linear region, where it cannot be accessed.

Quoted 7 lines

Quoted 1 line
[...]
Applied to arm64 (for-next/mem-hotplug), thanks!
[1/1] arm64: mm: account for hotplug memory when randomizing the linear region
      https://git.kernel.org/arm64/c/97d6786e0669

Hello Catalin,

Got delayed and never made here in time, sorry about that. Nonetheless, I have got something working with respect to the generic mechanism that David Hildenbrand had asked for earlier.

https://patchwork.kernel.org/project/linux-arm-kernel/patch/[email protected]/

I am wondering if we could instead consider merging the above patch with a small change that Ard had pointed out earlier [1], I will send out a revision if required.

I am asking this because the patch in question is a memory hotplug fix and should be back ported to other stable releases. Implementing that via the new proposed generic framework might make it difficult for a possible arm64 specific backport. We could then add the new generic framework and move this fix to an arch callback. Let me know if this would be an feasible option. Thank you.

- Anshuman

[1] From Ard Biesheuvel

"So I think your original approach makes more sense here, although I think you want '(start + size - 1) <= __pa(PAGE_END - 1)' in the comparison above (and please drop the redundant parens)"

+ David Hildenbrand <[email protected]>

David Hildenbrand

2020-11-11 09:11 UTC #6 lore raw

Quoted 34 lines · Anshuman Khandual

Quoted 11 lines · Catalin Marinas
Quoted 10 lines · Ard Biesheuvel
As a hardening measure, we currently randomize the placement of physical memory inside the linear region when KASLR is in effect. Since the random offset at which to place the available physical memory inside the linear region is chosen early at boot, it is based on the memblock description of memory, which does not cover hotplug memory. The consequence of this is that the randomization offset may be chosen such that any hotplugged memory located above memblock_end_of_DRAM() that appears later is pushed off the end of the linear region, where it cannot be accessed.
Quoted 7 lines
Quoted 1 line
[...]
Applied to arm64 (for-next/mem-hotplug), thanks!
[1/1] arm64: mm: account for hotplug memory when randomizing the linear region
       https://git.kernel.org/arm64/c/97d6786e0669
Hello Catalin,
Got delayed and never made here in time, sorry about that. Nonetheless, I have got something working with respect to the generic mechanism that David Hildenbrand had asked for earlier.
https://patchwork.kernel.org/project/linux-arm-kernel/patch/[email protected]/
I am wondering if we could instead consider merging the above patch with a small change that Ard had pointed out earlier [1], I will send out a revision if required.

Quoted 6 lines

I am asking this because the patch in question is a memory hotplug fix and should be back ported to other stable releases. Implementing that via the new proposed generic framework might make it difficult for a possible arm64 specific backport. We could then add the new generic framework and move this fix to an arch callback. Let me know if this would be an feasible option. Thank you.

Sure, if it's a fix that is intended to be backported as well, then let's move forward with the simple fix and do a proper cleanup on top later. Thanks!

Signature · 3 lines

Thanks,

David / dhildenb

Catalin Marinas

maintainer

2020-11-12 09:26 UTC #7 lore raw

In reply to Anshuman Khandual

Hi Anshuman,

Quoted 16 lines · Anshuman Khandual

Quoted 15 lines · Catalin Marinas
Quoted 11 lines · Ard Biesheuvel
As a hardening measure, we currently randomize the placement of physical memory inside the linear region when KASLR is in effect. Since the random offset at which to place the available physical memory inside the linear region is chosen early at boot, it is based on the memblock description of memory, which does not cover hotplug memory. The consequence of this is that the randomization offset may be chosen such that any hotplugged memory located above memblock_end_of_DRAM() that appears later is pushed off the end of the linear region, where it cannot be accessed.
[...]
Applied to arm64 (for-next/mem-hotplug), thanks!

Quoted 8 lines

Quoted 2 lines
[1/1] arm64: mm: account for hotplug memory when randomizing the linear region
      https://git.kernel.org/arm64/c/97d6786e0669
Got delayed and never made here in time, sorry about that. Nonetheless, I have got something working with respect to the generic mechanism that David Hildenbrand had asked for earlier.
https://patchwork.kernel.org/project/linux-arm-kernel/patch/[email protected]/

There was a lot of discussion around this patch but I haven't seen any new version posted.

Quoted 3 lines

I am wondering if we could instead consider merging the above patch with a small change that Ard had pointed out earlier [1], I will send out a revision if required.

If your patch fixes the randomisation issue that Ard addressed, I'm happy to replace that with your patch. But please post a new version and get some acks in place from the parties involved in the discussion.

Thanks.

Signature · 1 line

Catalin

Anshuman Khandual

2020-11-13 03:17 UTC #8 lore raw

Quoted 22 lines · Catalin Marinas

Hi Anshuman,
Quoted 19 lines · Anshuman Khandual
Quoted 17 lines · Catalin Marinas
Quoted 11 lines · Ard Biesheuvel
As a hardening measure, we currently randomize the placement of physical memory inside the linear region when KASLR is in effect. Since the random offset at which to place the available physical memory inside the linear region is chosen early at boot, it is based on the memblock description of memory, which does not cover hotplug memory. The consequence of this is that the randomization offset may be chosen such that any hotplugged memory located above memblock_end_of_DRAM() that appears later is pushed off the end of the linear region, where it cannot be accessed.
[...]
Applied to arm64 (for-next/mem-hotplug), thanks!
[1/1] arm64: mm: account for hotplug memory when randomizing the linear region
      https://git.kernel.org/arm64/c/97d6786e0669

Quoted 8 lines

Quoted 5 lines
Got delayed and never made here in time, sorry about that. Nonetheless, I have got something working with respect to the generic mechanism that David Hildenbrand had asked for earlier.
https://patchwork.kernel.org/project/linux-arm-kernel/patch/[email protected]/
There was a lot of discussion around this patch but I haven't seen any new version posted.

Just posted before some time.

https://lore.kernel.org/linux-arm-kernel/[email protected]/

Quoted 8 lines

Quoted 4 lines
I am wondering if we could instead consider merging the above patch with a small change that Ard had pointed out earlier [1], I will send out a revision if required.
If your patch fixes the randomisation issue that Ard addressed, I'm happy to replace that with your patch. But please post a new version and get some acks in place from the parties involved in the discussion.

The above patch is not a replacement for Ard's randomization patch here but rather complements it. Hence both these patches should be considered, which will make memory hotplug better on the platform.

_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Ard Biesheuvel

author

2020-11-13 06:15 UTC #9 lore raw

Quoted 30 lines · Anshuman Khandual

Quoted 26 lines · Catalin Marinas
Hi Anshuman,
Quoted 23 lines · Anshuman Khandual
Quoted 11 lines · Catalin Marinas
Quoted 10 lines · Ard Biesheuvel
As a hardening measure, we currently randomize the placement of physical memory inside the linear region when KASLR is in effect. Since the random offset at which to place the available physical memory inside the linear region is chosen early at boot, it is based on the memblock description of memory, which does not cover hotplug memory. The consequence of this is that the randomization offset may be chosen such that any hotplugged memory located above memblock_end_of_DRAM() that appears later is pushed off the end of the linear region, where it cannot be accessed.
Quoted 6 lines
Quoted 1 line
[...]
Applied to arm64 (for-next/mem-hotplug), thanks!
[1/1] arm64: mm: account for hotplug memory when randomizing the linear region
      https://git.kernel.org/arm64/c/97d6786e0669
Got delayed and never made here in time, sorry about that. Nonetheless, I have got something working with respect to the generic mechanism that David Hildenbrand had asked for earlier.

Quoted 9 lines

Quoted 4 lines
Quoted 1 line
https://patchwork.kernel.org/project/linux-arm-kernel/patch/[email protected]/
There was a lot of discussion around this patch but I haven't seen any new version posted.
Just posted before some time.
https://lore.kernel.org/linux-arm-kernel/[email protected]/

You failed to cc me on that patch.

The logic looks correct but please fix up the comment block:
- PAGE_END is no longer defined in terms of vabits_actual
- bits [51..48] are not ignored by the MMU

Actually, I think the entire second paragraph of that comment block can be dropped.

Please also fix up the coding style:
- put && at the end of the first line
- drop the redundant parens
- fix the indentation

Quoted 12 lines

Quoted 8 lines
Quoted 4 lines
I am wondering if we could instead consider merging the above patch with a small change that Ard had pointed out earlier [1], I will send out a revision if required.
If your patch fixes the randomisation issue that Ard addressed, I'm happy to replace that with your patch. But please post a new version and get some acks in place from the parties involved in the discussion.
The above patch is not a replacement for Ard's randomization patch here but rather complements it. Hence both these patches should be considered, which will make memory hotplug better on the platform.

Anshuman Khandual

2020-11-13 07:03 UTC #10 lore raw

Quoted 37 lines · Ard Biesheuvel

Quoted 35 lines · Anshuman Khandual
Quoted 30 lines · Catalin Marinas
Hi Anshuman,
Quoted 16 lines · Anshuman Khandual
Quoted 15 lines · Catalin Marinas
Quoted 11 lines · Ard Biesheuvel
As a hardening measure, we currently randomize the placement of physical memory inside the linear region when KASLR is in effect. Since the random offset at which to place the available physical memory inside the linear region is chosen early at boot, it is based on the memblock description of memory, which does not cover hotplug memory. The consequence of this is that the randomization offset may be chosen such that any hotplugged memory located above memblock_end_of_DRAM() that appears later is pushed off the end of the linear region, where it cannot be accessed.
[...]
Applied to arm64 (for-next/mem-hotplug), thanks!
Quoted 8 lines
Quoted 2 lines
[1/1] arm64: mm: account for hotplug memory when randomizing the linear region
      https://git.kernel.org/arm64/c/97d6786e0669
Got delayed and never made here in time, sorry about that. Nonetheless, I have got something working with respect to the generic mechanism that David Hildenbrand had asked for earlier.
https://patchwork.kernel.org/project/linux-arm-kernel/patch/[email protected]/
There was a lot of discussion around this patch but I haven't seen any new version posted.

Quoted 6 lines

Quoted 4 lines
Just posted before some time.
https://lore.kernel.org/linux-arm-kernel/[email protected]/
You failed to cc me on that patch.

I could see '[email protected]' marked as a copy on the patch. You did not receive the email ? The CC list is in the commit message itself. Even the lore.kernel.org based URL does list you email as well. Not sure what might have happened.

Cc Catalin Marinas <[email protected]>

Cc Will Deacon <[email protected]>

Cc Mark Rutland <[email protected]>

Cc Ard Biesheuvel <[email protected]>

Cc Steven Price <[email protected]>

Cc Robin Murphy <[email protected]>

Cc David Hildenbrand <[email protected]>

Cc Andrew Morton <[email protected]>

Cc [email protected]

Quoted 7 lines

The logic looks correct but please fix up the comment block:
- PAGE_END is no longer defined in terms of vabits_actual
- bits [51..48] are not ignored by the MMU
Actually, I think the entire second paragraph of that comment block can be dropped.

And from the commit message as well, had reused it in both places.

Quoted 5 lines

Please also fix up the coding style:
- put && at the end of the first line
- drop the redundant parens
- fix the indentation

Does this look okay ?

static bool inside_linear_region(u64 start, u64 size)
{
/*
* Linear mapping region is the range [PAGE_OFFSET..(PAGE_END - 1)]
* accommodating both its ends but excluding PAGE_END. Max physical
* range which can be mapped inside this linear mapping range, must
* also be derived from its end points.
*/
return start >= __pa(_PAGE_OFFSET(vabits_actual)) &&
(start + size - 1) <= __pa(PAGE_END - 1);
}

Ard Biesheuvel

author

2020-11-13 07:06 UTC #11 lore raw

Quoted 53 lines · Anshuman Khandual

Quoted 37 lines · Ard Biesheuvel
Quoted 35 lines · Anshuman Khandual
Quoted 30 lines · Catalin Marinas
Hi Anshuman,
Quoted 16 lines · Anshuman Khandual
Quoted 15 lines · Catalin Marinas
Quoted 11 lines · Ard Biesheuvel
As a hardening measure, we currently randomize the placement of physical memory inside the linear region when KASLR is in effect. Since the random offset at which to place the available physical memory inside the linear region is chosen early at boot, it is based on the memblock description of memory, which does not cover hotplug memory. The consequence of this is that the randomization offset may be chosen such that any hotplugged memory located above memblock_end_of_DRAM() that appears later is pushed off the end of the linear region, where it cannot be accessed.
[...]
Applied to arm64 (for-next/mem-hotplug), thanks!
Quoted 8 lines
Quoted 2 lines
[1/1] arm64: mm: account for hotplug memory when randomizing the linear region
      https://git.kernel.org/arm64/c/97d6786e0669
Got delayed and never made here in time, sorry about that. Nonetheless, I have got something working with respect to the generic mechanism that David Hildenbrand had asked for earlier.
https://patchwork.kernel.org/project/linux-arm-kernel/patch/[email protected]/
There was a lot of discussion around this patch but I haven't seen any new version posted.
Quoted 6 lines
Quoted 4 lines
Just posted before some time.
https://lore.kernel.org/linux-arm-kernel/[email protected]/
You failed to cc me on that patch.
I could see '[email protected]' marked as a copy on the patch. You did not receive the email ? The CC list is in the commit message itself. Even the lore.kernel.org based URL does list you email as well. Not sure what might have happened.

Quoted 11 lines

Cc Catalin Marinas <[email protected]>
Cc Will Deacon <[email protected]>
Cc Mark Rutland <[email protected]>
Cc Ard Biesheuvel <[email protected]>
Cc Steven Price <[email protected]>
Cc Robin Murphy <[email protected]>
Cc David Hildenbrand <[email protected]>
Cc Andrew Morton <[email protected]>
Cc [email protected]
Cc [email protected]

Right. Not sure what happened there, I may have deleted it by accident. Apologies.

Quoted 18 lines

Quoted 7 lines
The logic looks correct but please fix up the comment block:
- PAGE_END is no longer defined in terms of vabits_actual
- bits [51..48] are not ignored by the MMU
Actually, I think the entire second paragraph of that comment block can be dropped.
And from the commit message as well, had reused it in both places.
Quoted 5 lines
Please also fix up the coding style:
- put && at the end of the first line
- drop the redundant parens
- fix the indentation
Does this look okay ?

Quoted 11 lines

static bool inside_linear_region(u64 start, u64 size)
{
/*
* Linear mapping region is the range [PAGE_OFFSET..(PAGE_END - 1)]
* accommodating both its ends but excluding PAGE_END. Max physical
* range which can be mapped inside this linear mapping range, must
* also be derived from its end points.
*/
return start >= __pa(_PAGE_OFFSET(vabits_actual)) &&
(start + size - 1) <= __pa(PAGE_END - 1);
}

Not sure whether the whitespace has been mangled by the email client, but the first ( on the second line should align vertically with the 's' of 'start' on the first line

Anshuman Khandual

2020-11-13 07:40 UTC #12 lore raw

Quoted 100 lines · Ard Biesheuvel

Quoted 53 lines · Anshuman Khandual
Quoted 37 lines · Ard Biesheuvel
Quoted 35 lines · Anshuman Khandual
Quoted 30 lines · Catalin Marinas
Hi Anshuman,
Quoted 16 lines · Anshuman Khandual
Quoted 15 lines · Catalin Marinas
Quoted 11 lines · Ard Biesheuvel
As a hardening measure, we currently randomize the placement of physical memory inside the linear region when KASLR is in effect. Since the random offset at which to place the available physical memory inside the linear region is chosen early at boot, it is based on the memblock description of memory, which does not cover hotplug memory. The consequence of this is that the randomization offset may be chosen such that any hotplugged memory located above memblock_end_of_DRAM() that appears later is pushed off the end of the linear region, where it cannot be accessed.
[...]
Applied to arm64 (for-next/mem-hotplug), thanks!
Quoted 8 lines
Quoted 2 lines
[1/1] arm64: mm: account for hotplug memory when randomizing the linear region
      https://git.kernel.org/arm64/c/97d6786e0669
Got delayed and never made here in time, sorry about that. Nonetheless, I have got something working with respect to the generic mechanism that David Hildenbrand had asked for earlier.
https://patchwork.kernel.org/project/linux-arm-kernel/patch/[email protected]/
There was a lot of discussion around this patch but I haven't seen any new version posted.
Quoted 6 lines
Quoted 4 lines
Just posted before some time.
https://lore.kernel.org/linux-arm-kernel/[email protected]/
You failed to cc me on that patch.
I could see '[email protected]' marked as a copy on the patch. You did not receive the email ? The CC list is in the commit message itself. Even the lore.kernel.org based URL does list you email as well. Not sure what might have happened.
Quoted 11 lines
Cc Catalin Marinas <[email protected]>
Cc Will Deacon <[email protected]>
Cc Mark Rutland <[email protected]>
Cc Ard Biesheuvel <[email protected]>
Cc Steven Price <[email protected]>
Cc Robin Murphy <[email protected]>
Cc David Hildenbrand <[email protected]>
Cc Andrew Morton <[email protected]>
Cc [email protected]
Cc [email protected]
Right. Not sure what happened there, I may have deleted it by accident. Apologies.
Quoted 18 lines
Quoted 7 lines
The logic looks correct but please fix up the comment block:
- PAGE_END is no longer defined in terms of vabits_actual
- bits [51..48] are not ignored by the MMU
Actually, I think the entire second paragraph of that comment block can be dropped.
And from the commit message as well, had reused it in both places.
Quoted 5 lines
Please also fix up the coding style:
- put && at the end of the first line
- drop the redundant parens
- fix the indentation
Does this look okay ?
Quoted 11 lines
static bool inside_linear_region(u64 start, u64 size)
{
/*
* Linear mapping region is the range [PAGE_OFFSET..(PAGE_END - 1)]
* accommodating both its ends but excluding PAGE_END. Max physical
* range which can be mapped inside this linear mapping range, must
* also be derived from its end points.
*/
return start >= __pa(_PAGE_OFFSET(vabits_actual)) &&
(start + size - 1) <= __pa(PAGE_END - 1);
}

Quoted 3 lines

Not sure whether the whitespace has been mangled by the email client, but the first ( on the second line should align vertically with the 's' of 'start' on the first line

It was not aligned vertically here but fixed it. I hope you have received the latest version this time.

https://lore.kernel.org/linux-arm-kernel/[email protected]/