Re: [RFC][PATCH 0/4] slab: Allow for type introspection during allocation

From: Kees Cook
Date: Tue Jul 09 2024 - 14:57:28 EST


On Tue, Jul 09, 2024 at 04:57:38PM +0000, Roman Gushchin wrote:
> On Mon, Jul 08, 2024 at 12:18:34PM -0700, Kees Cook wrote:
> > Hi,
> >
> > This is an RFC for some changes I'd like to make to the kernel's
> > allocators (starting with slab) that allow for type introspection, which
> > has been a long-time gap in potential analysis capabilities available
> > at compile-time. The changes here are just a "first step" example that
> > updates kmalloc() and kzalloc() to show what I'm thinking we can do,
> > and shows an example conversion within the fs/pstore tree.
> >
> > Repeating patch 3's commit log here:
> >
> > There is currently no way for the slab to know what type is being
> > allocated, and this hampers the development of any logic that would need
> > this information including basic type checking, alignment need analysis,
> > etc.
> >
> > Allow the size argument to optionally be a variable, from which the
> > type (and there by the size, alignment, or any other features) can be
> > determined at compile-time. This allows for the incremental replacement
> > of the classic code pattern:
> >
> > obj = kmalloc(sizeof(*obj), gfp);
> >
> > into:
> >
> > obj = kmalloc(obj, gfp);
> >
> > As an additional build-time safety feature, the return value of kmalloc()
> > also becomes typed so that the assignment and first argument cannot drift,
> > doing away with the other, more fragile, classic code pattern:
> >
> > obj = kmalloc(sizeof(struct the_object), gfp);
> >
> > into:
> >
> > obj = kmalloc(obj, gfp);
>
> I like the idea, however it's not as simple and straightforward because
> it's common for structures to have a variable part (usually at the end)
> and also allocate more than one structure at once.
>
> There are many allocations which look like
> kmalloc(sizeof(my_struct) * 2 + SOME_MAGIC_LENGTH, GFP_...)
> or something like this, which you can't easily convert to your scheme.

Right -- and with this we can leave those as-is initially (since a size
argument will still work).

> The only option I see is to introduce the new set of functions/macros,
> something like kmalloc_obj() or kmalloc_struct(). Or maybe tmalloc()?
> (t for typed)

Yeah, in a neighboring thread I was talking about a kmalloc_obj that
would handle fixed-sized structs, flexible array structs, and arrays. I
need to prove out the array part, but the first two should be trivial to
implement.

--
Kees Cook