Hi Christophe, >>>> - 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 ?
I suppose, but KVM is pretty important to me! >>>> - 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. I'll try to disable this and see if I can trigger it again. >>>> - 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 ? It has a perfomance impact when allocating and freeing virtual address space in the vmalloc region, yes. There should be no discernable impact when using vmalloc space. My team is actively working on vmap-stack support for ppc64, with the end goal of running syzkaller with vmap-stack and kasan. vmap-stack plus kasan requires kasan-vmalloc, so for my purposes doing things in this order makes sense. I'd be happy to have a later series introduce the split and then make KASAN_VMALLOC optional. I would need to understand the implications of splitting the address space from a KASLR point of view: I don't want to accidentally overly restrict the available randomness. Regards, Daniel > > Christophe
