On Thu, 25 Jul 2019 at 12:11, Mark Rutland <mark.rutland@xxxxxxx> wrote: > > 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! No fault, system just appears to freeze. Log: [ 18.408553] lkdtm: Calling function with 1024 frame size to depth 64 ... [ 18.409546] lkdtm: loop 64/64 ... [ 18.410030] lkdtm: loop 63/64 ... [ 18.410497] lkdtm: loop 62/64 ... [ 18.410972] lkdtm: loop 61/64 ... [ 18.411470] lkdtm: loop 60/64 ... [ 18.411946] lkdtm: loop 59/64 ... [ 18.412415] lkdtm: loop 58/64 ... [ 18.412890] lkdtm: loop 57/64 ... [ 18.413356] lkdtm: loop 56/64 ... [ 18.413830] lkdtm: loop 55/64 ... [ 18.414297] lkdtm: loop 54/64 ... [ 18.414801] lkdtm: loop 53/64 ... [ 18.415269] lkdtm: loop 52/64 ... [ 18.415751] lkdtm: loop 51/64 ... [ 18.416219] lkdtm: loop 50/64 ... [ 18.416698] lkdtm: loop 49/64 ... [ 18.417201] lkdtm: loop 48/64 ... [ 18.417712] lkdtm: loop 47/64 ... [ 18.418216] lkdtm: loop 46/64 ... [ 18.418728] lkdtm: loop 45/64 ... [ 18.419232] lkdtm: loop 44/64 ... [ 18.419747] lkdtm: loop 43/64 ... [ 18.420262] lkdtm: loop 42/64 ... < no further output, system appears unresponsive at this point > Thanks, -- Marco
