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. 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) Thanks!
