Re: [PATCH v3 0/6] implement KASLR for powerpc/fsl_booke/64
From: Daniel Axtens <hidden>
Date: 2020-02-26 11:41:53
Also in:
lkml
Jason Yan [off-list ref] writes:
Hi Daniel, 在 2020/2/26 15:16, Daniel Axtens 写道:quoted
Hi Jason,quoted
This is a try to implement KASLR for Freescale BookE64 which is based on my earlier implementation for Freescale BookE32: https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=131718 The implementation for Freescale BookE64 is similar as BookE32. One difference is that Freescale BookE64 set up a TLB mapping of 1G during booting. Another difference is that ppc64 needs the kernel to be 64K-aligned. So we can randomize the kernel in this 1G mapping and make it 64K-aligned. This can save some code to creat another TLB map at early boot. The disadvantage is that we only have about 1G/64K = 16384 slots to put the kernel in. KERNELBASE 64K |--> kernel <--| | | | +--+--+--+ +--+--+--+--+--+--+--+--+--+ +--+--+ | | | |....| | | | | | | | | |....| | | +--+--+--+ +--+--+--+--+--+--+--+--+--+ +--+--+ | | 1G |-----> offset <-----| kernstart_virt_addr I'm not sure if the slot numbers is enough or the design has any defects. If you have some better ideas, I would be happy to hear that. Thank you all.Are you making any attempt to hide kernel address leaks in this series?Yes.quoted
I've just been looking at the stackdump code just now, and it directly prints link registers and stack pointers, which is probably enough to determine the kernel base address: SPs: LRs: %pS pointer [ 0.424506] [c0000000de403970] [c000000001fc0458] dump_stack+0xfc/0x154 (unreliable) [ 0.424593] [c0000000de4039c0] [c000000000267eec] panic+0x258/0x5ac [ 0.424659] [c0000000de403a60] [c0000000024d7a00] mount_block_root+0x634/0x7c0 [ 0.424734] [c0000000de403be0] [c0000000024d8100] prepare_namespace+0x1ec/0x23c [ 0.424811] [c0000000de403c60] [c0000000024d7010] kernel_init_freeable+0x804/0x880 git grep \\\"REG\\\" arch/powerpc shows a few other uses like this, all in process.c or in xmon.Thanks for reminding this.quoted
Maybe replacing the REG format string in KASLR mode would be sufficient?Most archs have removed the address printing when dumping stack. Do we really have to print this? If we have to do this, maybe we can use "%pK" so that they will be hidden from unprivileged users.
I suspect that you will find it easier to convince people to accept a change to %pK than removal :) BTW, I have a T4240RDB so I might be able to test this series at some point - do I need an updated bootloader to pass in a random seed, or is the kernel able to get enough randomness by itself? (Sorry if this is explained elsewhere in the series, I have only skimmed it lightly!) Regards, Daniel
Thanks, Jasonquoted
Regards, Danielquoted
v2->v3: Fix build error when KASLR is disabled. v1->v2: Add __kaslr_offset for the secondary cpu boot up. Jason Yan (6): powerpc/fsl_booke/kaslr: refactor kaslr_legal_offset() and kaslr_early_init() powerpc/fsl_booke/64: introduce reloc_kernel_entry() helper powerpc/fsl_booke/64: implement KASLR for fsl_booke64 powerpc/fsl_booke/64: do not clear the BSS for the second pass powerpc/fsl_booke/64: clear the original kernel if randomized powerpc/fsl_booke/kaslr: rename kaslr-booke32.rst to kaslr-booke.rst and add 64bit part .../{kaslr-booke32.rst => kaslr-booke.rst} | 35 +++++++-- arch/powerpc/Kconfig | 2 +- arch/powerpc/kernel/exceptions-64e.S | 23 ++++++ arch/powerpc/kernel/head_64.S | 14 ++++ arch/powerpc/kernel/setup_64.c | 4 +- arch/powerpc/mm/mmu_decl.h | 19 ++--- arch/powerpc/mm/nohash/kaslr_booke.c | 71 +++++++++++++------ 7 files changed, 132 insertions(+), 36 deletions(-) rename Documentation/powerpc/{kaslr-booke32.rst => kaslr-booke.rst} (59%) -- 2.17.2.