summaryrefslogtreecommitdiff
path: root/kexec/kexec-elf-boot.c
diff options
context:
space:
mode:
authorBhupesh Sharma <bhsharma@redhat.com>2018-04-26 14:27:32 +0530
committerSimon Horman <horms@verge.net.au>2018-06-19 17:32:27 +0200
commitc3f043241a866a7af9117396634dfcb20f0fd9cb (patch)
treedc5830112810761ed02680687049e43e8340c8cf /kexec/kexec-elf-boot.c
parent7acd257ae67b4ca94f8c23cb8bda0ee0709b9216 (diff)
arm64: Add support to supply 'kaslr-seed' to secondary kernel
This patch adds the support to supply 'kaslr-seed' to secondary kernel, when we do a 'kexec warm reboot to another kernel' (although the behaviour remains the same for the 'kdump' case as well) on arm64 platforms using the 'kexec_load' invocation method. Lets consider the case where the primary kernel working on the arm64 platform supports kaslr (i.e 'CONFIG_RANDOMIZE_BASE' was set to y and we have a compliant EFI firmware which supports EFI_RNG_PROTOCOL and hence can pass a non-zero (valid) seed to the primary kernel). Now the primary kernel reads the 'kaslr-seed' and wipes it to 0 and uses the seed value to randomize for e.g. the module base address offset. In the case of 'kexec_load' (or even kdump for brevity), we rely on the user-space kexec-tools to pass an appropriate dtb to the secondary kernel and since 'kaslr-seed' is wiped to 0 by the primary kernel, the secondary will essentially work with *nokaslr* as 'kaslr-seed' is set to 0 when it is passed to the secondary kernel. This can be true even in case the secondary kernel had 'CONFIG_RANDOMIZE_BASE' and 'CONFIG_RANDOMIZE_MODULE_REGION_FULL' set to y. This patch addresses this issue by first checking if the device tree provided by the firmware to the kernel supports the 'kaslr-seed' property and verifies that it is really wiped to 0. If this condition is met, it fixes up the 'kaslr-seed' property by using the getrandom() syscall to get a suitable random number. I verified this patch on my Qualcomm arm64 board and here are some test results: 1. Ensure that the primary kernel is boot'ed with 'kaslr-seed' dts property and it is really wiped to 0: [root@qualcomm-amberwing]# dtc -I dtb -O dts /sys/firmware/fdt | grep -A 10 -i chosen chosen { kaslr-seed = <0x0 0x0>; ... } 2. Now issue 'kexec_load' to load the secondary kernel (let's assume that we are using the same kernel as the secondary kernel): # kexec -l /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname -r`.img --reuse-cmdline -d 3. Issue 'kexec -e' to warm boot to the secondary: # kexec -e 4. Now after the secondary boots, confirm that the load address of the modules is randomized in every successive boot: [root@qualcomm-amberwing]# cat /proc/modules sunrpc 524288 1 - Live 0xffff0307db190000 vfat 262144 1 - Live 0xffff0307db110000 fat 262144 1 vfat, Live 0xffff0307db090000 crc32_ce 262144 0 - Live 0xffff0307d8c70000 ... Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
Diffstat (limited to 'kexec/kexec-elf-boot.c')
0 files changed, 0 insertions, 0 deletions