[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 26 Feb 2020 18:16:26 +1100
From: Daniel Axtens <dja@...ens.net>
To: Jason Yan <yanaijie@...wei.com>, mpe@...erman.id.au, linuxppc-dev@...ts.ozlabs.org, diana.craciun@....com, christophe.leroy@....fr, benh@...nel.crashing.org, paulus@...ba.org, npiggin@...il.com, keescook@...omium.org, kernel-hardening@...ts.openwall.com, oss@...error.net
Cc: linux-kernel@...r.kernel.org, zhaohongjiang@...wei.com, Jason Yan <yanaijie@...wei.com>
Subject: Re: [PATCH v3 0/6] implement KASLR for powerpc/fsl_booke/64
Hi Jason,
> 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?
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.
Maybe replacing the REG format string in KASLR mode would be sufficient?
Regards,
Daniel
> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
