On Wed, 8 Oct 2025 at 09:49, Vegard Nossum <[email protected]> wrote: > > > On 08/10/2025 06:20, Kees Cook wrote: > > 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: > >>> 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). > > Maybe I'm missing the point here, but I think we can already do per- > callsite static caches without specific new compiler support:
What we want is not per-callsite but per-type caches, possibly with some smarter cache organization based on the properties of that type (does type contain/is pointer), where the latter is required if we cannot have as many caches as there are types. Per-callsite caches could be stronger than per-type caches (with the exception where a single callsite can allocate multiple types), but neither per-callsite and full per-type caches are likely feasible due to performance reasons. So we need some scheme that allows bounding the number of caches, and letting the compiler help us out with type introspection is probably the most reasonable approach.
