From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: ACJfBoudlSdCCRN4CDBzGQvno9Y7cXLnOILur+OH1IOmGkAUT5GpfC9yRxg0ludF+/4Lvd3YLhyK ARC-Seal: i=1; a=rsa-sha256; t=1516389386; cv=none; d=google.com; s=arc-20160816; b=CBTLbSEn65AR+rbqTP5ptHJREWiO/EM7fMiFnzdFuqN3uf1PiDQW3YjyvId13du4MH fsn7sfHLDuoIoQUZM9y9lloUhQv1zTEvu3B/HUEA2LXTJ3T+4m0wFnGq35dyhDNKvEmE 45xI3wcOC/DVCsOQRMsRAk5YTIGUhg9BhsuZuY/9ZDvRXAn8k43jOp7PUk9LL6ZnXLz7 qZdH/u8SnuZrJ5SqDCkApz2qXCHXw/EVn+2axe/GeXrH/K3x9SetBt6ZGo0PN6kushqV kfKLvZdml3oVBXF2qlVYiwaeYlhqm+IGXWw5sqUpJx2WAN9tzVdYUhf2J64361kcdFFu z84w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=subject:content-transfer-encoding:content-language:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :delivered-to:list-id:list-subscribe:list-unsubscribe:list-help :list-post:precedence:mailing-list:arc-authentication-results; bh=Qyem+ClXWfVFqPUBmcTnt/sMrYJtX7aD2njvc6Wu/9s=; b=FIozXGHzxa1oKDskxh3Vc5s3cAk6pdCLVyOsDMsA0wbipy+O9ZvbjNTdwwH/YJmOUu 1pClIrgJp2xh3CjbmtxSwxJfGAvmEUJbkA0hJXSFhSmhSHo/rCoAaZji9NUJ/0lUDG5l rAKWGaawgghSoLQam6KqXjfCfCaB6jS3NalFE38ffLyu6kF9DZUXze85fQos2Ehe9xvf Sv5KTfPTlzhVHuMsRKHzW6ccnVvg4SOqsFNjtH1QCtHGOnzznxjjc70UKWPlhEs1AArm Pf0FgZ4kPGzcj7nACyDMHd9+fD9hTegy5h6MRlnzDjPElNqDOBCAQJwr0i9nItj+JSGY BFZw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of kernel-hardening-return-11356-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11356-gregkh=linuxfoundation.org@lists.openwall.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of kernel-hardening-return-11356-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11356-gregkh=linuxfoundation.org@lists.openwall.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: To: Michal Hocko , Kees Cook Cc: Andrew Morton , Andy Lutomirski , Jann Horn , Ingo Molnar , Thomas Gleixner , Al Viro , Sahara , "Levin, Alexander (Sasha Levin)" , Andrea Arcangeli , "Kirill A. Shutemov" , linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com References: <20180117055015.GA15256@beast> <20180117091729.GB2900@dhcp22.suse.cz> From: Laura Abbott Message-ID: Date: Fri, 19 Jan 2018 11:16:04 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180117091729.GB2900@dhcp22.suse.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: [kernel-hardening] Re: [PATCH] fork: Allow stack to be wiped on fork X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1589817624643319879?= X-GMAIL-MSGID: =?utf-8?q?1590049517424892830?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On 01/17/2018 01:17 AM, Michal Hocko wrote: > 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. > I tried /bin/true in a loop in my QEMU setup and didn't see a difference there. >> 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. > Agreed this could use a few more words, but it looks good to me overall. Thanks, Laura