On Tue, Oct 07, 2025 at 08:18:28PM +0200, Marco Elver wrote: > On Tue, 7 Oct 2025 at 19:47, Christoph Lameter (Ampere) <[email protected]> > wrote: > > > > On Tue, 7 Oct 2025, Kees Cook wrote: > > > > > But all of that is orthogonal to just _having_ the type info available. > > > > iOS did go the path of creating basically one slab cache for each > > "type" of kmalloc for security reasons. > > > > See > > https://security.apple.com/blog/towards-the-next-generation-of-xnu-memory-safety/ > > We can get something similar to that with: > https://lore.kernel.org/all/[email protected]/ > Pending compiler support which is going to become available in a few > months (probably). > That version used the existing RANDOM_KMALLOC_CACHES choice of 16 slab > caches, but there's no fundamental limitation to go higher.
Right -- having compiler support for dealing with types at compile time means we can create the slab caches statically (instead of any particular fixed number, even the 16 from RANDOM_KMALLOC_CACHES). Another compiler feature that might help here is getting a unique u32 for arbitrary type info, which is also how KCFI works: https://lore.kernel.org/linux-hardening/[email protected]/ My main issue is that I prefer explicitly exposing the type instead of having the compiler have to guess. We want it for more than just slab isolation (e.g. examining alignment). > Note, this mitigation is likely not as strong as we'd like to without > SLAB_VIRTUAL (or so I'm told): https://lwn.net/Articles/944647/ True, but both "halves" are needed -- SLAB_VIRTUAL isn't as robust without the type separation either. -Kees -- Kees Cook
