From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: ARC-Seal: i=1; a=rsa-sha256; t=1522267045; cv=none; d=google.com; s=arc-20160816; b=ly4l9bwW8i2uLM/o1DLIPQeTVlD8Z2kVUOQ657ej5G57R8x/Csz2p/Ap8Ewenrziny ZKol29KPmcf5+JVWQx79sO4fl7+6fAjFetBrEktpUR21ushNlyhg3xeq8x2uQDBUTT50 9AsiDTfK6Wi61kdDWH4iVbI2PWfb4eSZglMlkI4vyreYsgtnnJxiPqZSx9Gu/vZQeG6Z vAPG6fvT+g6t5Kfk8D4J2lLTI7+MtYyCfRH1cOZIqhzlcUQ08FwgRV6hWlLf+zFTq0ef lWvsUo8qalM/GDymcn7U9juDdNboSB9ah0hz5RpnpOHv+lxFb8YSkpq6ufvy3HwPFvPS LNOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=message-id:date:subject:to:from:arc-authentication-results; bh=C8wBCuAG6K1WgmurdetMv95nMwYo5Yj3y1423+WU5jU=; b=BYvC1B7Ar6XDY9U8Y+yPGSigWCufAcFzngKvjzxJndcUiJm6KoQfO5+4VeiEtwO7yB qe/hr6Ifa+7MmawXChujjz1qr9lVkezMwYkskI7aXa2wP33tJC2QPMQnCXjn/23Bi0j5 TSa/SMfQWUXLzHPXUAoEfwoCmNtFWZyeldjL74TwZBvVqCoq7YsAj9O0f5y5PCgmF8fk DCkSttNtpGeCR+tGY4WagkaT3uQLsY7uNSkCpXNeLkUJuPA20GHjOtQl0cHOJEKp3okK wDteeCTf4clL8xeKDesTtLye32FjnXnSMDvNnKCaPbzDrx8ieyBLUdMiREihPleFckFc Cyjg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of a13xp0p0v88@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=a13xp0p0v88@gmail.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of a13xp0p0v88@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=a13xp0p0v88@gmail.com X-Google-Smtp-Source: AIpwx4/IWiz19rHGp1DsX/74n7kIoK0bMu+/TcmckNE6omiSIePoeDKYtj4emxg5uFLVuX0t8hSrVg== From: Alexander Popov To: kernel-hardening@lists.openwall.com, Kees Cook , PaX Team , Brad Spengler , Ingo Molnar , Andy Lutomirski , Tycho Andersen , Laura Abbott , Mark Rutland , Ard Biesheuvel , Borislav Petkov , Richard Sandiford , Thomas Gleixner , "H . Peter Anvin" , Peter Zijlstra , "Dmitry V . Levin" , Emese Revfy , Jonathan Corbet , Andrey Ryabinin , "Kirill A . Shutemov" , Thomas Garnier , Andrew Morton , Alexei Starovoitov , Josef Bacik , Masami Hiramatsu , Nicholas Piggin , Al Viro , "David S . Miller" , Ding Tianhong , David Woodhouse , Josh Poimboeuf , Steven Rostedt , Dominik Brodowski , Juergen Gross , Greg Kroah-Hartman , Dan Williams , Dave Hansen , Mathias Krause , Vikas Shivappa , Kyle Huey , Dmitry Safonov , Will Deacon , Arnd Bergmann , Florian Weimer , Boris Lukashev , x86@kernel.org, linux-kernel@vger.kernel.org, alex.popov@linux.com Subject: [PATCH RFC v10 0/6] Introduce the STACKLEAK feature and a test for it Date: Wed, 28 Mar 2018 22:57:06 +0300 Message-Id: <1522267032-6603-1-git-send-email-alex.popov@linux.com> X-Mailer: git-send-email 2.7.4 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1596212689180490954?= X-GMAIL-MSGID: =?utf-8?q?1596212689180490954?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: This is the 10th version of the patch series introducing STACKLEAK to the mainline kernel. The previous version raised a fervent discussion[0]. The assembly code introduced by v9 irritated the reviewers. I've found the way to bypass the obstacles[1] of the C implementation. So I dare come once again. Let me ask you to look at this code without preconception. Motivation ========== STACKLEAK (initially developed by PaX Team): 1. reduces the information that can be revealed through kernel stack leak bugs. The idea of erasing the thread stack at the end of syscalls is similar to CONFIG_PAGE_POISONING and memzero_explicit() in kernel crypto, which all comply with FDP_RIP.2 (Full Residual Information Protection) of the Common Criteria standard. 2. blocks some uninitialized stack variable attacks (e.g. CVE-2017-17712, CVE-2010-2963). That kind of bugs should be killed by improving C compilers in future, which might take a long time. 3. blocks stack depth overflow caused by alloca (aka Stack Clash attack). That is orthogonal to the mainline kernel VLA cleanup and protects un-upstreamed code. Performance impact ================== Hardware: Intel Core i7-4770, 16 GB RAM Test #1: building the Linux kernel on a single core 0.91% slowdown Test #2: hackbench -s 4096 -l 2000 -g 15 -f 25 -P 4.2% slowdown So the STACKLEAK description in Kconfig includes: "The tradeoff is the performance impact: on a single CPU system kernel compilation sees a 1% slowdown, other systems and workloads may vary and you are advised to test this feature on your expected workload before deploying it". Links ===== [0] http://www.openwall.com/lists/kernel-hardening/2018/03/03/7 [1] http://www.openwall.com/lists/kernel-hardening/2018/03/21/4 Alexander Popov (6): gcc-plugins: Clean up the cgraph_create_edge* macros x86/entry: Add STACKLEAK erasing the kernel stack at the end of syscalls gcc-plugins: Add STACKLEAK plugin for tracking the kernel stack lkdtm: Add a test for STACKLEAK fs/proc: Show STACKLEAK metrics in the /proc file system doc: self-protection: Add information about STACKLEAK feature Documentation/security/self-protection.rst | 23 +- Documentation/x86/x86_64/mm.txt | 2 + arch/Kconfig | 53 ++++ arch/x86/Kconfig | 1 + arch/x86/entry/Makefile | 3 + arch/x86/entry/entry_32.S | 11 + arch/x86/entry/entry_64.S | 11 + arch/x86/entry/entry_64_compat.S | 11 + arch/x86/entry/erase.c | 58 ++++ arch/x86/include/asm/processor.h | 7 + arch/x86/kernel/dumpstack.c | 19 ++ arch/x86/kernel/process_32.c | 8 + arch/x86/kernel/process_64.c | 8 + drivers/misc/Makefile | 3 + drivers/misc/lkdtm.h | 4 + drivers/misc/lkdtm_core.c | 2 + drivers/misc/lkdtm_stackleak.c | 141 +++++++++ fs/proc/base.c | 18 ++ include/linux/compiler.h | 4 + mm/util.c | 33 ++ scripts/Makefile.gcc-plugins | 3 + scripts/gcc-plugins/gcc-common.h | 26 +- scripts/gcc-plugins/stackleak_plugin.c | 470 +++++++++++++++++++++++++++++ 23 files changed, 900 insertions(+), 19 deletions(-) create mode 100644 arch/x86/entry/erase.c create mode 100644 drivers/misc/lkdtm_stackleak.c create mode 100644 scripts/gcc-plugins/stackleak_plugin.c -- 2.7.4