Andrey Ryabinin <a.ryabinin@xxxxxxxxxxx> writes: > This feature let us to detect accesses out of bounds of > global variables. This will work as for globals in kernel > image, so for globals in modules. Currently this won't work > for symbols in user-specified sections (e.g. __init, __read_mostly, ...) > > The idea of this is simple. Compiler increases each global variable > by redzone size and add constructors invoking __asan_register_globals() > function. Information about global variable (address, size, > size with redzone ...) passed to __asan_register_globals() so we could > poison variable's redzone. > > This patch also forces module_alloc() to return 8*PAGE_SIZE aligned > address making shadow memory handling ( kasan_module_alloc()/kasan_module_free() ) > more simple. Such alignment guarantees that each shadow page backing > modules address space correspond to only one module_alloc() allocation. Hmm, I understand why you only fixed x86, but it's weird. I think MODULE_ALIGN belongs in linux/moduleloader.h, and every arch should be fixed up to use it (though you could leave that for later). Might as well fix the default implementation at least. > @@ -49,8 +49,15 @@ void kasan_krealloc(const void *object, size_t new_size); > void kasan_slab_alloc(struct kmem_cache *s, void *object); > void kasan_slab_free(struct kmem_cache *s, void *object); > > +#define MODULE_ALIGN (PAGE_SIZE << KASAN_SHADOW_SCALE_SHIFT) > + > +int kasan_module_alloc(void *addr, size_t size); > +void kasan_module_free(void *addr); > + > #else /* CONFIG_KASAN */ > > +#define MODULE_ALIGN 1 Hmm, that should be PAGE_SIZE (we assume that in several places). > @@ -1807,6 +1808,7 @@ static void unset_module_init_ro_nx(struct module *mod) { } > void __weak module_memfree(void *module_region) > { > vfree(module_region); > + kasan_module_free(module_region); > } This looks racy (memory reuse?). Perhaps try other order? Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html