On Wed, Aug 24, 2016 at 3:03 AM, Ingo Molnar <mi...@kernel.org> wrote: > > * Andy Lutomirski <l...@kernel.org> wrote: > >> +config VMAP_STACK >> + default y >> + bool "Use a virtually-mapped stack" >> + depends on HAVE_ARCH_VMAP_STACK && !KASAN >> + ---help--- >> + Enable this if you want the use virtually-mapped kernel stacks >> + with guard pages. This causes kernel stack overflows to be >> + caught immediately rather than causing difficult-to-diagnose >> + corruption. >> + >> + This is presently incompatible with KASAN because KASAN expects >> + the stack to map directly to the KASAN shadow map using a formula >> + that is incorrect if the stack is in vmalloc space. > > Btw., is this KASAN limitation fundamental? > > As x86 is going to enable this feature by default, this probably limits KASAN > utility rather significantly.
No, it's not fundamental. KASAN has shadow for vmalloc range, but currently we map a single read-only zero page there (which means "this memory is good"). Stack instrumentation tries to write to that read-only page, which causes crash. Andrey proposed that we can map some real writable pages in the shadow range when we allocate a vmalloc-ed stack: https://groups.google.com/d/msg/kasan-dev/0YxqFs9r0V8/OKoGHQL8BAAJ
