Received-SPF: pass (google.com: domain of linux-kernel+bounces-96195-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Thu, 7 Mar 2024 12:31:17 -0800
From: Kees Cook <keescook@chromium.org>
To: "GONG, Ruiqi" <gongruiqi@huaweicloud.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Lameter <cl@linux.com>, Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	Hyeonggon Yoo <42.hyeyoo@gmail.com>,
	Xiu Jianfeng <xiujianfeng@huawei.com>,
	Suren Baghdasaryan <surenb@google.com>,
	Kent Overstreet <kent.overstreet@linux.dev>,
	Jann Horn <jannh@google.com>, Matteo Rizzo <matteorizzo@google.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-hardening@vger.kernel.org
Subject: Re: [PATCH v2 0/9] slab: Introduce dedicated bucket allocator
Message-ID: <202403071227.D29DE5F8C4@keescook>
References: <20240305100933.it.923-kees@kernel.org>
 <b5f9f094-51d3-445a-b19b-99fc1cd7cac1@huaweicloud.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b5f9f094-51d3-445a-b19b-99fc1cd7cac1@huaweicloud.com>

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. 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.

-Kees

-- 
Kees Cook