linux-hardening - Re: [PATCH RFC] slab: support for compiler-assisted type-based slab cache partitioning

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: <CANpmjNMpnyQ=PhZ4jkSiAR7gg8WJOiunoxwhRWuUD1U_EEnyrw@mail.gmail.com>
Date: Tue, 26 Aug 2025 12:50:18 +0200
From: Marco Elver <elver@...gle.com>
To: Kees Cook <kees@...nel.org>
Cc: linux-kernel@...r.kernel.org, kasan-dev@...glegroups.com, 
	"Gustavo A. R. Silva" <gustavoars@...nel.org>, "Liam R. Howlett" <Liam.Howlett@...cle.com>, 
	Alexander Potapenko <glider@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	Andrey Konovalov <andreyknvl@...il.com>, David Hildenbrand <david@...hat.com>, 
	David Rientjes <rientjes@...gle.com>, Dmitry Vyukov <dvyukov@...gle.com>, 
	Florent Revest <revest@...gle.com>, GONG Ruiqi <gongruiqi@...weicloud.com>, 
	Harry Yoo <harry.yoo@...cle.com>, Jann Horn <jannh@...gle.com>, 
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, Matteo Rizzo <matteorizzo@...gle.com>, 
	Michal Hocko <mhocko@...e.com>, Mike Rapoport <rppt@...nel.org>, Nathan Chancellor <nathan@...nel.org>, 
	Roman Gushchin <roman.gushchin@...ux.dev>, Suren Baghdasaryan <surenb@...gle.com>, 
	Vlastimil Babka <vbabka@...e.cz>, linux-hardening@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH RFC] slab: support for compiler-assisted type-based slab
 cache partitioning

On Mon, 25 Aug 2025 at 22:18, Kees Cook <kees@...nel.org> wrote:
> On August 25, 2025 11:44:40 AM EDT, Marco Elver <elver@...gle.com> wrote:
> >Additionally, when I compile my kernel with -Rpass=alloc-token, which
> >provides diagnostics where (after dead-code elimination) type inference
> >failed, I see 966 allocation sites where the compiler failed to identify
> >a type. Some initial review confirms these are mostly variable sized
> >buffers, but also include structs with trailing flexible length arrays
> >(the latter could be recognized by the compiler by teaching it to look
> >more deeply into complex expressions such as those generated by
> >struct_size).
>
> Can the type be extracted from an AST analysis of the lhs?
>
> struct foo *p = kmalloc(bytes, gfp);
>
> Doesn't tell us much from "bytes", but typeof(*p) does...

Certainly possible. It currently looks for explicit casts if it can't
figure out from malloc args, but is not yet able to deal with implicit
casts like that. But it's fixable - on the TODO list, and should
improve coverage even more.