linux-kernel - Re: [RFC][PATCH] mm/slub.c: Allow poisoning to use the fast path

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, 7 Aug 2017 15:00:44 -0700
From:   Laura Abbott <labbott@...hat.com>
To:     Christopher Lameter <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>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, Kees Cook <keescook@...omium.org>,
        Rik van Riel <riel@...hat.com>
Subject: Re: [RFC][PATCH] mm/slub.c: Allow poisoning to use the fast path

On 08/07/2017 11:03 AM, Christopher Lameter wrote:
> On Mon, 7 Aug 2017, Laura Abbott wrote:
> 
>>> Ok I see that the objects are initialized with poisoning and redzoning but
>>> I do not see that there is fastpath code to actually check the values
>>> before the object is reinitialized. Is that intentional or am
>>> I missing something?
>>
>> Yes, that's intentional here. I see the validation as a separate more
>> expensive feature. I had a crude patch to do some checks for testing
>> and I know Daniel Micay had an out of tree patch to do some checks
>> as well.
> 
> Ok then this patch does nothing? How does this help?

The purpose of this patch is to ensure the poisoning can happen without
too much penalty. Even if there aren't checks to abort/warn when there
is a problem, there's still value in ensuring objects are always poisoned.

Thanks,
Laura