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] [day] [month] [year] [list]

Message-ID: <b64c6a55-bc27-443e-b2e2-8f6b8e2d1060@huawei.com>
Date: Sun, 26 Jan 2025 15:17:52 +0800
From: GONG Ruiqi <gongruiqi1@...wei.com>
To: Vlastimil Babka <vbabka@...e.cz>, "Christoph Lameter (Ampere)"
	<cl@...two.org>
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 2025/01/24 23:19, Vlastimil Babka wrote:
> 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.

Thanks for the advice!

I will send a V2 based on moving __kvmalloc_node_noprof() and kvfree()
to slub.c as soon as possible.

BR,
Ruiqi