+ KASAN list
Le 06/10/2022 à 06:10, Michael Ellerman a écrit :
> Nathan Lynch <nath...@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
