Re: [PATCH v3 0/6] implement KASLR for powerpc/fsl_booke/64

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Daniel,

在 2020/2/26 15:16, Daniel Axtens 写道:
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?

Yes.

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.

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.

Thanks,
Jason

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

.





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux