From patchwork Wed Jan 17 05:50:15 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kees Cook X-Patchwork-Id: 10168535 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 DA88C601E7 for ; Wed, 17 Jan 2018 05:50:33 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BC09D26E3C for ; Wed, 17 Jan 2018 05:50:33 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id AD39026E97; Wed, 17 Jan 2018 05:50:33 +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.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,T_DKIM_INVALID 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 A484626E3C for ; Wed, 17 Jan 2018 05:50:32 +0000 (UTC) Received: (qmail 24573 invoked by uid 550); 17 Jan 2018 05:50:30 -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 24545 invoked from network); 17 Jan 2018 05:50:29 -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=ol5AN9727YrZSNVuTLzJKo4qxME/1Lnt4CGuDVZaE7c=; b=XYDduO6wLRFQYNzqrHF8gllBWLfPbA0SYEpfxC7v3G2Ra/LMcw4KppB+/7sOAUdyhG n6JPsr2sBTBE6zh/8OvJRUqPcCbdcOlOQEpcqlJfUhYvHi17CYf82Cn0Gm5l9rcadhjJ QodV5P8DqZ7wv0F6Lx4iqP4Lewrsg1h3Gwa5Y= 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=ol5AN9727YrZSNVuTLzJKo4qxME/1Lnt4CGuDVZaE7c=; b=VU/RHZTrTHdGyYLtucd9ly4FAM5GlCSbd6aWDQmERIheb1TZD/kTH/7H8qSgOFheIv t93tjvh8U67U2unuqjrEDVI/maUwpUfCPyZ8vFWZxAlf2NoVn0vbhzJ6VK8FgmZu7/M1 yZsvd8Pll1QVhMmZ4S1qknSiLI0Vkg63mYCwoE2QcbZTJ9chk1RJbA0UF6ET5DyAHL2E y1AmX4UIgKmZCPM5IKMn12Pjnm4QOU1ai+U0EhZnv6ytECItiGT5Gbr248pH3a3cd0JE gp9fsdu9VI3NKe7AF3jN0z7gwBuTCbDDquIXgtBkWXKXJJrgKlfMxY0msb/Ojf+BUdfs 2pMw== X-Gm-Message-State: AKGB3mKtSpEQoSFh1JKpRQWj4XNm8iw6HQaFN1PYnGnkleCxoTTEItGl dAs0voRSGfUZC0IQkDcnwXUWkg== X-Google-Smtp-Source: ACJfBot5up0ePVeRgKTtWmtM1EC7mehmFJESkM3AWIwsGU8SqiRembPxODfO+wjI25DQrmXr+AE2eA== X-Received: by 10.99.126.22 with SMTP id z22mr27955016pgc.231.1516168217894; Tue, 16 Jan 2018 21:50:17 -0800 (PST) Date: Tue, 16 Jan 2018 21:50:15 -0800 From: Kees Cook To: Andrew Morton Cc: Andy Lutomirski , Jann Horn , Ingo Molnar , Laura Abbott , Thomas Gleixner , Al Viro , Sahara , "Levin, Alexander (Sasha Levin)" , Michal Hocko , Andrea Arcangeli , "Kirill A. Shutemov" , linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com Message-ID: <20180117055015.GA15256@beast> MIME-Version: 1.0 Content-Disposition: inline Subject: [kernel-hardening] [PATCH] fork: Allow stack to be wiped on fork X-Virus-Scanned: ClamAV using ClamSMTP 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. 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 --- arch/Kconfig | 8 ++++++++ include/linux/thread_info.h | 4 +++- kernel/fork.c | 2 +- 3 files changed, 12 insertions(+), 2 deletions(-) diff --git a/arch/Kconfig b/arch/Kconfig index 400b9e1b2f27..42d56dad03ec 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -904,6 +904,14 @@ config VMAP_STACK the stack to map directly to the KASAN shadow map using a formula that is incorrect if the stack is in vmalloc space. +config CLEAR_STACK_FORK + bool "Clear the kernel stack at each fork" + help + To resist stack content leak flaws, this clears newly allocated + kernel stacks to keep previously freed heap or stack contents + from being present in the new stack. This has almost no + measurable performance impact. + config ARCH_OPTIONAL_KERNEL_RWX def_bool n diff --git a/include/linux/thread_info.h b/include/linux/thread_info.h index 34f053a150a9..091f53fe31cc 100644 --- a/include/linux/thread_info.h +++ b/include/linux/thread_info.h @@ -43,7 +43,9 @@ enum { #define THREAD_ALIGN THREAD_SIZE #endif -#if IS_ENABLED(CONFIG_DEBUG_STACK_USAGE) || IS_ENABLED(CONFIG_DEBUG_KMEMLEAK) +#if IS_ENABLED(CONFIG_DEBUG_STACK_USAGE) || \ + IS_ENABLED(CONFIG_DEBUG_KMEMLEAK) || \ + IS_ENABLED(CONFIG_CLEAR_STACK_FORK) # define THREADINFO_GFP (GFP_KERNEL_ACCOUNT | __GFP_ZERO) #else # define THREADINFO_GFP (GFP_KERNEL_ACCOUNT) diff --git a/kernel/fork.c b/kernel/fork.c index 2295fc69717f..215b1ce2b2cd 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -215,7 +215,7 @@ static unsigned long *alloc_thread_stack_node(struct task_struct *tsk, int node) if (!s) continue; -#ifdef CONFIG_DEBUG_KMEMLEAK +#if IS_ENABLED(CONFIG_DEBUG_KMEMLEAK) || IS_ENABLED(CONFIG_CLEAR_STACK_FORK) /* Clear stale pointers from reused stack. */ memset(s->addr, 0, THREAD_SIZE); #endif