linux-kernel - Re: [PATCH 0/3] gcc-plugins: Introduce stackinit plugin

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:   Tue, 29 Jan 2019 03:12:24 +0300
From:   Alexander Popov <alex.popov@...ux.com>
To:     Kees Cook <keescook@...omium.org>, linux-kernel@...r.kernel.org
Cc:     Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Laura Abbott <labbott@...hat.com>,
        xen-devel@...ts.xenproject.org, dri-devel@...ts.freedesktop.org,
        intel-gfx@...ts.freedesktop.org, intel-wired-lan@...ts.osuosl.org,
        netdev@...r.kernel.org, linux-usb@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
        dev@...nvswitch.org, linux-kbuild@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        kernel-hardening@...ts.openwall.com,
        Greg KH <gregkh@...uxfoundation.org>,
        Jann Horn <jannh@...gle.com>,
        William Kucharski <william.kucharski@...cle.com>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        Edwin Zimmerman <edwin@...mainstreet.net>,
        Matthew Wilcox <willy@...radead.org>,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Subject: Re: [PATCH 0/3] gcc-plugins: Introduce stackinit plugin

On 23.01.2019 14:03, Kees Cook wrote:
> This adds a new plugin "stackinit" that attempts to perform unconditional
> initialization of all stack variables

Hello Kees! Hello everyone!

I was curious about the performance impact of the initialization of all stack
variables. So I did a very brief test with this plugin on top of 4.20.5.

hackbench on Intel Core i7-4770 showed ~0.7% slowdown.
hackbench on Kirin 620 (ARM Cortex-A53 Octa-core 1.2GHz) showed ~1.3% slowdown.

This test involves the kernel scheduler and allocator. I can't say whether they
use stack aggressively. Maybe performance tests of other subsystems (e.g.
network subsystem) can show different numbers. Did you try?

I've heard a hypothesis that the initialization of all stack variables would
pollute CPU caches, which is critical for some types of computations. Maybe some
micro-benchmarks can disprove/confirm that?

Thanks!
Best regards,
Alexander