linux-kernel - Re: [PATCH] mm: slub: reinitialize random sequence cache on slab object update

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: <f5c4c74ecb1f43992285bb5f57ee874c@codeaurora.org>
Date:   Thu, 20 Feb 2020 10:42:52 +0530
From:   vjitta@...eaurora.org
To:     Christopher Lameter <cl@...ux.com>
Cc:     penberg@...nel.org, rientjes@...gle.com, iamjoonsoo.kim@....com,
        akpm@...ux-foundation.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, vinmenon@...eaurora.org,
        kernel-team@...roid.com, linux-kernel-owner@...r.kernel.org
Subject: Re: [PATCH] mm: slub: reinitialize random sequence cache on slab
 object update

On 2020-02-03 12:27, Vijayanand Jitta wrote:
> On 1/30/2020 11:58 PM, Christopher Lameter wrote:
>> On Thu, 30 Jan 2020, vjitta@...eaurora.org wrote:
>> 
>>> Random sequence cache is precomputed during slab object creation
>>> based up on the object size and no of objects per slab. These could
>>> be changed when flags like SLAB_STORE_USER, SLAB_POISON are updated
>>> from sysfs. So when shuffle_freelist is called during slab_alloc it
>> 
>> Sorry no. That cannot happen. Changing the size of the slab is only
>> possible if no slab pages are allocated. Any sysfs changes that affect 
>> the
>> object size must fail if object and slab pages are already allocated.
>> 
>> If you were able to change the object size then we need to prevent 
>> that
>> from happening.
>> 
> 
> Yes, size of slab can't be changed after objects are allocated, that 
> holds
> true even with this change. Let me explain a bit more about the use 
> case here
> 
> ZRAM compression uses the slub allocator, by enabling the slub debug 
> flags like
> SLAB_STORE_USER etc.. the memory consumption will rather be increased
> which doesn't
> serve the purpose of ZRAM compression. So, such flags are to be
> disabled before the
> allocations happen, this requires updation of random sequence cache as 
> object
> size and number of objects change after these flags are disabled.
> 
> So, the sequence will be
> 
> 1. Slab creation (this will set a precomputed random sequence cache)
> 2. Remove the debug flags
> 3. update the random sequence cache
> 4. Mount zram and then start using it for allocations.
> 
> Thanks,
> Vijay

Waiting for your response.

Thanks,
Vijay