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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202601080912.F762F30B6@keescook>
Date: Thu, 8 Jan 2026 09:15:40 -0800
From: Kees Cook <kees@...nel.org>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: Christoph Lameter <cl@...ux.com>, Pekka Enberg <penberg@...nel.org>,
	David Rientjes <rientjes@...gle.com>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Roman Gushchin <roman.gushchin@...ux.dev>,
	Hyeonggon Yoo <42.hyeyoo@...il.com>,
	"Gustavo A . R . Silva" <gustavoars@...nel.org>,
	Bill Wendling <morbo@...gle.com>,
	Justin Stitt <justinstitt@...gle.com>, Jann Horn <jannh@...gle.com>,
	Przemek Kitszel <przemyslaw.kitszel@...el.com>,
	Marco Elver <elver@...gle.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Sasha Levin <sashal@...nel.org>, linux-mm@...ck.org,
	Randy Dunlap <rdunlap@...radead.org>,
	Miguel Ojeda <ojeda@...nel.org>,
	Matthew Wilcox <willy@...radead.org>,
	John Hubbard <jhubbard@...dia.com>, Joe Perches <joe@...ches.com>,
	Vegard Nossum <vegard.nossum@...cle.com>,
	Harry Yoo <harry.yoo@...cle.com>,
	Nathan Chancellor <nathan@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Nick Desaulniers <nick.desaulniers+lkml@...il.com>,
	Jonathan Corbet <corbet@....net>, Jakub Kicinski <kuba@...nel.org>,
	Yafang Shao <laoar.shao@...il.com>,
	Tony Ambardar <tony.ambardar@...il.com>,
	Alexander Lobakin <aleksander.lobakin@...el.com>,
	Jan Hendrik Farr <kernel@...rr.cc>,
	Alexander Potapenko <glider@...gle.com>,
	linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org,
	linux-doc@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [PATCH v6 1/5] slab: Introduce kmalloc_obj() and family

On Thu, Jan 08, 2026 at 03:01:00PM +0100, Vlastimil Babka wrote:
> On 12/4/25 00:30, Kees Cook wrote:
> > Introduce type-aware kmalloc-family helpers to replace the common
> > idioms for single object and arrays of objects allocation:
> > 
> > 	ptr = kmalloc(sizeof(*ptr), gfp);
> > 	ptr = kmalloc(sizeof(struct some_obj_name), gfp);
> > 	ptr = kzalloc(sizeof(*ptr), gfp);
> > 	ptr = kmalloc_array(count, sizeof(*ptr), gfp);
> > 	ptr = kcalloc(count, sizeof(*ptr), gfp);
> > 
> > These become, respectively:
> > 
> > 	ptr = kmalloc_obj(*ptr, gfp);
> > 	ptr = kmalloc_obj(*ptr, gfp);
> > 	ptr = kzalloc_obj(*ptr, gfp);
> > 	ptr = kmalloc_objs(*ptr, count, gfp);
> > 	ptr = kzalloc_objs(*ptr, count, gfp);
> > 
> > Beyond the other benefits outlined below, the primary ergonomic benefit
> > is the elimination of needing "sizeof" nor the type name, and the
> > enforcement of assignment types (they do not return "void *", but rather
> > a pointer to the type of the first argument). The type name _can_ be
> > used, though, in the case where an assignment is indirect (e.g. via
> > "return"). This additionally allows[1] variables to be declared via
> > __auto_type:
> > 
> > 	__auto_type ptr = kmalloc_obj(struct foo, gfp);
> > 
> > Internal introspection of the allocated type now becomes possible,
> > allowing for future alignment-aware choices to be made by the allocator
> > and future hardening work that can be type sensitive. For example,
> > adding __alignof(*ptr) as an argument to the internal allocators so that
> > appropriate/efficient alignment choices can be made, or being able to
> > correctly choose per-allocation offset randomization within a bucket
> > that does not break alignment requirements.
> > 
> > Link: https://lore.kernel.org/all/CAHk-=wiCOTW5UftUrAnvJkr6769D29tF7Of79gUjdQHS_TkF5A@mail.gmail.com/ [1]
> > Signed-off-by: Kees Cook <kees@...nel.org>
> 
> Acked-by: Vlastimil Babka <vbabka@...e.cz>
> 
> How do you plan to handle this series? Given minimal slab changes (just
> wrappers) but there being also changes elsewhere, want to use your hardening
> tree? I wouldn't mind.

Ah! Sure, yeah, I can take it. Thanks for the Ack. I'll get it into
-next and refresh the treewide changes.

-Kees

-- 
Kees Cook

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ