Hi all
I'm wondering, have you thought about implementing stack instrumentation for linux kernel? It seems there is not much difference from userspace implementation. 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. 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? 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.
