On 2024/03/08 4:31, Kees Cook wrote: > On Wed, Mar 06, 2024 at 09:47:36AM +0800, GONG, Ruiqi wrote: >> >> >> On 2024/03/05 18:10, Kees Cook wrote: >>> Hi, >>> >>> Repeating the commit logs for patch 4 here: >>> >>> Dedicated caches are available For fixed size allocations via >>> kmem_cache_alloc(), but for dynamically sized allocations there is only >>> the global kmalloc API's set of buckets available. This means it isn't >>> possible to separate specific sets of dynamically sized allocations into >>> a separate collection of caches. >>> >>> This leads to a use-after-free exploitation weakness in the Linux >>> kernel since many heap memory spraying/grooming attacks depend on using >>> userspace-controllable dynamically sized allocations to collide with >>> fixed size allocations that end up in same cache. >>> >>> While CONFIG_RANDOM_KMALLOC_CACHES provides a probabilistic defense >>> against these kinds of "type confusion" attacks, including for fixed >>> same-size heap objects, we can create a complementary deterministic >>> defense for dynamically sized allocations. >>> >>> In order to isolate user-controllable sized allocations from system >>> allocations, introduce kmem_buckets_create(), which behaves like >>> kmem_cache_create(). (The next patch will introduce kmem_buckets_alloc(), >>> which behaves like kmem_cache_alloc().) >> >> So can I say the vision here would be to make all the kernel interfaces >> that handles user space input to use separated caches? Which looks like >> creating a "grey zone" in the middle of kernel space (trusted) and user >> space (untrusted) memory. I've also thought that maybe hardening on the >> "border" could be more efficient and targeted than a mitigation that >> affects globally, e.g. CONFIG_RANDOM_KMALLOC_CACHES. > > I think it ends up having a similar effect, yes. The more copies that > move to memdup_user(), the more coverage is created. The main point is to > just not share caches between different kinds of allocations. The most > abused version of this is the userspace size-controllable allocations, > which this targets. I agree. Currently if we want to fulfill a more strict separation between user-space manageable memory and other memory in kernel space, technically speaking for fixed size allocations we could transform them into using dedicated caches (i.e. kmem_cache_create()), but for dynamic size allocations I don't think of any solution. With the APIs provided by this patch set, we've got something that works. > ... The existing caches (which could still be used for > type confusion attacks when the sizes are sufficiently similar) have a > good chance of being mitigated by CONFIG_RANDOM_KMALLOC_CACHES already, > so this proposed change is just complementary, IMO. Maybe in the future we could require that all user-kernel interfaces that make use of SLAB caches should use either kmem_cache_create() or kmem_buckets_create()? ;) > > -Kees >
