linux-kernel - Re: [PATCH 1/3] ipc: convert ipc_namespace.count from atomic_t to refcount

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 19 Jul 2017 17:32:10 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Davidlohr Bueso <dave@...olabs.net>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Elena Reshetova <elena.reshetova@...el.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Ingo Molnar <mingo@...hat.com>,
        Alexey Dobriyan <adobriyan@...il.com>,
        "Serge E. Hallyn" <serge@...lyn.com>, arozansk@...hat.com,
        Hans Liljestrand <ishkamiel@...il.com>,
        David Windsor <dwindsor@...il.com>
Subject: Re: [PATCH 1/3] ipc: convert ipc_namespace.count from atomic_t to refcount_t

On Wed, Jul 19, 2017 at 4:20 PM, Kees Cook <keescook@...omium.org> wrote:
> On Wed, Jul 19, 2017 at 4:11 PM, Davidlohr Bueso <dave@...olabs.net> wrote:
>> May I suggest using mmtests with the following config file:
>>
>> https://github.com/gormanm/mmtests/blob/7e070a810bc0af92e592e5121d0ea75fada51aeb/configs/config-global-dhp__workload-ipc-scale-short
>>
>> It will run two of Manfred's ipcscale sem benchmarks.
>
> I'll see if I can figure out how to use this for testing the fast
> refcount protection:
> https://lkml.org/lkml/2017/7/18/1223
>
> Then we could see:
>
> before conversion
> after conversion
> with CONFIG_REFCOUNT_FULL
> with fast refcount protection

I have no idea how to read this report. It seems to be mostly noise
(multiple baseline runs seem to show greater variability than compared
against the other possible results).

Test runs were atomic_t, atomic_t-2, refcount_t, refcount-full, and
refcount-fast. (Two baselines, refcount_t conversion, with FULL, and
with the fast implementation.) Output here:
http://pastebin.ubuntu.com/25129382/

-Kees

-- 
Kees Cook
Pixel Security