Received-SPF: pass (google.com: domain of linux-kernel+bounces-117922-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Mon, 25 Mar 2024 13:26:34 -0700
From: Kees Cook <keescook@chromium.org>
To: Kent Overstreet <kent.overstreet@linux.dev>
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>,
	"GONG, Ruiqi" <gongruiqi@huaweicloud.com>,
	Xiu Jianfeng <xiujianfeng@huawei.com>,
	Suren Baghdasaryan <surenb@google.com>,
	Jann Horn <jannh@google.com>, Matteo Rizzo <matteorizzo@google.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-hardening@vger.kernel.org, jvoisin <julien.voisin@dustri.org>
Subject: Re: [PATCH v2 0/9] slab: Introduce dedicated bucket allocator
Message-ID: <202403251324.F8EADD2E@keescook>
References: <20240305100933.it.923-kees@kernel.org>
 <5e1571de-2c5a-4be4-93f4-01582094ee96@suse.cz>
 <24vn56fs7oohqgw3rhssiwglmviruqnt44y6oeajzvskostcrr@7jzhmxjbhcha>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <24vn56fs7oohqgw3rhssiwglmviruqnt44y6oeajzvskostcrr@7jzhmxjbhcha>

On Mon, Mar 25, 2024 at 03:32:12PM -0400, Kent Overstreet wrote:
> On Mon, Mar 25, 2024 at 10:03:23AM +0100, Vlastimil Babka wrote:
> > On 3/5/24 11:10 AM, 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().)
> > > 
> > >     Allows for confining allocations to a dedicated set of sized caches
> > >     (which have the same layout as the kmalloc caches).
> > > 
> > >     This can also be used in the future once codetag allocation annotations
> > >     exist to implement per-caller allocation cache isolation[0] even for
> > >     dynamic allocations.
> > > 
> > >     Link: https://lore.kernel.org/lkml/202402211449.401382D2AF@keescook [0]
> > > 
> > > After the implemetation are 2 example patches of how this could be used
> > > for some repeat "offenders" that get used in exploits. There are more to
> > > be isolated beyond just these. Repeating the commit log for patch 8 here:
> > > 
> > >     The msg subsystem is a common target for exploiting[1][2][3][4][5][6]
> > >     use-after-free type confusion flaws in the kernel for both read and
> > >     write primitives. Avoid having a user-controlled size cache share the
> > >     global kmalloc allocator by using a separate set of kmalloc buckets.
> > > 
> > >     Link: https://blog.hacktivesecurity.com/index.php/2022/06/13/linux-kernel-exploit-development-1day-case-study/ [1]
> > >     Link: https://hardenedvault.net/blog/2022-11-13-msg_msg-recon-mitigation-ved/ [2]
> > >     Link: https://www.willsroot.io/2021/08/corctf-2021-fire-of-salvation-writeup.html [3]
> > >     Link: https://a13xp0p0v.github.io/2021/02/09/CVE-2021-26708.html [4]
> > >     Link: https://google.github.io/security-research/pocs/linux/cve-2021-22555/writeup.html [5]
> > >     Link: https://zplin.me/papers/ELOISE.pdf [6]
> > 
> > Hi Kees,
> > 
> > after reading [1] I think the points should be addressed, mainly about the
> > feasibility of converting users manually. On a related technical note I
> > worry what will become of /proc/slabinfo when we convert non-trivial amounts
> > of users.
> 
> There shouldn't be any need to convert users to this interface - just
> leverage the alloc_hooks() macro.

I expect to do both -- using the alloc_hooks() macro to do
per-call-site-allocation caches will certainly have a non-trivial amount
of memory usage overhead, and not all systems will want it. We can have
a boot param to choose between per-site and normal, though normal can
include a handful of these manually identified places.

-- 
Kees Cook