On 18/08/2021 23.40, Kees Cook wrote: > As already done in GrapheneOS, add the __alloc_size attribute for > regular kmalloc interfaces, to provide additional hinting for better > bounds checking, assisting CONFIG_FORTIFY_SOURCE and other compiler > optimizations. > > #ifdef CONFIG_NUMA > +__alloc_size(1) > void *__kmalloc_node(size_t size, gfp_t flags, int node) __assume_slab_alignment __malloc; Eh, can we keep all the attributes together instead of having some before, some after? I don't necessarily think this is a good idea, but just throwing it out there: __alloc_size almost always goes along with __malloc, so one could define __alloc_size in such a way that it implies __malloc, then just have a "raw" ____alloc_size version to use for krealloc() and similar. But I guess it's cleaner to keep it this way. While declared in string.h, kmemdup() is also eligible for alloc_size(2). Which brings me to an old wishlist item of mine [it's almost christmas]: that alloc_size could understand more general expressions for the size of the returned memory, not just the primitive one based on malloc()/calloc() prototypes. So e.g. kmemdup_nul() returns something of size $2+1, while it is also very common to have a alloc_foo(void) helper which returns something of size sizeof(struct foo). Unfortunately I don't think gcc's attribute parsing machinery can easily be tweaked into accepting struct bar *alloc_bars(unsigned count) __new_a_s(count * sizeof(struct bar)) but maybe clang could. If a compiler could understand that kind of attribute, it would also pave the way for implementing __attribute__((__buffer_size__(param, size, access))) e.g. memchr(src, c, size) __buffer_size(src, size, "r") clk_bulk_get(struct device *dev, int num_clks, struct clk_bulk_data *clks) __buffer_size(clks, num_clks * sizeof(*clks), "rw") which could be used for both static analysis and optional run-time instrumentation. Rasmus
