Le 05/09/2025 à 20:08, Andrey Konovalov a écrit :
On Fri, Sep 5, 2025 at 7:12 PM Andrey Ryabinin <[email protected]> wrote:

But have you tried running kasan=off + CONFIG_KASAN_STACK=y +
CONFIG_VMAP_STACK=y (+ CONFIG_KASAN_VMALLOC=y)? I would expect this
should causes crashes, as the early shadow is mapped as read-only and
the inline stack instrumentation will try writing into it (or do the
writes into the early shadow somehow get ignored?..).


It's not read-only, otherwise we would crash very early before full shadow
setup and won't be able to boot at all. So writes still happen, and shadow
checked, but reports are disabled.

Hm, I thought it worked like that, but then what threw me off just now
was seeing that zero_pte_populate()->pte_wrprotect() (on arm64) resets
the PTE_WRITE bit and sets the PTE_RDONLY bit. So I thought the
kasan_early_shadow_page is marked as read-only and then the
instrumentation is disabled for all early code that might write into
the page before the proper shadow is set up. Or am I reading this
bit-setting code wrong?

But that zero_pte_populate() is called by kasan_init() when everything is ready.

kasan_init()->kasan_init_shadow()->kasan_populate_early_shadow()->zero_p4d_populate()->zero_pud_populate()->zero_pmd_populate()->zero_pte_populate()

Here we are talking about the shadow set at startup kasan_early_init(), aren't we ?

Christophe

Reply via email to