linux-hardening - Re: [PATCH v4 2/6] mm/slab: Plumb kmem_buckets into __do_kmalloc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <801d4833-6a29-4134-8ed6-5006d157af88@suse.cz>
Date: Tue, 4 Jun 2024 14:30:31 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Kees Cook <kees@...nel.org>
Cc: Christoph Lameter <cl@...ux.com>, Pekka Enberg <penberg@...nel.org>,
 David Rientjes <rientjes@...gle.com>, Joonsoo Kim <iamjoonsoo.kim@....com>,
 jvoisin <julien.voisin@...tri.org>, Andrew Morton
 <akpm@...ux-foundation.org>, Roman Gushchin <roman.gushchin@...ux.dev>,
 Hyeonggon Yoo <42.hyeyoo@...il.com>, linux-mm@...ck.org,
 linux-hardening@...r.kernel.org, "GONG, Ruiqi" <gongruiqi@...weicloud.com>,
 Xiu Jianfeng <xiujianfeng@...wei.com>, Suren Baghdasaryan
 <surenb@...gle.com>, Kent Overstreet <kent.overstreet@...ux.dev>,
 Jann Horn <jannh@...gle.com>, Matteo Rizzo <matteorizzo@...gle.com>,
 Thomas Graf <tgraf@...g.ch>, Herbert Xu <herbert@...dor.apana.org.au>,
 linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v4 2/6] mm/slab: Plumb kmem_buckets into
 __do_kmalloc_node()

On 6/4/24 12:44 AM, Kees Cook wrote:
> On Mon, Jun 03, 2024 at 07:06:15PM +0200, Vlastimil Babka wrote:
>> On 5/31/24 9:14 PM, Kees Cook wrote:
>> > Introduce CONFIG_SLAB_BUCKETS which provides the infrastructure to
>> > support separated kmalloc buckets (in the follow kmem_buckets_create()
>> > patches and future codetag-based separation). Since this will provide
>> > a mitigation for a very common case of exploits, enable it by default.
>> 
>> Are you sure? I thought there was a policy that nobody is special enough
>> to have stuff enabled by default. Is it worth risking Linus shouting? :)
> 
> I think it's important to have this enabled given how common the
> exploitation methodology is and how cheap this solution is. Regardless,
> if you want it "default n", I can change it.

Yeah, I'd just recommend it in the help, noting it has a bit of memory
overhead. Defaults are not that important anyway IMHO, either it's distro
doing the config, and individually security conscious people should know
what they are doing.

> 
> This looks really nice, thank you! This is well aligned with the codetag
> followup, which also needs to have "size" be very easy to find (to the
> macros can check for compile-time-constant or not).
> 
> I will go work from your branch...

Great!

> Thanks!
> 
> -Kees
>