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
