On Mon, May 26, 2014 at 1:28 PM, Andrey Ryabinin <[email protected]> wrote: > Hi all > > I'm wondering, have you thought about implementing stack instrumentation for > linux kernel? Of course we did! This is in our near term plans.
> It seems there is not much difference from userspace implementation. Yep. > For stack redzones we need a lot larger stack than usual. Currently kernel > stack is limited to 8K-sizeof(struct thread_info). > However it should be trivial to enlarge default stack size for sanitizers > needs. > > > UAR implementation will be a bit more complicated, but it seems doable to > me. UAR in kasan is not in our near term plans... > > For allocating "fake stack" slab allocator would be probably enough, but > there are some problems: > 1. I believe we don't want to allocate slab redzones, and call kasan hooks > for such "fake stack" allocations. > 2. On early boot stages until some point kmalloc is not available yet. > > Solutions: > 1. We could create kmem_caches for "fake stacks" with special flag, which > will prevent us from redzone allocation and > calling kasan hooks. > 2. That's trivial - just check if slab_state == UP. > > > Poisoning/unpoisoning stacks could be implemented the same way like for > userspace, just without inlining. > > At first, poison shadow after "fake stack" allocation faze (if "fake stack" > allocation failed poison current stack). > And then that call unpoison_shadow(addr, size) for every stack variable. > For speed up it might be worth to implement unpoison_shadow_x functions > where x is most common variables sizes (1, 2, 4, 8, 16). > The big problem I expect here, is that it's probably gonna be slooooooow. > > > Another option, suggested by Yuri Gribov, would be to call function only > once and provide it with address of the beginning of descriptor of caller's > frame. > > That would certainly speed things up. > > Something like poison_stack(void *stack_start_addres, char > *stack_description, stack_size) > > > > So, what do you think about it? We first need to prepare a reasonable patch to GCC that implements kasan instrumentation (in progress). Then we are going to extend it to support stack overflow instrumentation. --kcc > > Best regards, > Andrey Ryabinin > > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
