Messages in this thread | | | Subject | Re: KASAN & the vmalloc area | From | Andrey Ryabinin <> | Date | Wed, 9 Nov 2016 19:53:05 +0300 |
| |
On 11/08/2016 10:03 PM, Mark Rutland wrote: > Hi, > > I see a while back [1] there was a discussion of what to do about KASAN > and vmapped stacks, but it doesn't look like that was solved, judging by > the vmapped stacks pull [2] for v4.9. > > I wondered whether anyone had looked at that since? >
Sadly, but I didn't have much time for this yet, so it's in an initial state.
> I have an additional reason to want to dynamically allocate the vmalloc > area shadow: it turns out that KASAN currently interacts rather poorly > with the arm64 ptdump code. > > When KASAN is selected, we allocate shadow for the whole vmalloc area, > using common zero pte, pmd, pud tables. Walking over these in the ptdump > code takes a *very* long time (I've seen up to 15 minutes with > KASAN_OUTLINE enabled). For DEBUG_WX [3], this means boot hangs for that > long, too. >
I didn't look at any code, but we probably could can remember last visited pgd and skip next pgd if it's the same as previous. Alternatively - just skip kasan_zero_p*d in ptdump walker.
> If I don't allocate vmalloc shadow (and remove the apparently pointlesss > shadow of the shadow area), and only allocate shadow for the image, > fixmap, vmemmap and so on, that delay gets cut to a few seconds, which > is tolerable for a debug configuration... > > ... however, things blow up when the kernel touches vmalloc'd memory for > the first time, as we don't install shadow for that dynamically. > > Thanks, > Mark. > > [1] https://lkml.kernel.org/r/CALCETrWucrYp+yq8RHSDqf93xtg793duByirurzJbLRhrz=tcA@mail.gmail.com > [2] https://lkml.kernel.org/r/20161003092940.GA691@gmail.com > [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/464191.html >
| |