summaryrefslogtreecommitdiff
path: root/scripts/gcc-plugins
AgeCommit message (Collapse)AuthorFilesLines
2020-08-10Merge tag 'kbuild-v5.9' of ↵Linus Torvalds1-11/+50
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild updates from Masahiro Yamada: - run the checker (e.g. sparse) after the compiler - remove unneeded cc-option tests for old compiler flags - fix tar-pkg to install dtbs - introduce ccflags-remove-y and asflags-remove-y syntax - allow to trace functions in sub-directories of lib/ - introduce hostprogs-always-y and userprogs-always-y syntax - various Makefile cleanups * tag 'kbuild-v5.9' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kbuild: stop filtering out $(GCC_PLUGINS_CFLAGS) from cc-option base kbuild: include scripts/Makefile.* only when relevant CONFIG is enabled kbuild: introduce hostprogs-always-y and userprogs-always-y kbuild: sort hostprogs before passing it to ifneq kbuild: move host .so build rules to scripts/gcc-plugins/Makefile kbuild: Replace HTTP links with HTTPS ones kbuild: trace functions in subdirectories of lib/ kbuild: introduce ccflags-remove-y and asflags-remove-y kbuild: do not export LDFLAGS_vmlinux kbuild: always create directories of targets powerpc/boot: add DTB to 'targets' kbuild: buildtar: add dtbs support kbuild: remove cc-option test of -ffreestanding kbuild: remove cc-option test of -fno-stack-protector Revert "kbuild: Create directory for target DTB" kbuild: run the checker after the compiler
2020-08-09kbuild: move host .so build rules to scripts/gcc-plugins/MakefileMasahiro Yamada1-11/+50
The host shared library rules are currently implemented in scripts/Makefile.host, but actually GCC-plugin is the only user of them. (The VDSO .so files are built for the target by different build rules) Hence, they do not need to be treewide available. Move all the relevant build rules to scripts/gcc-plugins/Makefile. I also optimized the build steps so *.so is directly built from .c because every upstream plugin is compiled from a single source file. I am still keeping the multi-file plugin support, which Kees Cook mentioned might be needed by out-of-tree plugins. (https://lkml.org/lkml/2019/1/11/1107) If the plugin, foo.so, is compiled from two files foo.c and foo2.c, then you can do like follows: foo-objs := foo.o foo2.o Single-file plugins do not need the *-objs notation. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Kees Cook <keescook@chromium.org>
2020-08-04Merge tag 'gcc-plugins-v5.9-rc1' of ↵Linus Torvalds4-34/+220
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull gcc plugin updates from Kees Cook: "Primarily improvements to STACKLEAK from Alexander Popov, along with some additional cleanups. - Update URLs for HTTPS scheme where available (Alexander A. Klimov) - Improve STACKLEAK code generation on x86 (Alexander Popov)" * tag 'gcc-plugins-v5.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: gcc-plugins: Replace HTTP links with HTTPS ones gcc-plugins/stackleak: Add 'verbose' plugin parameter gcc-plugins/stackleak: Use asm instrumentation to avoid useless register saving ARM: vdso: Don't use gcc plugins for building vgettimeofday.c gcc-plugins/stackleak: Don't instrument itself
2020-07-13gcc-plugins: Replace HTTP links with HTTPS onesAlexander A. Klimov3-3/+3
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de> Link: https://lore.kernel.org/r/20200713135018.34708-1-grandmaster@al2klimov.de Signed-off-by: Kees Cook <keescook@chromium.org>
2020-06-28gcc-plugins: fix gcc-plugins directory path in documentationMasahiro Yamada1-1/+1
Fix typos "plgins" -> "plugins". Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Kees Cook <keescook@chromium.org>
2020-06-24gcc-plugins/stackleak: Add 'verbose' plugin parameterAlexander Popov1-5/+42
Add 'verbose' plugin parameter for stackleak gcc plugin. It can be used for printing additional info about the kernel code instrumentation. For using it add the following to scripts/Makefile.gcc-plugins: gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STACKLEAK) \ += -fplugin-arg-stackleak_plugin-verbose Signed-off-by: Alexander Popov <alex.popov@linux.com> Link: https://lore.kernel.org/r/20200624123330.83226-6-alex.popov@linux.com Signed-off-by: Kees Cook <keescook@chromium.org>
2020-06-24gcc-plugins/stackleak: Use asm instrumentation to avoid useless register savingAlexander Popov1-28/+177
The kernel code instrumentation in stackleak gcc plugin works in two stages. At first, stack tracking is added to GIMPLE representation of every function (except some special cases). And later, when stack frame size info is available, stack tracking is removed from the RTL representation of the functions with small stack frame. There is an unwanted side-effect for these functions: some of them do useless work with caller-saved registers. As an example of such case, proc_sys_write without() instrumentation: 55 push %rbp 41 b8 01 00 00 00 mov $0x1,%r8d 48 89 e5 mov %rsp,%rbp e8 11 ff ff ff callq ffffffff81284610 <proc_sys_call_handler> 5d pop %rbp c3 retq 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) 00 00 00 proc_sys_write() with instrumentation: 55 push %rbp 48 89 e5 mov %rsp,%rbp 41 56 push %r14 41 55 push %r13 41 54 push %r12 53 push %rbx 49 89 f4 mov %rsi,%r12 48 89 fb mov %rdi,%rbx 49 89 d5 mov %rdx,%r13 49 89 ce mov %rcx,%r14 4c 89 f1 mov %r14,%rcx 4c 89 ea mov %r13,%rdx 4c 89 e6 mov %r12,%rsi 48 89 df mov %rbx,%rdi 41 b8 01 00 00 00 mov $0x1,%r8d e8 f2 fe ff ff callq ffffffff81298e80 <proc_sys_call_handler> 5b pop %rbx 41 5c pop %r12 41 5d pop %r13 41 5e pop %r14 5d pop %rbp c3 retq 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1) 00 00 Let's improve the instrumentation to avoid this: 1. Make stackleak_track_stack() save all register that it works with. Use no_caller_saved_registers attribute for that function. This attribute is available for x86_64 and i386 starting from gcc-7. 2. Insert calling stackleak_track_stack() in asm: asm volatile("call stackleak_track_stack" :: "r" (current_stack_pointer)) Here we use ASM_CALL_CONSTRAINT trick from arch/x86/include/asm/asm.h. The input constraint is taken into account during gcc shrink-wrapping optimization. It is needed to be sure that stackleak_track_stack() call is inserted after the prologue of the containing function, when the stack frame is prepared. This work is a deep reengineering of the idea described on grsecurity blog https://grsecurity.net/resolving_an_unfortunate_stackleak_interaction Signed-off-by: Alexander Popov <alex.popov@linux.com> Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Link: https://lore.kernel.org/r/20200624123330.83226-5-alex.popov@linux.com Signed-off-by: Kees Cook <keescook@chromium.org>
2020-06-11Merge branch 'rwonce/rework' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux Pull READ/WRITE_ONCE rework from Will Deacon: "This the READ_ONCE rework I've been working on for a while, which bumps the minimum GCC version and improves code-gen on arm64 when stack protector is enabled" [ Side note: I'm _really_ tempted to raise the minimum gcc version to 4.9, so that we can just say that we require _Generic() support. That would allow us to more cleanly handle a lot of the cases where we depend on very complex macros with 'sizeof' or __builtin_choose_expr() with __builtin_types_compatible_p() etc. This branch has a workaround for sparse not handling _Generic(), either, but that was already fixed in the sparse development branch, so it's really just gcc-4.9 that we'd require. - Linus ] * 'rwonce/rework' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux: compiler_types.h: Use unoptimized __unqual_scalar_typeof for sparse compiler_types.h: Optimize __unqual_scalar_typeof compilation time compiler.h: Enforce that READ_ONCE_NOCHECK() access size is sizeof(long) compiler-types.h: Include naked type in __pick_integer_type() match READ_ONCE: Fix comment describing 2x32-bit atomicity gcov: Remove old GCC 3.4 support arm64: barrier: Use '__unqual_scalar_typeof' for acquire/release macros locking/barriers: Use '__unqual_scalar_typeof' for load-acquire macros READ_ONCE: Drop pointer qualifiers when reading from scalar types READ_ONCE: Enforce atomicity for {READ,WRITE}_ONCE() memory accesses READ_ONCE: Simplify implementations of {READ,WRITE}_ONCE() arm64: csum: Disable KASAN for do_csum() fault_inject: Don't rely on "return value" from WRITE_ONCE() net: tls: Avoid assigning 'const' pointer to non-const pointer netfilter: Avoid assigning 'const' pointer to non-const pointer compiler/gcc: Raise minimum GCC version for kernel builds to 4.8
2020-05-25gcc-plugins: remove always-false $(if ...) in MakefileMasahiro Yamada1-1/+1
This is the remnant of commit c17d6179ad5a ("gcc-plugins: remove unused GCC_PLUGIN_SUBDIR"). The conditional $(if $(findstring /,$(p)),...) is always false because none of plugins contains '/' in the file name. Clean up the code. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org>
2020-04-15compiler/gcc: Raise minimum GCC version for kernel builds to 4.8Will Deacon1-1/+1
It is very rare to see versions of GCC prior to 4.8 being used to build the mainline kernel. These old compilers are also know to have codegen issues which can lead to silent miscompilation: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 Raise the minimum GCC version for kernel build to 4.8 and remove some tautological Kconfig dependencies as a consequence. Cc: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Will Deacon <will@kernel.org>
2020-04-13gcc-common.h: Update for GCC 10Frédéric Pierret (fepitre)2-0/+5
Remove "params.h" include, which has been dropped in GCC 10. Remove is_a_helper() macro, which is now defined in gimple.h, as seen when running './scripts/gcc-plugin.sh g++ g++ gcc': In file included from <stdin>:1: ./gcc-plugins/gcc-common.h:852:13: error: redefinition of ‘static bool is_a_helper<T>::test(U*) [with U = const gimple; T = const ggoto*]’ 852 | inline bool is_a_helper<const ggoto *>::test(const_gimple gs) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from ./gcc-plugins/gcc-common.h:125, from <stdin>:1: /usr/lib/gcc/x86_64-redhat-linux/10/plugin/include/gimple.h:1037:1: note: ‘static bool is_a_helper<T>::test(U*) [with U = const gimple; T = const ggoto*]’ previously declared here 1037 | is_a_helper <const ggoto *>::test (const gimple *gs) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ Add -Wno-format-diag to scripts/gcc-plugins/Makefile to avoid meaningless warnings from error() formats used by plugins: scripts/gcc-plugins/structleak_plugin.c: In function ‘int plugin_init(plugin_name_args*, plugin_gcc_version*)’: scripts/gcc-plugins/structleak_plugin.c:253:12: warning: unquoted sequence of 2 consecutive punctuation characters ‘'-’ in format [-Wformat-diag] 253 | error(G_("unknown option '-fplugin-arg-%s-%s'"), plugin_name, argv[i].key); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Frédéric Pierret (fepitre) <frederic.pierret@qubes-os.org> Link: https://lore.kernel.org/r/20200407113259.270172-1-frederic.pierret@qubes-os.org [kees: include -Wno-format-diag for plugin builds] Signed-off-by: Kees Cook <keescook@chromium.org>
2020-04-13gcc-plugins/stackleak: Avoid assignment for unused macro argumentKees Cook1-3/+2
With GCC version >= 8, the cgraph_create_edge() macro argument using "frequency" goes unused. Instead of assigning a temporary variable for the argument, pass the compute_call_stmt_bb_frequency() call directly as the macro argument so that it will just not be called when it is not wanted by the macros. Silences the warning: scripts/gcc-plugins/stackleak_plugin.c:54:6: warning: variable ‘frequency’ set but not used [-Wunused-but-set-variable] Now builds cleanly with gcc-7 and gcc-9. Both boot and pass STACKLEAK_ERASING LKDTM test. Signed-off-by: Kees Cook <keescook@chromium.org>
2020-04-08gcc-plugins: drop support for GCC <= 4.7Masahiro Yamada2-25/+8
Nobody was opposed to raising minimum GCC version to 4.8 [1] So, we will drop GCC <= 4.7 support sooner or later. We always use C++ compiler for building plugins for GCC >= 4.8. This commit drops the plugin support for GCC <= 4.7 a bit earlier, which allows us to dump lots of code. [1] https://lkml.org/lkml/2020/1/23/545 Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Kees Cook <keescook@chromium.org>
2020-04-03Merge tag 'spdx-5.7-rc1' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/spdx Pull SPDX updates from Greg KH: "Here are three SPDX patches for 5.7-rc1. One fixes up the SPDX tag for a single driver, while the other two go through the tree and add SPDX tags for all of the .gitignore files as needed. Nothing too complex, but you will get a merge conflict with your current tree, that should be trivial to handle (one file modified by two things, one file deleted.) All three of these have been in linux-next for a while, with no reported issues other than the merge conflict" * tag 'spdx-5.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/spdx: ASoC: MT6660: make spdxcheck.py happy .gitignore: add SPDX License Identifier .gitignore: remove too obvious comments
2020-04-01Merge tag 'kbuild-v5.7' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild updates from Masahiro Yamada: "Build system: - add CONFIG_UNUSED_KSYMS_WHITELIST, which will be useful to define a fixed set of export symbols for Generic Kernel Image (GKI) - allow to run 'make dt_binding_check' without .config - use full schema for checking DT examples in *.yaml files - make modpost fail for missing MODULE_IMPORT_NS(), which makes more sense because we know the produced modules are never loadable - Remove unused 'AS' variable Kconfig: - sanitize DEFCONFIG_LIST, and remove ARCH_DEFCONFIG from Kconfig files - relax the 'imply' behavior so that symbols implied by 'y' can become 'm' - make 'imply' obey 'depends on' in order to make 'imply' really weak Misc: - add documentation on building the kernel with Clang/LLVM - revive __HAVE_ARCH_STRLEN for 32bit sparc to use optimized strlen() - fix warning from deb-pkg builds when CONFIG_DEBUG_INFO=n - various script and Makefile cleanups" * tag 'kbuild-v5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (34 commits) Makefile: Update kselftest help information kbuild: deb-pkg: fix warning when CONFIG_DEBUG_INFO is unset kbuild: add outputmakefile to no-dot-config-targets kbuild: remove AS variable net: wan: wanxl: refactor the firmware rebuild rule net: wan: wanxl: use $(M68KCC) instead of $(M68KAS) for rebuilding firmware net: wan: wanxl: use allow to pass CROSS_COMPILE_M68k for rebuilding firmware kbuild: add comment about grouped target kbuild: add -Wall to KBUILD_HOSTCXXFLAGS kconfig: remove unused variable in qconf.cc sparc: revive __HAVE_ARCH_STRLEN for 32bit sparc kbuild: refactor Makefile.dtbinst more kbuild: compute the dtbs_install destination more simply Makefile: disallow data races on gcc-10 as well kconfig: make 'imply' obey the direct dependency kconfig: allow symbols implied by y to become m net: drop_monitor: use IS_REACHABLE() to guard net_dm_hw_report() modpost: return error if module is missing ns imports and MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS=n modpost: rework and consolidate logging interface kbuild: allow to run dt_binding_check without kernel configuration ...
2020-03-29kbuild: add -Wall to KBUILD_HOSTCXXFLAGSMasahiro Yamada1-1/+1
Add -Wall to catch more warnings for C++ host programs. When I submitted the previous version, the 0-day bot reported -Wc++11-compat warnings for old GCC: HOSTCXX -fPIC scripts/gcc-plugins/latent_entropy_plugin.o In file included from /usr/lib/gcc/x86_64-linux-gnu/4.8/plugin/include/tm.h:28:0, from scripts/gcc-plugins/gcc-common.h:15, from scripts/gcc-plugins/latent_entropy_plugin.c:78: /usr/lib/gcc/x86_64-linux-gnu/4.8/plugin/include/config/elfos.h:102:21: warning: C++11 requires a space between string literal and macro [-Wc++11-compat] fprintf ((FILE), "%s"HOST_WIDE_INT_PRINT_UNSIGNED"\n",\ ^ /usr/lib/gcc/x86_64-linux-gnu/4.8/plugin/include/config/elfos.h:170:24: warning: C++11 requires a space between string literal and macro [-Wc++11-compat] fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n", \ ^ In file included from /usr/lib/gcc/x86_64-linux-gnu/4.8/plugin/include/tm.h:42:0, from scripts/gcc-plugins/gcc-common.h:15, from scripts/gcc-plugins/latent_entropy_plugin.c:78: /usr/lib/gcc/x86_64-linux-gnu/4.8/plugin/include/defaults.h:126:24: warning: C++11 requires a space between string literal and macro [-Wc++11-compat] fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n", \ ^ The source of the warnings is in the plugin headers, so we have no control of it. I just suppressed them by adding -Wno-c++11-compat to scripts/gcc-plugins/Makefile. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Kees Cook <keescook@chromium.org>
2020-03-25.gitignore: add SPDX License IdentifierMasahiro Yamada1-0/+1
Add SPDX License Identifier to all .gitignore files. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-10docs: move gcc-plugins to the kbuild manualJonathan Corbet1-1/+1
Information about GCC plugins is relevant to kernel building, so move this document to the kbuild manual. Acked-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2020-02-03kbuild: rename hostprogs-y/always to hostprogs/always-yMasahiro Yamada1-1/+1
In old days, the "host-progs" syntax was used for specifying host programs. It was renamed to the current "hostprogs-y" in 2004. It is typically useful in scripts/Makefile because it allows Kbuild to selectively compile host programs based on the kernel configuration. This commit renames like follows: always -> always-y hostprogs-y -> hostprogs So, scripts/Makefile will look like this: always-$(CONFIG_BUILD_BIN2C) += ... always-$(CONFIG_KALLSYMS) += ... ... hostprogs := $(always-y) $(always-m) I think this makes more sense because a host program is always a host program, irrespective of the kernel configuration. We want to specify which ones to compile by CONFIG options, so always-y will be handier. The "always", "hostprogs-y", "hostprogs-m" will be kept for backward compatibility for a while. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-01-03gcc-plugins: make it possible to disable CONFIG_GCC_PLUGINS againArnd Bergmann1-5/+4
I noticed that randconfig builds with gcc no longer produce a lot of ccache hits, unlike with clang, and traced this back to plugins now being enabled unconditionally if they are supported. I am now working around this by adding export CCACHE_COMPILERCHECK=/usr/bin/size -A %compiler% to my top-level Makefile. This changes the heuristic that ccache uses to determine whether the plugins are the same after a 'make clean'. However, it also seems that being able to just turn off the plugins is generally useful, at least for build testing it adds noticeable overhead but does not find a lot of bugs additional bugs, and may be easier for ccache users than my workaround. Fixes: 9f671e58159a ("security: Create "kernel hardening" config area") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Masahiro Yamada <masahiroy@kernel.org> Link: https://lore.kernel.org/r/20191211133951.401933-1-arnd@arndb.de Cc: stable@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org>
2019-07-31randstruct: Check member structs in is_pure_ops_struct()Joonwon Kang1-5/+5
While no uses in the kernel triggered this case, it was possible to have a false negative where a struct contains other structs which contain only function pointers because of unreachable code in is_pure_ops_struct(). Signed-off-by: Joonwon Kang <kjw1627@gmail.com> Link: https://lore.kernel.org/r/20190727155841.GA13586@host Fixes: 313dd1b62921 ("gcc-plugins: Add the randstruct plugin") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org>
2019-07-15docs: move gcc_plugins.txt to core-api and rename to .rstMauro Carvalho Chehab1-1/+1
The gcc_plugins.txt file is already a ReST file. Move it to the core-api book while renaming it. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Acked-by: Kees Cook <keescook@chromium.org>
2019-05-31Merge tag 'gcc-plugins-v5.2-rc3' of ↵Linus Torvalds1-0/+4
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull gcc-plugins fix from Kees Cook: "Handle unusual header environment, fixing a redefined macro error under a Darwin build host" * tag 'gcc-plugins-v5.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: gcc-plugins: Fix build failures under Darwin host
2019-05-21treewide: Add SPDX license identifier - Makefile/KconfigThomas Gleixner1-0/+1
Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-20gcc-plugins: Fix build failures under Darwin hostKees Cook1-0/+4
The gcc-common.h file did not take into account certain macros that might have already been defined in the build environment. This updates the header to avoid redefining the macros, as seen on a Darwin host using gcc 4.9.2: HOSTCXX -fPIC scripts/gcc-plugins/arm_ssp_per_task_plugin.o - due to: scripts/gcc-plugins/gcc-common.h In file included from scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3:0: scripts/gcc-plugins/gcc-common.h:153:0: warning: "__unused" redefined ^ In file included from /usr/include/stdio.h:64:0, from /Users/hns/Documents/Projects/QuantumSTEP/System/Library/Frameworks/System.framework/Versions-jessie/x86_64-apple-darwin15.0.0/gcc/arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.2/plugin/include/system.h:40, from /Users/hns/Documents/Projects/QuantumSTEP/System/Library/Frameworks/System.framework/Versions-jessie/x86_64-apple-darwin15.0.0/gcc/arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.2/plugin/include/gcc-plugin.h:28, from /Users/hns/Documents/Projects/QuantumSTEP/System/Library/Frameworks/System.framework/Versions-jessie/x86_64-apple-darwin15.0.0/gcc/arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.2/plugin/include/plugin.h:23, from scripts/gcc-plugins/gcc-common.h:9, from scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3: /usr/include/sys/cdefs.h:161:0: note: this is the location of the previous definition ^ Reported-and-tested-by: "H. Nikolaus Schaller" <hns@goldelico.com> Fixes: 189af4657186 ("ARM: smp: add support for per-task stack canaries") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org>
2019-05-14Merge tag 'gcc-plugins-v5.2-rc1' of ↵Linus Torvalds1-1/+1
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull gcc plugin fix from Kees Cook: "Fix ARM stack-protector-per-task plugin build for older GCC < 6 (Chris Packham)" * tag 'gcc-plugins-v5.2-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/kees/linux: gcc-plugins: arm_ssp_per_task_plugin: Fix for older GCC < 6
2019-05-11gcc-plugins: arm_ssp_per_task_plugin: Fix for older GCC < 6Chris Packham1-1/+1
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 <chris.packham@alliedtelesis.co.nz> Fixes: 189af4657186 ("ARM: smp: add support for per-task stack canaries") Cc: stable@vger.kernel.org Tested-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2019-04-25security: Move stackleak config to Kconfig.hardeningKees Cook1-51/+0
This moves the stackleak plugin options to Kconfig.hardening's memory initialization menu. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Alexander Popov <alex.popov@linux.com> Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-04-24security: Create "kernel hardening" config areaKees Cook1-69/+6
Right now kernel hardening options are scattered around various Kconfig files. This can be a central place to collect these kinds of options going forward. This is initially populated with the memory initialization options from the gcc-plugins. Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-03-09Merge tag 'gcc-plugins-v5.1-rc1' of ↵Linus Torvalds2-22/+72
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull gcc-plugins updates from Kees Cook: "This adds additional type coverage to the existing structleak plugin and adds a large set of selftests to help evaluate stack variable zero-initialization coverage. That can be used to test whatever instrumentation might be performing zero-initialization: either with the structleak plugin or with Clang's coming "-ftrivial-auto-var-init=zero" option. Summary: - Add scalar and array initialization coverage - Refactor Kconfig to make options more clear - Add self-test module for testing automatic initialization" * tag 'gcc-plugins-v5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: lib: Introduce test_stackinit module gcc-plugins: structleak: Generalize to all variable types
2019-03-06kasan: remove use after scope bugs detection.Andrey Ryabinin1-4/+0
Use after scope bugs detector seems to be almost entirely useless for the linux kernel. It exists over two years, but I've seen only one valid bug so far [1]. And the bug was fixed before it has been reported. There were some other use-after-scope reports, but they were false-positives due to different reasons like incompatibility with structleak plugin. This feature significantly increases stack usage, especially with GCC < 9 version, and causes a 32K stack overflow. It probably adds performance penalty too. Given all that, let's remove use-after-scope detector entirely. While preparing this patch I've noticed that we mistakenly enable use-after-scope detection for clang compiler regardless of CONFIG_KASAN_EXTRA setting. This is also fixed now. [1] http://lkml.kernel.org/r/<20171129052106.rhgbjhhis53hkgfn@wfg-t540p.sh.intel.com> Link: http://lkml.kernel.org/r/20190111185842.13978-1-aryabinin@virtuozzo.com Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Acked-by: Will Deacon <will.deacon@arm.com> [arm64] Cc: Qian Cai <cai@lca.pw> Cc: Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-03-04gcc-plugins: structleak: Generalize to all variable typesKees Cook2-22/+72
This adjusts structleak to also work with non-struct types when they are passed by reference, since those variables may leak just like anything else. This is exposed via an improved set of Kconfig options. (This does mean structleak is slightly misnamed now.) Building with CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL should give the kernel complete initialization coverage of all stack variables passed by reference, including padding (see lib/test_stackinit.c). Using CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE to count added initializations under defconfig: ..._BYREF: 5945 added initializations ..._BYREF_ALL: 16606 added initializations There is virtually no change to text+data size (both have less than 0.05% growth): text data bss dec hex filename 19502103 5051456 1917000 26470559 193e89f vmlinux.stock 19513412 5051456 1908808 26473676 193f4cc vmlinux.byref 19516974 5047360 1900616 26464950 193d2b6 vmlinux.byref_all The measured performance difference is in the noise for hackbench and kernel build benchmarks: Stock: 5x hackbench -g 20 -l 1000 Mean: 10.649s Std Dev: 0.339 5x kernel build (4-way parallel) Mean: 261.98s Std Dev: 1.53 CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF: 5x hackbench -g 20 -l 1000 Mean: 10.540s Std Dev: 0.233 5x kernel build (4-way parallel) Mean: 260.52s Std Dev: 1.31 CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL: 5x hackbench -g 20 -l 1000 Mean: 10.320 Std Dev: 0.413 5x kernel build (4-way parallel) Mean: 260.10 Std Dev: 0.86 This does not yet solve missing padding initialization for structures on the stack that are never passed by reference (which should be a tiny minority). Hopefully this will be more easily addressed by upstream compiler fixes after clarifying the C11 padding initialization specification. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-01-21gcc-plugins: arm_ssp_per_task_plugin: fix for GCC 9+Ard Biesheuvel1-0/+18
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 <ard.biesheuvel@linaro.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2019-01-21gcc-plugins: arm_ssp_per_task_plugin: sign extend the SP maskArd Biesheuvel1-2/+3
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 <kugan.vivekanandarajah@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2018-12-27Merge tag 'gcc-plugins-v4.21-rc1' of ↵Linus Torvalds2-0/+107
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux 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
2018-12-13ARM: smp: add support for per-task stack canariesArd Biesheuvel2-0/+107
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 <linux@armlinux.org.uk> Cc: Kees Cook <keescook@chromium.org> Cc: Emese Revfy <re.emese@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Laura Abbott <labbott@redhat.com> Cc: kernel-hardening@lists.openwall.com Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2018-12-06stackleak: Register the 'stackleak_cleanup' pass before the '*free_cfg' passAlexander Popov1-3/+5
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 <lkp@intel.com> Signed-off-by: Alexander Popov <alex.popov@linux.com> Signed-off-by: Kees Cook <keescook@chromium.org>
2018-09-04stackleak: Allow runtime disabling of kernel stack erasingAlexander Popov1-0/+8
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 <mingo@kernel.org> Signed-off-by: Alexander Popov <alex.popov@linux.com> Tested-by: Laura Abbott <labbott@redhat.com> Signed-off-by: Kees Cook <keescook@chromium.org>
2018-09-04fs/proc: Show STACKLEAK metrics in the /proc file systemAlexander Popov1-0/+12
Introduce CONFIG_STACKLEAK_METRICS providing STACKLEAK information about tasks via the /proc file system. In particular, /proc/<pid>/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 <mingo@kernel.org> Signed-off-by: Alexander Popov <alex.popov@linux.com> Tested-by: Laura Abbott <labbott@redhat.com> Signed-off-by: Kees Cook <keescook@chromium.org>
2018-09-04gcc-plugins: Add STACKLEAK plugin for tracking the kernel stackAlexander Popov2-0/+439
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 <alex.popov@linux.com> Tested-by: Laura Abbott <labbott@redhat.com> Signed-off-by: Kees Cook <keescook@chromium.org>
2018-09-04x86/entry: Add STACKLEAK erasing the kernel stack at the end of syscallsAlexander Popov1-0/+19
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 <alex.popov@linux.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2018-08-26Merge tag 'gcc-plugins-v4.19-rc1-fix' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull gcc plugin fix from Kees Cook: "Lift gcc test into Kconfig. This is for better behavior when the kernel is built with Clang, reported by Stefan Agner" * tag 'gcc-plugins-v4.19-rc1-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: gcc-plugins: Disable when building under Clang
2018-08-23gcc-plugins: Disable when building under ClangKees Cook1-1/+1
Prior to doing compiler feature detection in Kconfig, attempts to build GCC plugins with Clang would fail the build, much in the same way missing GCC plugin headers would fail the build. However, now that this logic has been lifted into Kconfig, add an explicit test for GCC (instead of duplicating it in the feature-test script). Reported-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-07-25gcc-plugins: Clean up the cgraph_create_edge* macrosAlexander Popov1-10/+16
Drop useless redefinitions of cgraph_create_edge* macros. Drop the unused nest argument. Also support gcc-8, which doesn't have freq argument. Signed-off-by: Alexander Popov <alex.popov@linux.com> Signed-off-by: Kees Cook <keescook@chromium.org>
2018-07-25gcc-plugins: split out Kconfig entries to scripts/gcc-plugins/KconfigMasahiro Yamada1-0/+142
Collect relevant code into the scripts/gcc-plugins directory. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Kees Cook <keescook@chromium.org>
2018-07-03gcc-plugins: remove unused GCC_PLUGIN_SUBDIRMasahiro Yamada1-5/+0
GCC_PLUGIN_SUBDIR has never been used. If you really need this in the future, please re-add it then. For now, the code is unused. Remove. 'export HOSTLIBS' is not necessary either. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Kees Cook <keescook@chromium.org>
2018-06-11gcc-plugins: test plugin support in Kconfig and clean up MakefileMasahiro Yamada1-0/+1
Run scripts/gcc-plugin.sh from Kconfig so that users can enable GCC_PLUGINS only when the compiler supports building plugins. Kconfig defines a new symbol, PLUGIN_HOSTCC. This will contain the compiler (g++ or gcc) used for building plugins, or empty if the plugin can not be supported at all. This allows us to remove all ugly testing in Makefile.gcc-plugins. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Kees Cook <keescook@chromium.org>
2018-06-11kcov: test compiler capability in Kconfig and correct dependencyMasahiro Yamada1-4/+0
As Documentation/kbuild/kconfig-language.txt notes, 'select' should be be used with care - it forces a lower limit of another symbol, ignoring the dependency. Currently, KCOV can select GCC_PLUGINS even if arch does not select HAVE_GCC_PLUGINS. This could cause the unmet direct dependency. Now that Kconfig can test compiler capability, let's handle this in a more sophisticated way. There are two ways to enable KCOV; use the compiler that natively supports -fsanitize-coverage=trace-pc, or build the SANCOV plugin if the compiler has ability to build GCC plugins. Hence, the correct dependency for KCOV is: depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS You do not need to build the SANCOV plugin if the compiler already supports -fsanitize-coverage=trace-pc. Hence, the select should be: select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC With this, GCC_PLUGIN_SANCOV is selected only when necessary, so scripts/Makefile.gcc-plugins can be cleaner. I also cleaned up Kconfig and scripts/Makefile.kcov as well. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Kees Cook <keescook@chromium.org>
2018-03-31security: convert security hooks to use hlistSargun Dhillon1-2/+2
This changes security_hook_heads to use hlist_heads instead of the circular doubly-linked list heads. This should cut down the size of the struct by about half. In addition, it allows mutation of the hooks at the tail of the callback list without having to modify the head. The longer-term purpose of this is to enable making the heads read only. Signed-off-by: Sargun Dhillon <sargun@sargun.me> Reviewed-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Acked-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: James Morris <james.morris@microsoft.com>
2018-02-06gcc-plugins: Use dynamic initializersKees Cook3-78/+33
GCC 8 changed the order of some fields and is very picky about ordering in static initializers, so instead just move to dynamic initializers, and drop the redundant already-zero field assignments. Suggested-by: Valdis Kletnieks <valdis.kletnieks@vt.edu> Signed-off-by: Kees Cook <keescook@chromium.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-11-26 00:40:22 +0300