+ KASAN list

Le 06/10/2022 à 06:10, Michael Ellerman a écrit :

Nathan Lynch [off-list ref] writes:

quoted

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.

quoted

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:

...

quoted

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