Re: [PATCH v2 0/9] randomize kernel physical address and virtual address separately

[Baoquan He]

Hi Yinghai,

I have rearrange my patchset, they depend on your patchset in below
link. How should I post them? 

https://git.kernel.org/cgit/linux/kernel/git/yinghai/linux-yinghai.git/log/?h=for-x86-4.0-rc2-aslr


I post a patchset which includes your below patches?

x86, kaslr, 64bit: Set new or extra ident_mapping
x86, boot: Split kernel_ident_mapping_init to another file
x86, kaslr: Consolidate the mem_avoid filling
x86, kaslr: Get kaslr_enabled back correctly
x86, boot: Keep data from ZO boot stage to VO kernel stage.
x86, boot: Move ZO to end of buffer
x86, kaslr: Use init_size instead of run_size

Thanks
Baoquan

On 03/02/15 at 10:58pm, Baoquan He wrote:
> Currently kaslr only randomize physical address of kernel loading, then add the delta
> to virtual address of kernel text mapping. Because kernel virtual address can only be
> from __START_KERNEL_map to LOAD_PHYSICAL_ADDR+CONFIG_RANDOMIZE_BASE_MAX_OFFSET, namely
> [0xffffffff80000000, 0xffffffffc0000000], so physical address can only be randomized
> in region [LOAD_PHYSICAL_ADDR, CONFIG_RANDOMIZE_BASE_MAX_OFFSET], namely [16M, 1G].
> 
> So hpa and Vivek suggested the randomization should be done separately for both physical
> and virtual address. In this patchset the behavior is changed. Randomize both the physical
> address where kernel is decompressed and the virtual address where kernel text is mapped.
> And physical address can be randomized from where vmlinux was linked to load to maximum
> physical memory, possibly near 64T. While virtual address can get a random offset from load
> address to CONFIG_RANDOMIZE_BASE_MAX_OFFSET, then added to __START_KERNEL_map. And
> relocation handling only depends on virtual address randomization. Means if and only if
> virtual address is randomized to a different value, we add the delta to the offset of
> kernel relocs.
> 
> v1->v2:
>     Thanks to Yinghai's patch which make kernel be able to load above 4G in boot stage,
>     physical address can be randomized to anywhere, even near 64T.
> 
> 
>     Thank Andy Lutomirski for his adding idt patch, finally it's not used in this patchset
>     since I didn't make the #PF handler work well. I believe it does work, but I didn't
>     make it. Will check why later. Thanks anyway.
> 
> Baoquan He (8):
>   remove a unused function parameter
>   a bug that relocation can not be handled when kernel is loaded above
>     2G
>   introduce struct slot_area to manage randomization slot info
>   add mem_min_overlap to find the first avoid region within a memory
>     region
>   change process_e820_entry to store slot info into slot_area
>   get the random phy addr according to slot_area info
>   introduce fetch_random_virt_offset to randomize the kernel text
>     mapping address
>   change the relocations behavior for kaslr on x86_64
> 
> Yinghai Lu (1):
>   make kernel be able to load above 4G in boot stage
> 
>  arch/x86/boot/compressed/aslr.c     | 194 +++++++++++++++++++++++++++---------
>  arch/x86/boot/compressed/misc.c     |  46 ++++++---
>  arch/x86/boot/compressed/misc.h     |  22 ++--
>  arch/x86/boot/compressed/misc_pgt.c |  61 ++++++++++++
>  arch/x86/include/asm/page.h         |   5 +
>  arch/x86/mm/ident_map.c             |  74 ++++++++++++++
>  arch/x86/mm/init_64.c               |  74 +-------------
>  7 files changed, 333 insertions(+), 143 deletions(-)
>  create mode 100644 arch/x86/boot/compressed/misc_pgt.c
>  create mode 100644 arch/x86/mm/ident_map.c
> 
> -- 
> 1.9.3
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/