user/sven/linux.git/scripts/gcc-plugins, branch v5.0.19

gcc-plugins: arm_ssp_per_task_plugin: Fix for older GCC < 6

2019-05-25T16:22:10Z

commit 259799ea5a9aa099a267f3b99e1f7078bbaf5c5e upstream. Use gen_rtx_set instead of gen_rtx_SET. The former is a wrapper macro that handles the difference between GCC versions implementing the latter. This fixes the following error on my system with g++ 5.4.0 as the host compiler HOSTCXX -fPIC scripts/gcc-plugins/arm_ssp_per_task_plugin.o scripts/gcc-plugins/arm_ssp_per_task_plugin.c:42:14: error: macro "gen_rtx_SET" requires 3 arguments, but only 2 given mask)), ^ scripts/gcc-plugins/arm_ssp_per_task_plugin.c: In function ‘unsigned int arm_pertask_ssp_rtl_execute()’: scripts/gcc-plugins/arm_ssp_per_task_plugin.c:39:20: error: ‘gen_rtx_SET’ was not declared in this scope emit_insn_before(gen_rtx_SET Signed-off-by: Chris Packham Fixes: 189af4657186 ("ARM: smp: add support for per-task stack canaries") Cc: stable@vger.kernel.org Tested-by: Douglas Anderson Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman

gcc-plugins: arm_ssp_per_task_plugin: fix for GCC 9+

2019-01-20T22:06:40Z

GCC 9 reworks the way the references to the stack canary are emitted, to prevent the value from being spilled to the stack before the final comparison in the epilogue, defeating the purpose, given that the spill slot is under control of the attacker that we are protecting ourselves from. Since our canary value address is obtained without accessing memory (as opposed to pre-v7 code that will obtain it from a literal pool), it is unlikely (although not guaranteed) that the compiler will spill the canary value in the same way, so let's just disable this improvement when building with GCC9+. Signed-off-by: Ard Biesheuvel Signed-off-by: Kees Cook

gcc-plugins: arm_ssp_per_task_plugin: sign extend the SP mask

2019-01-20T22:06:40Z

The ARM per-task stack protector GCC plugin hits an assert in the compiler in some case, due to the fact the the SP mask expression is not sign-extended as it should be. So fix that. Suggested-by: Kugan Vivekanandarajah Signed-off-by: Ard Biesheuvel Signed-off-by: Kees Cook

Merge tag 'gcc-plugins-v4.21-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

2018-12-27T19:19:07Z

Pull gcc-plugins update from Kees Cook: "Both arm and arm64 are gaining per-task stack canaries (to match x86), but arm is being done with a gcc plugin, hence it going through the gcc-plugins tree. New gcc-plugin: - Enable per-task stack protector for ARM (Ard Biesheuvel)" * tag 'gcc-plugins-v4.21-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: ARM: smp: add support for per-task stack canaries

ARM: smp: add support for per-task stack canaries

2018-12-12T21:20:07Z

On ARM, we currently only change the value of the stack canary when switching tasks if the kernel was built for UP. On SMP kernels, this is impossible since the stack canary value is obtained via a global symbol reference, which means a) all running tasks on all CPUs must use the same value b) we can only modify the value when no kernel stack frames are live on any CPU, which is effectively never. So instead, use a GCC plugin to add a RTL pass that replaces each reference to the address of the __stack_chk_guard symbol with an expression that produces the address of the 'stack_canary' field that is added to struct thread_info. This way, each task will use its own randomized value. Cc: Russell King Cc: Kees Cook Cc: Emese Revfy Cc: Arnd Bergmann Cc: Laura Abbott Cc: kernel-hardening@lists.openwall.com Acked-by: Nicolas Pitre Signed-off-by: Ard Biesheuvel Signed-off-by: Kees Cook

stackleak: Register the 'stackleak_cleanup' pass before the '*free_cfg' pass

2018-12-06T17:10:23Z

Currently the 'stackleak_cleanup' pass deleting a CALL insn is executed after the 'reload' pass. That allows gcc to do some weird optimization in function prologues and epilogues, which are generated later [1]. Let's avoid that by registering the 'stackleak_cleanup' pass before the '*free_cfg' pass. It's the moment when the stack frame size is already final, function prologues and epilogues are generated, and the machine-dependent code transformations are not done. [1] https://www.openwall.com/lists/kernel-hardening/2018/11/23/2 Reported-by: kbuild test robot Signed-off-by: Alexander Popov Signed-off-by: Kees Cook

stackleak: Allow runtime disabling of kernel stack erasing

2018-09-04T17:35:48Z

Introduce CONFIG_STACKLEAK_RUNTIME_DISABLE option, which provides 'stack_erasing' sysctl. It can be used in runtime to control kernel stack erasing for kernels built with CONFIG_GCC_PLUGIN_STACKLEAK. Suggested-by: Ingo Molnar Signed-off-by: Alexander Popov Tested-by: Laura Abbott Signed-off-by: Kees Cook

fs/proc: Show STACKLEAK metrics in the /proc file system

2018-09-04T17:35:48Z

Introduce CONFIG_STACKLEAK_METRICS providing STACKLEAK information about tasks via the /proc file system. In particular, /proc//stack_depth shows the maximum kernel stack consumption for the current and previous syscalls. Although this information is not precise, it can be useful for estimating the STACKLEAK performance impact for your workloads. Suggested-by: Ingo Molnar Signed-off-by: Alexander Popov Tested-by: Laura Abbott Signed-off-by: Kees Cook

gcc-plugins: Add STACKLEAK plugin for tracking the kernel stack

2018-09-04T17:35:47Z

The STACKLEAK feature erases the kernel stack before returning from syscalls. That reduces the information which kernel stack leak bugs can reveal and blocks some uninitialized stack variable attacks. This commit introduces the STACKLEAK gcc plugin. It is needed for tracking the lowest border of the kernel stack, which is important for the code erasing the used part of the kernel stack at the end of syscalls (comes in a separate commit). The STACKLEAK feature is ported from grsecurity/PaX. More information at: https://grsecurity.net/ https://pax.grsecurity.net/ This code is modified from Brad Spengler/PaX Team's code in the last public patch of grsecurity/PaX based on our understanding of the code. Changes or omissions from the original code are ours and don't reflect the original grsecurity/PaX code. Signed-off-by: Alexander Popov Tested-by: Laura Abbott Signed-off-by: Kees Cook

x86/entry: Add STACKLEAK erasing the kernel stack at the end of syscalls

2018-09-04T17:35:47Z

The STACKLEAK feature (initially developed by PaX Team) has the following benefits: 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. This commit introduces the code filling the used part of the kernel stack with a poison value before returning to userspace. Full STACKLEAK feature also contains the gcc plugin which comes in a separate commit. The STACKLEAK feature is ported from grsecurity/PaX. More information at: https://grsecurity.net/ https://pax.grsecurity.net/ This code is modified from Brad Spengler/PaX Team's code in the last public patch of grsecurity/PaX based on our understanding of the code. Changes or omissions from the original code are ours and don't reflect the original grsecurity/PaX 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". Signed-off-by: Alexander Popov Acked-by: Thomas Gleixner Reviewed-by: Dave Hansen Acked-by: Ingo Molnar Signed-off-by: Kees Cook