| Message ID | 20200109070811.31169-1-dja@axtens.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | KASAN for powerpc64 radix | expand |
Le 09/01/2020 à 08:08, Daniel Axtens a écrit : > Building on the work of Christophe, Aneesh and Balbir, I've ported > KASAN to 64-bit Book3S kernels running on the Radix MMU. > > This provides full inline instrumentation on radix, but does require > that you be able to specify the amount of physically contiguous memory > on the system at compile time. More details in patch 4. This might be a stupid idea as I don't know ppc64 much. IIUC, PPC64 kernel can be relocated, there is no requirement to have it at address 0. Therefore, would it be possible to put the KASAN shadow mem at the begining of the physical memory, instead of putting it at the end ? That way, you wouldn't need to know the amount of memory at compile time because KASAN shadow mem would always be at address 0. Christophe
Christophe Leroy <christophe.leroy@c-s.fr> writes: > Le 09/01/2020 à 08:08, Daniel Axtens a écrit : >> Building on the work of Christophe, Aneesh and Balbir, I've ported >> KASAN to 64-bit Book3S kernels running on the Radix MMU. >> >> This provides full inline instrumentation on radix, but does require >> that you be able to specify the amount of physically contiguous memory >> on the system at compile time. More details in patch 4. > > This might be a stupid idea as I don't know ppc64 much. IIUC, PPC64 > kernel can be relocated, there is no requirement to have it at address > 0. Therefore, would it be possible to put the KASAN shadow mem at the > begining of the physical memory, instead of putting it at the end ? > That way, you wouldn't need to know the amount of memory at compile time > because KASAN shadow mem would always be at address 0. Good question! I've had a look. Bearing in mind that I'm not an expert in ppc64 early load, I think it would be possible, but a large chunk of work. One challenge is that - as I understand it - the early relocation code in head_64.S currently allows the kernel to either: - run at the address it's loaded at by kexec/the bootloader, or - relocate the kernel to 0 As far as I can tell book3s 64bit doesn't have code to arbitrarily relocate the kernel. It's possible I'm wrong about this, in which case I'm happy to reasses! If I'm right, I think we'd want to implement KASLR for book3s first, along the lines of how book3e does it. That would allow the kernel to be put at an arbitrary location at runtime. We could then leverage that. Another challenge is that some of the interrupt vectors are not easy to relocate, so we'd have to work around that. That's probably not too big an issue and we'd pick that up in KASLR implementation. So I think this is something we could come back to once we have KASLR. Regards, Daniel > > Christophe
Building on the work of Christophe, Aneesh and Balbir, I've ported KASAN to 64-bit Book3S kernels running on the Radix MMU. This provides full inline instrumentation on radix, but does require that you be able to specify the amount of physically contiguous memory on the system at compile time. More details in patch 4. v5: ptdump support. More cleanups, tweaks and fixes, thanks Christophe. Details in patch 4. I have seen another stack walk splat, but I don't think it's related to the patch set, I think there's a bug somewhere else, probably in stack frame manipulation in the kernel or (more unlikely) in the compiler. v4: More cleanups, split renaming out, clarify bits and bobs. Drop the stack walk disablement, that isn't needed. No other functional change. v3: Reduce the overly ambitious scope of the MAX_PTRS change. Document more things, including around why some of the restrictions apply. Clean up the code more, thanks Christophe. v2: The big change is the introduction of tree-wide(ish) MAX_PTRS_PER_{PTE,PMD,PUD} macros in preference to the previous approach, which was for the arch to override the page table array definitions with their own. (And I squashed the annoying intermittent crash!) Apart from that there's just a lot of cleanup. Christophe, I've addressed most of what you asked for and I will reply to your v1 emails to clarify what remains unchanged. Daniel Axtens (4): kasan: define and use MAX_PTRS_PER_* for early shadow tables kasan: Document support on 32-bit powerpc powerpc/mm/kasan: rename kasan_init_32.c to init_32.c powerpc: Book3S 64-bit "heavyweight" KASAN support Documentation/dev-tools/kasan.rst | 7 +- Documentation/powerpc/kasan.txt | 122 ++++++++++++++++++ arch/powerpc/Kconfig | 2 + arch/powerpc/Kconfig.debug | 23 +++- arch/powerpc/Makefile | 11 ++ arch/powerpc/include/asm/book3s/64/hash.h | 4 + arch/powerpc/include/asm/book3s/64/pgtable.h | 7 + arch/powerpc/include/asm/book3s/64/radix.h | 5 + arch/powerpc/include/asm/kasan.h | 15 ++- arch/powerpc/kernel/prom.c | 61 ++++++++- arch/powerpc/mm/kasan/Makefile | 3 +- .../mm/kasan/{kasan_init_32.c => init_32.c} | 0 arch/powerpc/mm/kasan/init_book3s_64.c | 71 ++++++++++ arch/powerpc/mm/ptdump/ptdump.c | 10 +- arch/powerpc/platforms/Kconfig.cputype | 1 + include/linux/kasan.h | 18 ++- mm/kasan/init.c | 6 +- 17 files changed, 350 insertions(+), 16 deletions(-) create mode 100644 Documentation/powerpc/kasan.txt rename arch/powerpc/mm/kasan/{kasan_init_32.c => init_32.c} (100%) create mode 100644 arch/powerpc/mm/kasan/init_book3s_64.c