The v2 post was here: https://lkml.org/lkml/2018/9/9/56
During the v2 patch reviewing, Ingo suggested to: (1) improve the document in Documentation/x86/x86_64/mm.txt; (2) improve the documents about struct kaslr_memory_region; (3) open code unnecessary function get_padding(); (4) improve the memory region randomization to be at 2M granularity; *** Part (1) has been done with below commits currently: d52888aa2753 x86/mm: Move LDT remap out of KASLR region on 5-level paging 32b89760ddf4 x86/mm/doc: Enhance the x86-64 virtual memory layout descriptions 5b1290406579 x86/mm/doc: Clean up the x86-64 virtual memory layout descriptions *** Part (4) has been investigated, the code change can be found here: https://github.com/baoquan-he/linux/commits/mm-kaslr-2m-aligned >From test resut and Table 4-15 of Intel manual, changing the memory randomization to be at 2M granularity is not doable. Table 4-15. Format of an IA-32e Page-Directory-Pointer-Table Entry (PDPTE) that Maps a 1-GByte Page The current memory region KASLR is at 1 GB granularity, PUD aligned. When I tested above patches on kvm guest, system work well with 1 GB memory deployed. With 4 GB, KVM guest can't boot up. Finally I read Intel CPU manual and found it's because the 1 GB page mapping need be mapped at 1 GB aglined physical address. While the 2M granularity randomization will break that and causes boot failure. But we stil can improve the granularity in 5-level paging mode from 512 GB to 1 GB, this will be posted soon. *** This patchset includes the original three code bug fix patches in v2, and two new patches to improve code comments about kaslr_memory_region and open code unnecessary function get_padding(), meanwhile carry the known SGI UV bug fix. Note: SGI UV bug fix is not tested yet, the idea was approved by SGI UV expert Mike Travis, and the old post as below was tested and has been merged into our RHEL distros. This new change doesn't change the way to calculate the size of the direct mapping section, but only wrap the calculation code into a new function calc_direct_mapping_size() according to Ingo's suggestion. https://lkml.org/lkml/2017/5/18/102 Baoquan He (6): x86/mm/KASLR: Improve code comments about struct kaslr_memory_region x86/mm/KASLR: Open code unnecessary function get_padding mm: Add build time sanity check for struct page size x86/mm/KASLR: Fix the wrong calculation of memory region initial size x86/mm/KASLR: Calculate the actual size of vmemmap region x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system arch/x86/mm/kaslr.c | 131 +++++++++++++++++++++++++++++++++++--------- mm/page_alloc.c | 2 + 2 files changed, 107 insertions(+), 26 deletions(-) -- 2.17.2
