All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <kees@kernel.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>,
	Thomas Graf <tgraf@suug.ch>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	julien.voisin@dustri.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH v3 0/6] slab: Introduce dedicated bucket allocator
Date: Fri, 31 May 2024 09:39:48 -0700	[thread overview]
Message-ID: <202405310938.A6EFEADB79@keescook> (raw)
In-Reply-To: <7nonr2cucww7j55kresncgt23pvgt3pmnfukqpnqblk3fmtfdl@ewhqe3ylioz2>

On Fri, May 24, 2024 at 10:54:58AM -0400, Kent Overstreet wrote:
> On Wed, Apr 24, 2024 at 02:40:57PM -0700, Kees Cook wrote:
> > Hi,
> > 
> > Series change history:
> > 
> >  v3:
> >   - clarify rationale and purpose in commit log
> >   - rebase to -next (CONFIG_CODE_TAGGING)
> >   - simplify calling styles and split out bucket plumbing more cleanly
> >   - consolidate kmem_buckets_*() family introduction patches
> >  v2: https://lore.kernel.org/lkml/20240305100933.it.923-kees@kernel.org/
> >  v1: https://lore.kernel.org/lkml/20240304184252.work.496-kees@kernel.org/
> > 
> > For the cover letter, I'm repeating commit log for patch 4 here, which has
> > additional clarifications and rationale since v2:
> > 
> >     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.
> 
> This is going to increase internal fragmentation in the slab allocator,
> so we're going to need better, more visible numbers on the amount of
> memory stranded thusly, so users can easily see the effect this has.

Yes, but not significantly. It's less than the 16-buckets randomized
kmalloc implementation. The numbers will be visible in /proc/slabinfo
just like any other.

> Please also document this effect and point users in the documentation
> where to check, so that we devs can get feedback on this.

Okay, sure. In the commit log, or did you have somewhere else in mind?

-- 
Kees Cook

      reply	other threads:[~2024-05-31 16:39 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-24 21:40 [PATCH v3 0/6] slab: Introduce dedicated bucket allocator Kees Cook
2024-04-24 21:40 ` [PATCH v3 1/6] mm/slab: Introduce kmem_buckets typedef Kees Cook
2024-04-24 21:40 ` [PATCH v3 2/6] mm/slab: Plumb kmem_buckets into __do_kmalloc_node() Kees Cook
2024-05-24 13:38   ` Vlastimil Babka
2024-05-31 16:42     ` Kees Cook
2024-05-24 15:01   ` Kent Overstreet
2024-05-31 16:48     ` Kees Cook
2024-05-31 16:50       ` Kent Overstreet
2024-05-31 16:51       ` Kent Overstreet
2024-05-31 20:59         ` Kees Cook
2024-04-24 21:41 ` [PATCH v3 3/6] mm/slab: Introduce __kvmalloc_node() that can take kmem_buckets argument Kees Cook
2024-04-24 21:41 ` [PATCH v3 4/6] mm/slab: Introduce kmem_buckets_create() and family Kees Cook
2024-05-24 13:43   ` Vlastimil Babka
2024-05-31 16:37     ` Kees Cook
2024-04-24 21:41 ` [PATCH v3 5/6] ipc, msg: Use dedicated slab buckets for alloc_msg() Kees Cook
2024-04-24 21:41 ` [PATCH v3 6/6] mm/util: Use dedicated slab buckets for memdup_user() Kees Cook
2024-04-28 11:02 ` [PATCH v3 0/6] slab: Introduce dedicated bucket allocator jvoisin
2024-04-28 17:02   ` Kees Cook
2024-05-03 13:39     ` jvoisin
2024-05-03 19:06       ` Kees Cook
2024-05-24 14:54 ` Kent Overstreet
2024-05-31 16:39   ` Kees Cook [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202405310938.A6EFEADB79@keescook \
    --to=kees@kernel.org \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=gongruiqi@huaweicloud.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=jannh@google.com \
    --cc=julien.voisin@dustri.org \
    --cc=kent.overstreet@linux.dev \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=matteorizzo@google.com \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=surenb@google.com \
    --cc=tgraf@suug.ch \
    --cc=vbabka@suse.cz \
    --cc=xiujianfeng@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.