[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 9 May 2019 18:43:21 +0200
From: Alexander Potapenko <glider@...gle.com>
To: Kees Cook <keescook@...omium.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Christoph Lameter <cl@...ux.com>,
Laura Abbott <labbott@...hat.com>, Linux-MM <linux-mm@...ck.org>,
linux-security-module <linux-security-module@...r.kernel.org>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>,
Masahiro Yamada <yamada.masahiro@...ionext.com>, James Morris <jmorris@...ei.org>,
"Serge E. Hallyn" <serge@...lyn.com>, Nick Desaulniers <ndesaulniers@...gle.com>,
Kostya Serebryany <kcc@...gle.com>, Dmitry Vyukov <dvyukov@...gle.com>, Sandeep Patil <sspatil@...roid.com>,
Randy Dunlap <rdunlap@...radead.org>, Jann Horn <jannh@...gle.com>,
Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH 1/4] mm: security: introduce init_on_alloc=1 and
init_on_free=1 boot options
From: Kees Cook <keescook@...omium.org>
Date: Wed, May 8, 2019 at 9:02 PM
To: Alexander Potapenko
Cc: Andrew Morton, Christoph Lameter, Kees Cook, Laura Abbott,
Linux-MM, linux-security-module, Kernel Hardening, Masahiro Yamada,
James Morris, Serge E. Hallyn, Nick Desaulniers, Kostya Serebryany,
Dmitry Vyukov, Sandeep Patil, Randy Dunlap, Jann Horn, Mark Rutland
> On Wed, May 8, 2019 at 8:38 AM Alexander Potapenko <glider@...gle.com> wrote:
> > The new options are needed to prevent possible information leaks and
> > make control-flow bugs that depend on uninitialized values more
> > deterministic.
>
> I like having this available on both alloc and free. This makes it
> much more configurable for the end users who can adapt to their work
> loads, etc.
>
> > Linux build with -j12, init_on_free=1: +24.42% sys time (st.err 0.52%)
> > [...]
> > Linux build with -j12, init_on_alloc=1: +0.57% sys time (st.err 0.40%)
>
> Any idea why there is such a massive difference here? This seems to
> high just for cache-locality effects of touching all the freed pages.
I've measured a single `make -j12` again under perf stat.
The numbers for init_on_alloc=1 were:
4936513177 cache-misses # 8.056 % of all
cache refs (44.44%)
61278262461 cache-references
(44.45%)
42844784 page-faults
1449630221347 L1-dcache-loads
(44.45%)
50569965485 L1-dcache-load-misses # 3.49% of all
L1-dcache hits (44.44%)
299987258588 L1-icache-load-misses
(44.44%)
1449857258648 dTLB-loads
(44.45%)
826292490 dTLB-load-misses # 0.06% of all
dTLB cache hits (44.44%)
22028472701 iTLB-loads
(44.44%)
858451905 iTLB-load-misses # 3.90% of all
iTLB cache hits (44.45%)
162.120107145 seconds time elapsed
, and for init_on_free=1:
6666716777 cache-misses # 10.862 % of all
cache refs (44.45%)
61378258434 cache-references
(44.46%)
42850913 page-faults
1449986416063 L1-dcache-loads
(44.45%)
51277338771 L1-dcache-load-misses # 3.54% of all
L1-dcache hits (44.45%)
298295905805 L1-icache-load-misses
(44.44%)
1450378031344 dTLB-loads
(44.43%)
807011341 dTLB-load-misses # 0.06% of all
dTLB cache hits (44.44%)
22044976638 iTLB-loads
(44.44%)
846377845 iTLB-load-misses # 3.84% of all
iTLB cache hits (44.45%)
164.427054893 seconds time elapsed
(note that we don't see the speed difference under perf)
init_on_free=1 causes 1.73B more cache misses than init_on_alloc=1.
If I'm understanding correctly, a cache miss costs 12-14 cycles on my
3GHz Skylake CPU, which can explain explain a 7-8-second difference
between the two modes.
But as I just realized this is both kernel and userspace, so while the
difference is almost correct for wall time (120s for init_on_alloc,
130s for init_on_free) this doesn't tell much about the time spent in
the kernel.
> --
> Kees Cook
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
