From patchwork Wed Feb 21 02:16:59 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kees Cook X-Patchwork-Id: 10231165 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 988C8604D4 for ; Wed, 21 Feb 2018 02:17:19 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 89D1628ADF for ; Wed, 21 Feb 2018 02:17:19 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 7E46028AE5; Wed, 21 Feb 2018 02:17:19 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.3 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.wl.linuxfoundation.org (Postfix) with SMTP id AAFA928ADF for ; Wed, 21 Feb 2018 02:17:18 +0000 (UTC) Received: (qmail 18310 invoked by uid 550); 21 Feb 2018 02:17:15 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Delivered-To: mailing list kernel-hardening@lists.openwall.com Received: (qmail 18280 invoked from network); 21 Feb 2018 02:17:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:mime-version:content-disposition; bh=x7KYIj6+3t4FFkPjN4oH2bZkALzv0Vo0pUN9HC3J8oE=; b=GnY7wNZF+Nq6VF5mVlPGujSkkGsqxLNzfWS+f6pRKEtPvhT+lzek/7W4oWbPAgl8kx LaWQEvxtnNzl3pAYZzVSxmQ8+TOs/GBgoBN6bSOciZKPM6WnG9y9te79GDlBW2sL2Jka LiQLeMBYbneZLCcaNAwDIeDC0l7VwFzCzrfMQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition; bh=x7KYIj6+3t4FFkPjN4oH2bZkALzv0Vo0pUN9HC3J8oE=; b=ZUCpRyQNf6t1hZj6LoN63kFl8FeG6WqPx29ZYON5nhtBVDPV68la84EIIbaZbJ+Sv4 q1AvCXAXWVHctzqxwL9PvKFWckvvD0KQHmu7Diybr8hf2TAEAebrATqq5578XruHC1tl FehV4kbLkRc3fwDGBqTEhKVoiUcR8RQweKD/Fsjf83yjMDk654ozW/E9GQRrKXMzXakC tjjMNf3D/gEFUJI0S7IDzY/lFdLF1OjCmRHzDtR7SkgQYZnd7w8Gnmrp5HnpG+h/Fiv1 plhK2s+nMuuoFm7DXPKRj/Hec1CiZNCzgXLM1CwLtdGFic9RwoAccX0/bWGNEQ8pyzv7 ZJAg== X-Gm-Message-State: APf1xPDLbPjNsAjD3Nw5PYtDn4KI6swZ6OLxqgojyw4OEe00yeAwzJQW xGA3KOK0Ehojx0kM8vVjqEPZ4Q== X-Google-Smtp-Source: AH8x224025IXyAZ5kAd/ijdCXZ0eDKFiRJTBZBvUHAuYdMbQ1ldCs3Du8KAm44biewXNeifnqRlPXg== X-Received: by 10.101.90.203 with SMTP id d11mr1354698pgt.366.1519179421542; Tue, 20 Feb 2018 18:17:01 -0800 (PST) Date: Tue, 20 Feb 2018 18:16:59 -0800 From: Kees Cook To: Andrew Morton Cc: Andy Lutomirski , Laura Abbott , Michal Hocko , Rasmus Villemoes , linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com Subject: [PATCH v2] fork: Unconditionally clear stack on fork Message-ID: <20180221021659.GA37073@beast> MIME-Version: 1.0 Content-Disposition: inline X-Virus-Scanned: ClamAV using ClamSMTP One of the classes of kernel stack content leaks[1] 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. In the face of stack content exposure flaws, those contents can leak to userspace. Fixing this will make the kernel no longer vulnerable to these flaws, 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. 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 and after: Run times: 159.31 157.34 156.71 158.15 160.81 Mean: 158.46 Std Dev: 1.46 Instead of making this a build or runtime config, Andy Lutomirski recommended this just be enabled by default. [1] A noisy search for many kinds of stack content leaks can be seen here: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=linux+kernel+stack+leak Signed-off-by: Kees Cook Acked-by: Michal Hocko --- include/linux/thread_info.h | 6 +----- kernel/fork.c | 3 +-- 2 files changed, 2 insertions(+), 7 deletions(-) diff --git a/include/linux/thread_info.h b/include/linux/thread_info.h index 34f053a150a9..cf2862bd134a 100644 --- a/include/linux/thread_info.h +++ b/include/linux/thread_info.h @@ -43,11 +43,7 @@ enum { #define THREAD_ALIGN THREAD_SIZE #endif -#if IS_ENABLED(CONFIG_DEBUG_STACK_USAGE) || IS_ENABLED(CONFIG_DEBUG_KMEMLEAK) -# define THREADINFO_GFP (GFP_KERNEL_ACCOUNT | __GFP_ZERO) -#else -# define THREADINFO_GFP (GFP_KERNEL_ACCOUNT) -#endif +#define THREADINFO_GFP (GFP_KERNEL_ACCOUNT | __GFP_ZERO) /* * flag set/clear/test wrappers diff --git a/kernel/fork.c b/kernel/fork.c index be8aa5b98666..4f2ee527c7d2 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -216,10 +216,9 @@ static unsigned long *alloc_thread_stack_node(struct task_struct *tsk, int node) if (!s) continue; -#ifdef CONFIG_DEBUG_KMEMLEAK /* Clear stale pointers from reused stack. */ memset(s->addr, 0, THREAD_SIZE); -#endif + tsk->stack_vm_area = s; return s->addr; }