[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180117091729.GB2900@dhcp22.suse.cz>
Date: Wed, 17 Jan 2018 10:17:29 +0100
From: Michal Hocko <mhocko@...nel.org>
To: Kees Cook <keescook@...omium.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Andy Lutomirski <luto@...nel.org>, Jann Horn <jannh@...gle.com>,
Ingo Molnar <mingo@...nel.org>, Laura Abbott <labbott@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Al Viro <viro@...iv.linux.org.uk>,
Sahara <keun-o.park@...kmatter.ae>,
"Levin, Alexander (Sasha Levin)" <alexander.levin@...izon.com>,
Andrea Arcangeli <aarcange@...hat.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH] fork: Allow stack to be wiped on fork
On Tue 16-01-18 21:50:15, Kees Cook wrote:
> One of the classes of kernel stack content leaks is exposing the contents
> of prior heap or stack contents when a new process stack is allocated.
> Normally, those stacks are not zeroed, and the old contents remain in
> place. With some types of stack content exposure flaws, those contents
> can leak to userspace. Kernels built with CONFIG_CLEAR_STACK_FORK will
> no longer be vulnerable to this, as the stack will be wiped each time
> a stack is assigned to a new process. There's not a meaningful change
> in runtime performance; it almost looks like it provides a benefit.
Have you tried something as simple as /bin/true in a loop. kbuild will
certainly amortize few cycles for the clearing and I would expect, most
reasonable applications would do as well. But it would be better to know
the worst case scenario IMHO.
> Performing back-to-back kernel builds before:
> Run times: 157.86 157.09 158.90 160.94 160.80
> Mean: 159.12
> Std Dev: 1.54
>
> With CONFIG_CLEAR_STACK_FORK=y:
> Run times: 159.31 157.34 156.71 158.15 160.81
> Mean: 158.46
> Std Dev: 1.46
>
> Signed-off-by: Kees Cook <keescook@...omium.org>
The change seems reasonable to me. Although it would be better to extend
on the types of attacks this prevents from, with some examples ideally.
How many attacks of that kind we had in the past and how often they
appear. That might help people to decide whether to deserve few cycles
on each fork. Also the config option sounds rather limiting. Consider
distros, should they enable it just to be on the safe side? This is kind
of generic concern with other hardening options though.
--
Michal Hocko
SUSE Labs
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.
