linux-hardening - Re: [PATCH] mm/slab: Achieve better kmalloc caches randomization in kvmalloc

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: <62044279-0c56-4185-97f7-7afac65ff449@suse.cz>
Date: Fri, 24 Jan 2025 16:19:55 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: "Christoph Lameter (Ampere)" <cl@...two.org>,
 GONG Ruiqi <gongruiqi1@...wei.com>
Cc: Pekka Enberg <penberg@...nel.org>, David Rientjes <rientjes@...gle.com>,
 Joonsoo Kim <iamjoonsoo.kim@....com>,
 Andrew Morton <akpm@...ux-foundation.org>, Kees Cook <kees@...nel.org>,
 Tamas Koczka <poprdi@...gle.com>, Roman Gushchin <roman.gushchin@...ux.dev>,
 Hyeonggon Yoo <42.hyeyoo@...il.com>, Xiu Jianfeng <xiujianfeng@...wei.com>,
 linux-mm@...ck.org, linux-hardening@...r.kernel.org,
 linux-kernel@...r.kernel.org, "Uladzislau Rezki (Sony)" <urezki@...il.com>
Subject: Re: [PATCH] mm/slab: Achieve better kmalloc caches randomization in
 kvmalloc

On 1/22/25 17:02, Christoph Lameter (Ampere) wrote:
> On Wed, 22 Jan 2025, GONG Ruiqi wrote:
> 
>>
>> +void *__kmalloc_node_inline(size_t size, kmem_buckets *b, gfp_t flags,
>> +				int node, unsigned long caller);
>> +
> 
> 
> Huh? Is this inline? Where is the body of the function?
> 
>> diff --git a/mm/slub.c b/mm/slub.c
>> index c2151c9fee22..ec75070345c6 100644
>> --- a/mm/slub.c
>> +++ b/mm/slub.c
>> @@ -4319,6 +4319,13 @@ void *__kmalloc_node_track_caller_noprof(DECL_BUCKET_PARAMS(size, b), gfp_t flag
>>  }
>>  EXPORT_SYMBOL(__kmalloc_node_track_caller_noprof);
>>
>> +__always_inline void *__kmalloc_node_inline(size_t size, kmem_buckets *b,
>> +					    gfp_t flags, int node,
>> +					    unsigned long caller)
>> +{
>> +	return __do_kmalloc_node(size, b, flags, node, caller);
>> +}
>> +
> 
> inline functions need to be defined in the header file AFAICT.

Yeah, this could possibly inline only with LTO (dunno if it does). But the
real difference is passing __kvmalloc_node_noprof()'s _RET_IP_ as caller.

Maybe instead of this new wrapper we could just move
__kvmalloc_node_noprof() to slub.c and access __do_kmalloc_node() directly.
For consistency also kvfree() and whatever necessary dependencies. The
placement in util.c is kinda weird anyway and IIRC we already moved
krealloc() due to needing deeper involvement with slab internals. The
vmalloc part of kvmalloc/kvfree is kinda a self-contained fallback that can
be just called from slub.c as well as from util.c.