Messages in this thread | | | From | Baoquan He <> | Subject | [PATCH 0/4] fix the compatibility between kaslr and kexe | Date | Fri, 5 Sep 2014 22:08:13 +0800 |
| |
Earlier it's reported kexec can't load kernel on system with over 4G memory and kdump didn't work when set crashkenrel=xx, high when kaslr is compiled. They didn't work though nokaslr is set in cmdline as long as it's compiled in. This is caused by not checking if the kernel decompression output region is in a legal region.
In this patchset, fixs the bug peopel reported that kexec/kdump didn't work when kernel loading addr is above 1G. This is done in patch 2/4.
When kernel is put in a address which is not LOAD_PHYSICAL_ADDR, and kaslr is compiled in, it will do the relocation handling though user set nokaslr in cmdline. This is because no config checking in 2nd part of kaslr process, namely handle_relocations(). This is fixed in patch 1/4.
Patch 3/4 is handling the setup data avoiding. Since setup data can be put anywhere, if it's in below 1G region, need be avoided to be the kaslr random relocation slot. I just tested it using a kexec-tools user space trick, change kexec-tools to make the buffer allocating from down to top, and set E820MAX to 10, then extra e820 regions have to be added into setup data.
Patch 4/4 is to export KERNEL_IMAGE_SIZE to VMCOREINFO, makedumpfile need this to calculate MODULES_VADDR. Since introduing kaslr, the MODULES_VADDR is not fixed.
Baoquan He (3): kaslr: check user's config too when handle relocations kaslr: check if the random addr is available export the kernel image size KERNEL_IMAGE_SIZE
Dave Young (1): kaslr setup_data handling
arch/x86/boot/compressed/aslr.c | 31 +++++++++++++++++++++++++++++-- arch/x86/boot/compressed/misc.c | 17 +++++++++++++++++ kernel/kexec.c | 3 +++ 3 files changed, 49 insertions(+), 2 deletions(-)
-- 1.8.5.3
| |