On Thu, Jul 25, 2019 at 12:06:46PM +0200, Marco Elver wrote: > On Thu, 25 Jul 2019 at 09:51, Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote: > > > > On Thu, Jul 25, 2019 at 9:35 AM Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote: > > > > > > ,On Thu, Jul 25, 2019 at 7:55 AM Daniel Axtens <dja@xxxxxxxxxx> wrote: > > > > > > > > Hook into vmalloc and vmap, and dynamically allocate real shadow > > > > memory to back the mappings. > > > > > > > > Most mappings in vmalloc space are small, requiring less than a full > > > > page of shadow space. Allocating a full shadow page per mapping would > > > > therefore be wasteful. Furthermore, to ensure that different mappings > > > > use different shadow pages, mappings would have to be aligned to > > > > KASAN_SHADOW_SCALE_SIZE * PAGE_SIZE. > > > > > > > > Instead, share backing space across multiple mappings. Allocate > > > > a backing page the first time a mapping in vmalloc space uses a > > > > particular page of the shadow region. Keep this page around > > > > regardless of whether the mapping is later freed - in the mean time > > > > the page could have become shared by another vmalloc mapping. > > > > > > > > This can in theory lead to unbounded memory growth, but the vmalloc > > > > allocator is pretty good at reusing addresses, so the practical memory > > > > usage grows at first but then stays fairly stable. > > > > > > > > This requires architecture support to actually use: arches must stop > > > > mapping the read-only zero page over portion of the shadow region that > > > > covers the vmalloc space and instead leave it unmapped. > > > > > > > > This allows KASAN with VMAP_STACK, and will be needed for architectures > > > > that do not have a separate module space (e.g. powerpc64, which I am > > > > currently working on). > > > > > > > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=202009 > > > > Signed-off-by: Daniel Axtens <dja@xxxxxxxxxx> > > > > > > Hi Daniel, > > > > > > This is awesome! Thanks so much for taking over this! > > > I agree with memory/simplicity tradeoffs. Provided that virtual > > > addresses are reused, this should be fine (I hope). If we will ever > > > need to optimize memory consumption, I would even consider something > > > like aligning all vmalloc allocations to PAGE_SIZE*KASAN_SHADOW_SCALE > > > to make things simpler. > > > > > > Some comments below. > > > > Marco, please test this with your stack overflow test and with > > syzkaller (to estimate the amount of new OOBs :)). Also are there any > > concerns with performance/memory consumption for us? > > It appears that stack overflows are *not* detected when KASAN_VMALLOC > and VMAP_STACK are enabled. > > Tested with: > insmod drivers/misc/lkdtm/lkdtm.ko cpoint_name=DIRECT cpoint_type=EXHAUST_STACK Could you elaborate on what exactly happens? i.e. does the test fail entirely, or is it detected as a fault (but not reported as a stack overflow)? If you could post a log, that would be ideal! Thanks, Mark.
