From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752424AbeAQJRf (ORCPT + 1 other); Wed, 17 Jan 2018 04:17:35 -0500 Received: from mx2.suse.de ([195.135.220.15]:34135 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750816AbeAQJRc (ORCPT ); Wed, 17 Jan 2018 04:17:32 -0500 Date: Wed, 17 Jan 2018 10:17:29 +0100 From: Michal Hocko To: Kees Cook Cc: Andrew Morton , Andy Lutomirski , Jann Horn , Ingo Molnar , Laura Abbott , Thomas Gleixner , Al Viro , Sahara , "Levin, Alexander (Sasha Levin)" , Andrea Arcangeli , "Kirill A. Shutemov" , linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com Subject: Re: [PATCH] fork: Allow stack to be wiped on fork Message-ID: <20180117091729.GB2900@dhcp22.suse.cz> References: <20180117055015.GA15256@beast> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180117055015.GA15256@beast> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: 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 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