On Fri, Jul 19, 2024 at 08:50:41PM -0700, David Rientjes wrote:
> On Fri, 19 Jul 2024, Kees Cook wrote:
>
> > diff --git a/include/linux/slab.h b/include/linux/slab.h
> > index 7247e217e21b..3817554f2d51 100644
> > --- a/include/linux/slab.h
> > +++ b/include/linux/slab.h
> > @@ -665,6 +665,44 @@ static __always_inline __alloc_size(1) void
> > *kmalloc_noprof(size_t size, gfp_t f
> > }
> > #define kmalloc(...)
> > alloc_hooks(kmalloc_noprof(__VA_ARGS__))
> >
> > +#define __alloc_obj3(ALLOC, P, COUNT, FLAGS) \
> > +({ \
> > + size_t __obj_size = size_mul(sizeof(*P), COUNT); \
> > + void *__obj_ptr; \
> > + (P) = __obj_ptr = ALLOC(__obj_size, FLAGS); \
> > + if (!__obj_ptr) \
> > + __obj_size = 0; \
> > + __obj_size; \
> > +})
> > +
> > +#define __alloc_obj2(ALLOC, P, FLAGS) __alloc_obj3(ALLOC, P, 1, FLAGS)
> > +
> > +#define __alloc_obj4(ALLOC, P, FAM, COUNT, FLAGS) \
> > +({ \
> > + size_t __obj_size = struct_size(P, FAM, COUNT); \
> > + void *__obj_ptr; \
> > + (P) = __obj_ptr = ALLOC(__obj_size, FLAGS); \
> > + if (!__obj_ptr) \
> > + __obj_size = 0; \
> > + __obj_size; \
> > +})
> > +
> > +#define kmalloc_obj(...) \
> > + CONCATENATE(__alloc_obj, \
> > + COUNT_ARGS(__VA_ARGS__))(kmalloc, __VA_ARGS__)
> > +
> > +#define kzalloc_obj(...) \
> > + CONCATENATE(__alloc_obj, \
> > + COUNT_ARGS(__VA_ARGS__))(kzalloc, __VA_ARGS__)
> > +
> > +#define kvmalloc_obj(...) \
> > + CONCATENATE(__alloc_obj, \
> > + COUNT_ARGS(__VA_ARGS__))(kvmalloc, __VA_ARGS__)
> > +
> > +#define kvzalloc_obj(...) \
> > + CONCATENATE(__alloc_obj, \
> > + COUNT_ARGS(__VA_ARGS__))(kvzalloc, __VA_ARGS__)
> > +
> > static __always_inline __alloc_size(1) void *kmalloc_node_noprof(size_t
> > size, gfp_t flags, int node)
> > {
> > if (__builtin_constant_p(size) && size) {
>
> I'm supportive of this especially because it will pave a pathway toward
> future hardening work. Request: could we get an addition to
Thanks!
> Documentation/ that explains how common idioms today can be converted to
> these new macros for future users? The above makes sense only when
> accompanied by your commit description :)
Oh, yes. Very good point! I will figure out a place to add this. I'm not
sure if kerndoc would be best here.
--
Kees Cook
