Re: [PATCH v2 RESEND 0/2] x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system
From: Baoquan He
Date: Wed Sep 13 2017 - 21:45:09 EST
Do anyone has any suggestion about this issue? This bug blocks SGI
system's boot, KASLR has to be disabled on SGI system if they want to
On 09/07/17 at 03:42pm, Baoquan He wrote:
> This is v2 post RESEND. Add Mike's Acked-by to patch 2/2 as he suggested
> in private mail. And update patches log slightly.
> This patchset is trying to fix a bug that SGI UV system casually hang
> during boot with KASLR enabled. The root cause is that mm KASLR adapts
> size of the direct mapping section only based on the system RAM size.
> Then later when map SGI UV MMIOH region into the direct mapping during
> rest_init() invocation, it might go beyond of the directing mapping
> section and step into VMALLOC or VMEMMAP area, then BUG_ON triggered.
> The fix is adding a helper function is_early_uv_system to check UV system
> earlier, then call the helper function in kernel_randomize_memory() to
> check if it's a SGI UV system, if yes, we keep the size of direct mapping
> section to be 64TB just as nokslr.
> With this fix, SGI UV system can have 64TB direct mapping size always,
> and the starting address of direct mapping/vmalloc/vmemmap and the padding
> between them can still be randomized to enhance the system security.
> 1. Mike suggested making is_early_uv_system() an inline function and be
> put in include/asm/uv/uv.h so that they can adjust them easier in the
> 2. Split the v1 code into uv part and mm KASLR part as Mike suggested.
> Baoquan He (2):
> x86/UV: Introduce a helper function to check UV system at earlier
> x86/mm/KASLR: Do not adapt the size of the direct mapping section for
> SGI UV system
> arch/x86/include/asm/uv/uv.h | 6 ++++++
> arch/x86/mm/kaslr.c | 3 ++-
> 2 files changed, 8 insertions(+), 1 deletion(-)