From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: ARC-Seal: i=1; a=rsa-sha256; t=1523024574; cv=none; d=google.com; s=arc-20160816; b=DwciUbC07GblIoy4RJXLtKB1ZgQHGRq0bzSAP3hws6YB+Z0gvGaI8LG5ZzuOnEbkCF 3sBZTuDwVPr9BilzREqFhlDJIKE3sI+mo1yxEJMM6YEUN4MInQnbV1lHQw0Ys5VGV885 eVMAcbD/SXTzGnFvRcnU579IK2ox3DCGfNDllAguUW6jh5WcTWoyHssRy/LDBfY0MIOP eyD551AreWZ8JyWBVTN9JKm/zz+2cpX5saYYB8QMJxjd0zNA+OIX58S2Th57jHd2Bp1J IkvB1U3NxHjXsliqzF5PfCBoYl77phMx9N3ZWu5IV+3K7YpvLeKwaI2bNVOvvfgkC6Lm Oa/A== 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=YgsuI70+8iNQcgm4CvG+KiYnwp1aQa3aNbnf6rQqrlQ=; b=Aporh1fANtnmVsx2IY56U3ZJV9CbZLPoYc2SszbbGP4/YooPXjVWL8no1nDLXy71by kRIUoIxHMd4QSD8lWSZXVgpXWaHLtEsbUZZ8uAqwzIlQGU1UuLgoe58ADwpNUi4pqaE/ dFxU3W/vwJmlEs5scnX8CyKz0VBeU5JThvRALp4275bn2BoH90Dgp8/rE6e4MqjsCNlL DIfp8hxnGTHhvuoVuOlScqLnjU7PbpnR64IfBwCaADFElCho2qspeTaxOet++6XavEI/ 8OIcv+8b4FCP9MN9wG2Fd0YoMPBaIvH6SjI/IaPCDz2qep/+t/XlymCupTyzFGvr/qQ4 yHXg== 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/5ZKPBr8FSEhIMIHRI8VKKJXtJJrspSL877cAZAjttAtwMnleJ1G6Gov3Iq6iLKOz7L5df4Q== 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 , Linus Torvalds , 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 v11 0/6] Introduce the STACKLEAK feature and a test for it Date: Fri, 6 Apr 2018 17:22:20 +0300 Message-Id: <1523024546-6150-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?1597007016485998750?= X-GMAIL-MSGID: =?utf-8?q?1597007016485998750?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: This is the 11th version of the patch series introducing STACKLEAK to the mainline kernel. The 9th version raised a fervent discussion[0]. The assembly code introduced by that version irritated the reviewers. I've found the way to bypass the obstacles[1] of the C implementation. So I dare come 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/calling.h | 14 + arch/x86/entry/entry_32.S | 7 + arch/x86/entry/entry_64.S | 3 + arch/x86/entry/entry_64_compat.S | 5 + 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 +++++++++++++++++++++++++++++ 24 files changed, 896 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