linux-hardening - Re: [PATCH RFC v2] Randomized slab caches for 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 16 May 2023 14:43:46 +0200
From:   Alexander Lobakin <aleksander.lobakin@...el.com>
To:     Gong Ruiqi <gongruiqi1@...wei.com>
CC:     <linux-mm@...ck.org>, <linux-hardening@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        Hyeonggon Yoo <42.hyeyoo@...il.com>,
        <kasan-dev@...glegroups.com>,
        Wang Weiyang <wangweiyang2@...wei.com>,
        "Xiu Jianfeng" <xiujianfeng@...wei.com>,
        Pedro Falcato <pedro.falcato@...il.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Christoph Lameter <cl@...ux.com>,
        "David Rientjes" <rientjes@...gle.com>,
        Roman Gushchin <roman.gushchin@...ux.dev>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Pekka Enberg <penberg@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Paul Moore <paul@...l-moore.com>,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        "Gustavo A. R. Silva" <gustavoars@...nel.org>
Subject: Re: [PATCH RFC v2] Randomized slab caches for kmalloc()

From: Gong Ruiqi <gongruiqi1@...wei.com>
Date: Mon, 15 May 2023 14:26:31 +0800

> 
> On 2023/05/11 22:54, Alexander Lobakin wrote:

[...]

> I tried this way of implementation but it didn't work: it did not
> propagate from 16 to 1, but stopped in the middle. I think it's because
> the macro is somehow (indirectly) self-referential and the preprocessor
> won't expand it. Check this for more info:
> 
> https://gcc.gnu.org/onlinedocs/cpp/Self-Referential-Macros.html

Ooops, I missed that, sorry. Thanks for the link!

> 
>> Also I'd rather not put commas ',' at the end of each macro, they're
>> usually put outside where the macro is used.
> 
> It seems here we have to put commas at the end. Not only it's to align
> with how KMALLOC_{RCL,CGROUP,DMA}_NAME are implemented, but also
> otherwise the expansion of INIT_KMALLOC_INFO would in some cases be like:
> 
> {
> 	.name[KMALLOC_NORMAL]  = "kmalloc-" #__short_size,
> 	, // an empty entry with a comma
> }
> 
> which would cause compilation error in kmalloc_info[]'s initialization.

+

> 
>>> +#endif
>>> +#else // CONFIG_RANDOM_KMALLOC_CACHES
>>> +#define KMALLOC_RANDOM_NAME(N, sz)
>>> +#endif
>>> +
>>>  #define INIT_KMALLOC_INFO(__size, __short_size)			\
>>>  {								\
>>>  	.name[KMALLOC_NORMAL]  = "kmalloc-" #__short_size,	\
>>>  	KMALLOC_RCL_NAME(__short_size)				\
>>>  	KMALLOC_CGROUP_NAME(__short_size)			\
>>>  	KMALLOC_DMA_NAME(__short_size)				\
>>> +	KMALLOC_RANDOM_NAME(CONFIG_RANDOM_KMALLOC_CACHES_NR, __short_size)	\
>>
>> Can't those names be __initconst and here you'd just do one loop from 1
>> to KMALLOC_CACHES_NR, which would assign names? I'm not sure compilers
>> will expand that one to a compile-time constant and assigning 69
>> different string pointers per one kmalloc size is a bit of a waste to me.
> 
> I'm not sure if I understand the question correctly, but I believe these
> names have been __initconst since kmalloc_info[] is already marked with
> it. Please let me know if it doesn't answer your question.

Ah okay, it's just me trying to show off without looking at the code. I
thought INIT_KMALLOC_INFO() is used somewhere in a function (from its
name), but it's used to initialize const array, okay.

> 
>>>  	.size = __size,						\
>>>  }
[...]

Thanks,
Olek