Re: [PATCH v2 0/2] x86/mm/KASLR: Do not adapt size of the direct mapping section for SGI UV system
Hi all, PING! Is there any further comment or suggetion about this patchset? Thanks Baoquan On 05/20/17 at 08:02pm, Baoquan He wrote: > This is v2 post. > > 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. > > v1->v2: > 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 > future. > > 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 > stage > 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(-) > > -- > 2.5.5 >
Re: [PATCH v2 0/2] x86/mm/KASLR: Do not adapt size of the direct mapping section for SGI UV system
Hi all, PING! Is there any further comment or suggetion about this patchset? Thanks Baoquan On 05/20/17 at 08:02pm, Baoquan He wrote: > This is v2 post. > > 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. > > v1->v2: > 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 > future. > > 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 > stage > 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(-) > > -- > 2.5.5 >
[PATCH v2 0/2] x86/mm/KASLR: Do not adapt size of the direct mapping section for SGI UV system
This is v2 post. 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. v1->v2: 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 future. 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 stage 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(-) -- 2.5.5
[PATCH v2 0/2] x86/mm/KASLR: Do not adapt size of the direct mapping section for SGI UV system
This is v2 post. 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. v1->v2: 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 future. 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 stage 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(-) -- 2.5.5
