On 2020/6/17 下午3:19, Bhupesh Sharma wrote:
Hi Xunlin,
On Tue, Jun 16, 2020 at 9:03 AM Xulin Sun <xulin.sun@xxxxxxxxxxxxx> wrote:
The commit c3f043241a866a (arm64: Add support to supply 'kaslr-seed' to secondary kernel)
add kaslr-seed support. And consider the primary kernel reads the 'kaslr-seed'
and wipes it to 0. But in the situation, 'CONFIG_RANDOMIZE_BASE' was not set to
y in the primary kernel and ATF firmware has set the 'kaslr-seed' dtb property
with non-zero, Thus will return error.
So in the above case, continue loading the segments with no kaslr
supported situation.
Signed-off-by: Xulin Sun <xulin.sun@xxxxxxxxxxxxx>
---
kexec/arch/arm64/kexec-arm64.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
index 2992bce..540f4d7 100644
--- a/kexec/arch/arm64/kexec-arm64.c
+++ b/kexec/arch/arm64/kexec-arm64.c
@@ -506,8 +506,7 @@ static int setup_2nd_dtb(struct dtb *dtb, char *command_line, int on_crash)
if (kaslr_seed != 0) {
dbgprintf("%s: kaslr-seed is not wiped to 0.\n",
__func__);
- result = -EINVAL;
- goto on_error;
+ goto unable_kaslr;
}
/*
@@ -550,6 +549,7 @@ static int setup_2nd_dtb(struct dtb *dtb, char *command_line, int on_crash)
}
}
+unable_kaslr:
if (on_crash) {
/* add linux,elfcorehdr */
nodeoffset = fdt_path_offset(new_buf, "/chosen");
--
2.17.1
Sorry, but this seems like an ATF issue which you are trying to fix in
kexec-tools.
See 'Documentation/devicetree/bindings/chosen.txt' for the details of
the 'kaslr-seed' property:
kaslr-seed
-----------
This property is used when booting with CONFIG_RANDOMIZE_BASE as the
entropy used to randomize the kernel image base address location. Since
it is used directly, this value is intended only for KASLR, and should
not be used for other purposes (as it may leak information about KASLR
offsets). It is parsed as a u64 value, e.g.
/ {
chosen {
kaslr-seed = <0xfeedbeef 0xc0def00d>;
};
};
So, if CONFIG_RANDOMIZE_BASE (or kaslr) is disabled, this value should
not be available in the patched DTB read from the kernel, as otherwise
we have a possible security vulnerability as we are leaking out the
kernel text address which can be used by snooping applications to
inject malicious code in the kernel.
For example on my qualcomm arm64 platform, if CONFIG_RANDOMIZE_BASE is
set to n, user-space tools like 'dtc' are not able to find the
'kaslr-seed' property in the /chosen node (and same is the case with
kexec-tools):
# dtc -I dtb -O dts /sys/firmware/fdt | grep -A 10 -i chosen
chosen {
... no 'kaslr-seed' node
}
On my NXP LS1043A RDB platform(arm64), the ATF related bootloader and
firmware are default installed with NXP released latest version.
1. if CONFIG_RANDOMIZE_BASE is set to n on linux kernel.
#dtc -I dtb -O dts fdt | grep -A 10 -i chosen
chosen {
kaslr-seed = <0x48895203 0x935bea31>;
}
2. if CONFIG_RANDOMIZE_BASE is set to y on linux kernel
#dtc -I dtb -O dts fdt | grep -A 10 -i chosen
chosen {
kaslr-seed = <0x0 0x0>;
}
The u-boot code flow to set the "kaslr-seed" is:
https://source.codeaurora.org/external/qoriq/qoriq-components/u-boot
ft_board_setup
ft_cpu_setup
fdt_fixup_kaslr
fdt_setprop(fdt, nodeoffset, "kaslr-seed", rand,
So I suspect that u-boot will set the "kaslr-seed" property and does not
need to know if kernel has enabled the kernel config option
"CONFIG_RANDOMIZE_BASE" or not, and it has no way to get the value.
Do your qualcomm arm64 platform use the same u-boot code with "git.denx.de"?
Thanks
Xulin
Also confirm that the kernel symbol base address is not randomized on
successive reboots (in this case) via:
# cat /proc/kallsyms
Whereas, if I boot the kernel with CONFIG_RANDOMIZE_BASE (or kaslr)
enabled, I can see that the 'kaslr-seed' property is wiped to '0' (as
expected by the kernel') and can be seen in the output of:
# dtc -I dtb -O dts /sys/firmware/fdt | grep -A 10 -i chosen
chosen {
kaslr-seed = <0x0 0x0>
}
Thanks,
Bhupesh
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
