linux-kernel - Re: [PATCH v3 1/3] slab: make check

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: Mon, 17 Jun 2024 13:08:52 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Chengming Zhou <chengming.zhou@...ux.dev>,
 "Christoph Lameter (Ampere)" <cl@...ux.com>
Cc: 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>, Feng Tang <feng.tang@...el.com>,
 linux-mm@...ck.org, linux-kernel@...r.kernel.org,
 zhouchengming@...edance.com, Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH v3 1/3] slab: make check_object() more consistent

On 6/17/24 12:29 PM, Chengming Zhou wrote:
> On 2024/6/17 17:51, Vlastimil Babka wrote:
>> On 6/14/24 4:40 AM, Chengming Zhou wrote:
>>> On 2024/6/12 06:52, Christoph Lameter (Ampere) wrote:
>>>
>>> This reminds me that we can't toggle slub_debug options for kmem_cache in runtime,
>>> I'm wondering is it useful to be able to enable/disable debug options in runtime?
>>> We can implement this feature by using per-slab debug options, so per-slab has
>>> independent execution path, in which some slabs with debug options enabled go
>>> the slow path, while others can still go fast path.
>> 
>> Many of the debug options change the layout of objects in slabs (i.e. affect
>> calculate_sizes()) so it would be very complicated to change things in
> Yeah, so each slab in the same kmem_cache can have different layout (caused by
> different debug_options enabled), we use these different information to decide
> which path each slab should go.
> 
> Then the problem is saving these different layout information for each slab,
> which has an unused _mapcount to reuse, can be used as index to find its layout
> information in the kmem_cache.
> 
> I haven't thought too much about this, so must be missing something.

Yeah it seems very complex with dubious benefits. Possibly would affect fast
paths too as we might disable debugging but still have some slabs around
that were created with debugging enabled so we'll need to keep doing the
checks for them... We'd basically have to keep the "percpu slabs and their
fastpaths can't be used" mode for given cache even after the debugging is
disabled, and that would already defeat most of the performance benefit.

> Thanks.
> 
>> runtime. Also the cache might be merged with other ones if it boots without
>> debug... I don't think it would be feasible at all.
>> 
>>> No sure if it's useful in some cases? Maybe KFENCE is enough? Just my random thoughts.
>>>
>>> Thanks.
>>