Re: [PATCH] powerpc/kasan/book3s_64: warn when running with hash MMU

[Christophe Leroy <christophe.leroy@csgroup.eu>]

+ KASAN list

Le 06/10/2022 à 06:10, Michael Ellerman a écrit :
> Nathan Lynch <nathanl@linux.ibm.com> writes:
>> kasan is known to crash at boot on book3s_64 with non-radix MMU. As
>> noted in commit 41b7a347bf14 ("powerpc: Book3S 64-bit outline-only
>> KASAN support"):
>>
>>    A kernel with CONFIG_KASAN=y will crash during boot on a machine
>>    using HPT translation because not all the entry points to the
>>    generic KASAN code are protected with a call to kasan_arch_is_ready().
> 
> I guess I thought there was some plan to fix that.

I was thinking the same.

Do we have a list of the said entry points to the generic code that are 
lacking a call to kasan_arch_is_ready() ?

Typically, the BUG dump below shows that kasan_byte_accessible() is 
lacking the check. It should be straight forward to add 
kasan_arch_is_ready() check to kasan_byte_accessible(), shouldn't it ?

> 
> But maybe I'm misremembering. Looking now it's not entirely straight
> forward with the way the headers are structured. So I guess I'm wrong
> about that.
> 
>> Such crashes look like this:
>>
>>    BUG: Unable to handle kernel data access at 0xc00e00000308b100
>>    Faulting instruction address: 0xc0000000006d0fcc
>>    Oops: Kernel access of bad area, sig: 11 [#1]
>>    LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
>>    CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc5-02183-g3ab165dea2a2 #13
>>    [...regs...]
>>    NIP [c0000000006d0fcc] kasan_byte_accessible+0xc/0x20
>>    LR [c0000000006cd9cc] __kasan_check_byte+0x2c/0xa0
>>    Call Trace:
...
>>
>> Change init_book3s_64.c::kasan_init() to emit a warning backtrace and
>> taint the kernel when not running on radix. When the kernel likely
>> oopses later, the 'W' taint flag in the report should help minimize
>> developer time spent trying to understand what's gone wrong.
> 
> Should we just panic() directly?

But then you loose any sight that the problem is in 
kasan_byte_accessible() and have to be fixed there.

Christophe