From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 96946CD11DB for ; Mon, 25 Mar 2024 19:41:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 293FD6B0092; Mon, 25 Mar 2024 15:41:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 21C616B0093; Mon, 25 Mar 2024 15:41:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0BDB06B0095; Mon, 25 Mar 2024 15:41:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id EDA9D6B0092 for ; Mon, 25 Mar 2024 15:40:59 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 71646807BC for ; Mon, 25 Mar 2024 19:40:59 +0000 (UTC) X-FDA: 81936579438.17.6FCBFB3 Received: from out-188.mta1.migadu.com (out-188.mta1.migadu.com [95.215.58.188]) by imf30.hostedemail.com (Postfix) with ESMTP id BF33E80005 for ; Mon, 25 Mar 2024 19:40:57 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=B1nzWHQz; spf=pass (imf30.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.188 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711395657; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=P/ulXyWKqkzXiOH+Zl+aph4Lwf/XKPejosEhROqYyvU=; b=61yCp87j3Kao2SFC7lFzDpotcRytD74EHVhCZG91I5r/1MAoL1Gw2ACoVuP7v0gZ8NAa22 8THyM5clKlCQxV9J3gBVIlXo/wDKwRt6GCK9JLDkw4m34BrSU53bUtXlE/Q3SuYcieh85Y ihWoBM3KSLw8U3EVJuSYcfsfJhzCA4o= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711395657; a=rsa-sha256; cv=none; b=aMZumpcH6e9j8h7US2LzKVeJMbehHtb2bCeZGjup6k4BPj3AEQHL0gfjifRe9eoV++aLFs jNULrJhAEY4uR41AkfsxTlBYTGHBFJHnMtHqag3rYSiZd4alRFK6KLcdseCHpOsGh8gQ00 jKGIzLQ6IOmomN7hVWx2IL136l7uhNU= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=B1nzWHQz; spf=pass (imf30.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.188 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Mon, 25 Mar 2024 15:40:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1711395655; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=P/ulXyWKqkzXiOH+Zl+aph4Lwf/XKPejosEhROqYyvU=; b=B1nzWHQz4fk8V3rHqtSVsCx9Y8hVkRHvgrE6Bvb1g36Mh6Av3cmyu8EN7JqrqT14Ci/PLQ N/Hhc46Z68FolOA4BiuHuB+K2LrNr1oASp+HeKbGSrjxoqKtfXzyhSY6z9DQcdp7ihUPY/ L5b8cDpzsUZYaoK4mu7IQW4sc2pYXC8= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Kees Cook Cc: Vlastimil Babka , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-mm@kvack.org, "GONG, Ruiqi" , Xiu Jianfeng , Suren Baghdasaryan , Jann Horn , Matteo Rizzo , linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH v2 4/9] slab: Introduce kmem_buckets_create() Message-ID: References: <20240305100933.it.923-kees@kernel.org> <20240305101026.694758-4-keescook@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240305101026.694758-4-keescook@chromium.org> X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: BF33E80005 X-Rspam-User: X-Stat-Signature: ddopuhg35tjcfur89x5fe1za58m6x97b X-Rspamd-Server: rspam03 X-HE-Tag: 1711395657-797531 X-HE-Meta: U2FsdGVkX1+abKEILCXC5LT3+8LF6PtB/Ud6gqmzrWBva6r6Vsb8ZFjjimKSLp/zrDHpPDUNz7YZoLNuvCWkar3WvAXGTi1jvYoeT+Jg4TQp9GrgX4gh9zqxGBjCuVP/E6wj47SE1vJmTppxEwVy8sPfSx8mFgDRbNzzOVtIf8v+v5o6UUpT6+GS8xE7ggSAW1b5AULmthmDZQTSAq3Yxx7cm9pJ80bo3Hpwd4f8md3rZozlyeK2whxu8sWTWRx/4PTQfIxIEMjVd4IndCwKkDdas+2fOqkigf2nV2s+xBkglZqgmVr1uiktjYrywMJvcmTel11xOaffR0lBeuYeCPJPSp8gBNpWhLjRCOJSlHFxifXAFVnVKKscYyCUEemeGTZ+vNwmEoh32SeNYRyRaQ9ycjsxIGR08CoqPVkZZlFIfyMpH7ZOxNjISk6mEcf0y3W1SaHVUaXYp7Q5fXuo353a0wmJQzXl+SbgHGdc/DP3FBSVAHidRS9XDObKgafS59ILWBTA6yI0il31sctAJPCioUY0KeMCHujQvx23cpRYSOvQCDfkccUsnoOVkUWXrdS2aMsa+AfhUKzC+MZBD5TTDekaSflsbeGFTTVM2b8AIgFNim2qCTa+JgW9WyRVeioIjyHhsPOAZNQ+nn5u+KYSfaSkYmBDs9dqI4wtweccjamyzvh4SpAVuFn1ydcYxy8dQnjPA/sFEyTJ37DMhexhHPtZYYTe8ZuqqkKsa8QAUhzghUTjXb4MXrJDBgD+Dk/8Ex5i0BXiipbvLbySDAUO9wj1kLur4XooQV6HwUuAUM5gLzyPSK88GfuZ/NIo3ECeA6TQoWwZD/YmnT7eEy6WhpPRFSrePUHkMx51NKwRR4zjFqz0T4vcUfoVG+dKFoRYgwORndP4gKeo73mvvATGitm41DEdD8ZjfqtR4Vo= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Mar 05, 2024 at 02:10:20AM -0800, Kees Cook wrote: > 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[1] even for > dynamic allocations. > > Link: https://lore.kernel.org/lkml/202402211449.401382D2AF@keescook [1] > Signed-off-by: Kees Cook > --- > Cc: Vlastimil Babka > Cc: Christoph Lameter > Cc: Pekka Enberg > Cc: David Rientjes > Cc: Joonsoo Kim > Cc: Andrew Morton > Cc: Roman Gushchin > Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com> > Cc: linux-mm@kvack.org > --- > include/linux/slab.h | 5 +++ > mm/slab_common.c | 72 ++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 77 insertions(+) > > diff --git a/include/linux/slab.h b/include/linux/slab.h > index f26ac9a6ef9f..058d0e3cd181 100644 > --- a/include/linux/slab.h > +++ b/include/linux/slab.h > @@ -493,6 +493,11 @@ void *kmem_cache_alloc_lru(struct kmem_cache *s, struct list_lru *lru, > gfp_t gfpflags) __assume_slab_alignment __malloc; > void kmem_cache_free(struct kmem_cache *s, void *objp); > > +kmem_buckets *kmem_buckets_create(const char *name, unsigned int align, > + slab_flags_t flags, > + unsigned int useroffset, unsigned int usersize, > + void (*ctor)(void *)); I'd prefer an API that initialized an object over one that allocates it - that is, prefer kmem_buckets_init(kmem_buckets *bucekts, ...) by forcing it to be separately allocated, you're adding a pointer deref to every access. That would also allow for kmem_buckets to be lazily initialized, which would play nicely declaring the kmem_buckets in the alloc_hooks() macro. I'm curious what all the arguments to kmem_buckets_create() are needed for, if this is supposed to be a replacement for kmalloc() users.