Le 10/12/2019 à 06:10, Daniel Axtens a écrit :
Christophe Leroy <christophe.le...@c-s.fr> writes:
Le 07/08/2019 à 01:38, Daniel Axtens a écrit :
KASAN support on powerpc64 is interesting:
- We want to be able to support inline instrumentation so as to be
able to catch global and stack issues.
- We run a lot of code at boot in real mode. This includes stuff like
printk(), so it's not feasible to just disable instrumentation
around it.
Have you definitely given up the idea of doing a standard implementation
of KASAN like other 64 bits arches have done ?
Isn't it possible to setup an early 1:1 mapping and go in virtual mode
earlier ? What is so different between book3s64 and book3e64 ?
On book3e64, we've been able to setup KASAN before printing anything
(except when using EARLY_DEBUG). Isn't it feasible on book3s64 too ?
So I got this pretty wrong when trying to explain it. The problem isn't
that we run the code in boot as I said, it's that a bunch of the KVM
code runs in real mode.
Ok.
Does it mean we would be able to implement it the standard way when
CONFIG_KVM is not selected ?
- disabled reporting when we're checking the stack for exception
frames. The behaviour isn't wrong, just incompatible with KASAN.
Does this applies to / impacts PPC32 at all ?
It should. I found that when doing stack walks, the code would touch
memory that KASAN hadn't unpoisioned. I'm a bit surprised you haven't
seen it arise, tbh.
How do you trigger that ?
I've tried to provoke some faults with LKDTM that provoke BUG dumps, but
it doesn't trip.
I also performed task state listing via sysrq, and I don't get anything
wrong either.
- Dropped old module stuff in favour of KASAN_VMALLOC.
You said in the cover that this is done to avoid having to split modules
out of VMALLOC area. Would it be an issue to perform that split ?
I can understand it is not easy on 32 bits because vmalloc space is
rather small, but on 64 bits don't we have enough virtual space to
confortably split modules out of vmalloc ? The 64 bits already splits
ioremap away from vmalloc whereas 32 bits have them merged too.
I could have done this. Maybe I should have done this. But now I have
done vmalloc space support.
So you force the use of KASAN_VMALLOC ? Doesn't it have a performance
impact ?
Christophe
