summaryrefslogtreecommitdiff
path: root/scripts/gcc-plugins
AgeCommit message (Collapse)AuthorFilesLines
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>
2018-02-06gcc-plugins: Add include required by GCC release 8valdis.kletnieks@vt.edu1-0/+4
GCC requires another #include to get the gcc-plugins to build cleanly. Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu> Signed-off-by: Kees Cook <keescook@chromium.org>
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman7-0/+7
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-07Merge branch 'for-next/gcc-plugin/structleak' into for-next/gcc-pluginsKees Cook1-2/+11
2017-08-07gcc-plugins: structleak: add option to init all vars used as byref argsArd Biesheuvel1-2/+11
In the Linux kernel, struct type variables are rarely passed by-value, and so functions that initialize such variables typically take an input reference to the variable rather than returning a value that can subsequently be used in an assignment. If the initalization function is not part of the same compilation unit, the lack of an assignment operation defeats any analysis the compiler can perform as to whether the variable may be used before having been initialized. This means we may end up passing on such variables uninitialized, resulting in potential information leaks. So extend the existing structleak GCC plugin so it will [optionally] apply to all struct type variables that have their address taken at any point, rather than only to variables of struct types that have a __user annotation. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2017-08-02randstruct: Enable function pointer struct detectionKees Cook1-3/+0
This enables the automatic structure selection logic in the randstruct GCC plugin. The selection logic randomizes all structures that contain only function pointers, unless marked with __no_randomize_layout. Signed-off-by: Kees Cook <keescook@chromium.org>
2017-06-23randstruct: Whitelist NIU struct page overloadingKees Cook1-0/+2
The NIU ethernet driver intentionally stores a page struct pointer on top of the "mapping" field. Whitelist this case: drivers/net/ethernet/sun/niu.c: In function ‘niu_rx_pkt_ignore’: drivers/net/ethernet/sun/niu.c:3402:10: note: found mismatched ssa struct pointer types: ‘struct page’ and ‘struct address_space’ *link = (struct page *) page->mapping; ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Cc: David S. Miller <davem@davemloft.net> Signed-off-by: Kees Cook <keescook@chromium.org>
2017-06-23randstruct: Whitelist big_key path struct overloadingKees Cook1-0/+2
The big_key payload structure intentionally stores a struct path in two void pointers to avoid header soup. Whitelist this case: security/keys/big_key.c: In function ‘big_key_read’: security/keys/big_key.c:293:16: note: found mismatched rhs struct pointer types: ‘struct path’ and ‘void *’ struct path *path = (struct path *)&key->payload.data[big_key_path]; ^~~~ Cc: David Howells <dhowells@redhat.com> Signed-off-by: Kees Cook <keescook@chromium.org>
2017-06-23randstruct: Whitelist UNIXCB castKees Cook1-0/+2
This is another false positive in bad cast detection: net/unix/af_unix.c: In function ‘unix_skb_scm_eq’: net/unix/af_unix.c:1621:31: note: found mismatched rhs struct pointer types: ‘struct unix_skb_parms’ and ‘char’ const struct unix_skb_parms *u = &UNIXCB(skb); ^ UNIXCB is: #define UNIXCB(skb) (*(struct unix_skb_parms *)&((skb)->cb)) And ->cb is: char cb[48] __aligned(8); This is a rather crazy cast, but appears to be safe in the face of randomization, so whitelist it in the plugin. Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> Cc: David S. Miller <davem@davemloft.net> Signed-off-by: Kees Cook <keescook@chromium.org>
2017-06-23randstruct: Whitelist struct security_hook_heads castKees Cook1-0/+2
The LSM initialization routines walk security_hook_heads as an array of struct list_head instead of via names to avoid a ton of needless source. Whitelist this to avoid the false positive warning from the plugin: security/security.c: In function ‘security_init’: security/security.c:59:20: note: found mismatched op0 struct pointer types: ‘struct list_head’ and ‘struct security_hook_heads’ struct list_head *list = (struct list_head *) &security_hook_heads; ^ Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: James Morris <james.l.morris@oracle.com> Signed-off-by: Kees Cook <keescook@chromium.org>
2017-06-23gcc-plugins: Add the randstruct pluginKees Cook5-0/+1042
This randstruct plugin is modified from Brad Spengler/PaX Team's code in the last public patch of grsecurity/PaX based on my understanding of the code. Changes or omissions from the original code are mine and don't reflect the original grsecurity/PaX code. The randstruct GCC plugin randomizes the layout of selected structures at compile time, as a probabilistic defense against attacks that need to know the layout of structures within the kernel. This is most useful for "in-house" kernel builds where neither the randomization seed nor other build artifacts are made available to an attacker. While less useful for distribution kernels (where the randomization seed must be exposed for third party kernel module builds), it still has some value there since now all kernel builds would need to be tracked by an attacker. In more performance sensitive scenarios, GCC_PLUGIN_RANDSTRUCT_PERFORMANCE can be selected to make a best effort to restrict randomization to cacheline-sized groups of elements, and will not randomize bitfields. This comes at the cost of reduced randomization. Two annotations are defined,__randomize_layout and __no_randomize_layout, which respectively tell the plugin to either randomize or not to randomize instances of the struct in question. Follow-on patches enable the auto-detection logic for selecting structures for randomization that contain only function pointers. It is disabled here to assist with bisection. Since any randomized structs must be initialized using designated initializers, __randomize_layout includes the __designated_init annotation even when the plugin is disabled so that all builds will require the needed initialization. (With the plugin enabled, annotations for automatically chosen structures are marked as well.) The main differences between this implemenation and grsecurity are: - disable automatic struct selection (to be enabled in follow-up patch) - add designated_init attribute at runtime and for manual marking - clarify debugging output to differentiate bad cast warnings - add whitelisting infrastructure - support gcc 7's DECL_ALIGN and DECL_MODE changes (Laura Abbott) - raise minimum required GCC version to 4.7 Earlier versions of this patch series were ported by Michael Leibowitz. Signed-off-by: Kees Cook <keescook@chromium.org>
2017-05-28gcc-plugins: Detail c-common.h location for GCC 4.6Kees Cook1-0/+7
The c-common.h file moved in stock gcc 4.7, not gcc 4.6. However, most people building plugins with gcc 4.6 are using the Debian or Ubuntu version, which includes a patch to move the headers to the 4.7 location. In case anyone trips over this with a stock gcc 4.6, add a pointer to the patch used by Debian/Ubuntu. Signed-off-by: Kees Cook <keescook@chromium.org>
2017-03-10Merge tag 'gcc-plugins-v4.11-rc2' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull gcc-plugins fix from Kees Cook: "Fixes a typo in sancov plugin, exposed in earlier compiler versions" * tag 'gcc-plugins-v4.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: gcc-plugins: fix sancov_plugin for gcc-5
2017-02-28gcc-plugins: fix sancov_plugin for gcc-5Arnd Bergmann1-1/+1
The name of the local variable was inadvertantly changed from sancov_plugin_pass_info to sancov_pass_info: scripts/gcc-plugins/sancov_plugin.c: In function ‘int plugin_init(plugin_name_args*, plugin_gcc_version*)’: scripts/gcc-plugins/sancov_plugin.c:136:67: error: ‘sancov_plugin_pass_info’ was not declared in this scope This changes the conditional reference to this variable as well. Fixes: 5a45a4c5c3f5 ("gcc-plugins: consolidate on PASS_INFO macro") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kees Cook <keescook@chromium.org>
2017-02-22Merge branch 'for-next/gcc-plugin/structleak' into for-linus/gcc-pluginsKees Cook1-0/+246
2017-01-18gcc-plugins: Add structleak for more stack initializationKees Cook1-0/+246
This plugin detects any structures that contain __user attributes and makes sure it is being fully initialized so that a specific class of information exposure is eliminated. (This plugin was originally designed to block the exposure of siginfo in CVE-2013-2141.) Ported from grsecurity/PaX. This version adds a verbose option to the plugin and the Kconfig. Signed-off-by: Kees Cook <keescook@chromium.org>
2017-01-14gcc-plugins: consolidate on PASS_INFO macroKees Cook3-17/+5
Now that PASS_INFO() exists, use it in the other existing gcc plugins, instead of always open coding the same thing. Based on updates to the grsecurity/PaX gcc plugins. Signed-off-by: Kees Cook <keescook@chromium.org>
2017-01-11gcc-plugins: add PASS_INFO and build_const_char_string()Kees Cook1-11/+44
This updates the GCC plugins gcc-common.h from PaX Team to include more helpers and header files, specifically adds the PASS_INFO() macro to make plugin declarations nicer and a helper for proper const string building. Signed-off-by: Kees Cook <keescook@chromium.org>
2017-01-03gcc-plugins: update gcc-common.h for gcc-7Kees Cook1-0/+85
This updates gcc-common.h from Emese Revfy for gcc 7. This fixes issues seen by Kugan and Arnd. Build tested with gcc 5.4 and 7 snapshot. Cc: stable@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org>
2017-01-03latent_entropy: fix ARM build error on earlier gccKees Cook1-2/+2
This fixes build errors seen on gcc-4.9.3 or gcc-5.3.1 for an ARM: arm-soc/init/initramfs.c: In function 'error': arm-soc/init/initramfs.c:50:1: error: unrecognizable insn: } ^ (insn 26 25 27 5 (set (reg:SI 111 [ local_entropy.243 ]) (rotatert:SI (reg:SI 116 [ local_entropy.243 ]) (const_int -30 [0xffffffffffffffe2]))) -1 (nil)) Patch from PaX Team <pageexec@freemail.hu> Reported-by: Arnd Bergmann <arnd@arndb.de> Reported-by: Brad Spengler <spender@grsecurity.net> Cc: stable@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org>
2016-12-14treewide: Fix printk() message errorsMasanari Iida2-2/+2
This patch fix spelling typos in printk and kconfig. Signed-off-by: Masanari Iida <standby24x7@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-10-31latent_entropy: Fix wrong gcc code generation with 64 bit variablesKees Cook1-10/+9
The stack frame size could grow too large when the plugin used long long on 32-bit architectures when the given function had too many basic blocks. The gcc warning was: drivers/pci/hotplug/ibmphp_ebda.c: In function 'ibmphp_access_ebda': drivers/pci/hotplug/ibmphp_ebda.c:409:1: warning: the frame size of 1108 bytes is larger than 1024 bytes [-Wframe-larger-than=] This switches latent_entropy from u64 to unsigned long. Thanks to PaX Team and Emese Revfy for the patch. Signed-off-by: Kees Cook <keescook@chromium.org>
2016-10-31gcc-plugins: Export symbols needed by gccKees Cook4-7/+8
This explicitly exports symbols that gcc expects from plugins. Based on code from Emese Revfy. Signed-off-by: Kees Cook <keescook@chromium.org>
2016-10-11gcc-plugins: Add latent_entropy pluginEmese Revfy1-0/+640
This adds a new gcc plugin named "latent_entropy". It is designed to extract as much possible uncertainty from a running system at boot time as possible, hoping to capitalize on any possible variation in CPU operation (due to runtime data differences, hardware differences, SMP ordering, thermal timing variation, cache behavior, etc). At the very least, this plugin is a much more comprehensive example for how to manipulate kernel code using the gcc plugin internals. The need for very-early boot entropy tends to be very architecture or system design specific, so this plugin is more suited for those sorts of special cases. The existing kernel RNG already attempts to extract entropy from reliable runtime variation, but this plugin takes the idea to a logical extreme by permuting a global variable based on any variation in code execution (e.g. a different value (and permutation function) is used to permute the global based on loop count, case statement, if/then/else branching, etc). To do this, the plugin starts by inserting a local variable in every marked function. The plugin then adds logic so that the value of this variable is modified by randomly chosen operations (add, xor and rol) and random values (gcc generates separate static values for each location at compile time and also injects the stack pointer at runtime). The resulting value depends on the control flow path (e.g., loops and branches taken). Before the function returns, the plugin mixes this local variable into the latent_entropy global variable. The value of this global variable is added to the kernel entropy pool in do_one_initcall() and _do_fork(), though it does not credit any bytes of entropy to the pool; the contents of the global are just used to mix the pool. Additionally, the plugin can pre-initialize arrays with build-time random contents, so that two different kernel builds running on identical hardware will not have the same starting values. Signed-off-by: Emese Revfy <re.emese@gmail.com> [kees: expanded commit message and code comments] Signed-off-by: Kees Cook <keescook@chromium.org>
2016-08-09gcc-plugins: Add support for plugin subdirectoriesEmese Revfy1-3/+6
This adds support for building more complex gcc plugins that live in a subdirectory instead of just in a single source file. Reported-by: PaX Team <pageexec@freemail.hu> Signed-off-by: Emese Revfy <re.emese@gmail.com> [kees: clarified commit message] Signed-off-by: Kees Cook <keescook@chromium.org>
2016-08-09gcc-plugins: Automate make rule generationEmese Revfy1-2/+1
There's no reason to repeat the same names in the Makefile when the .so files have already been listed. The .o list can be generated from them. Reported-by: PaX Team <pageexec@freemail.hu> Signed-off-by: Emese Revfy <re.emese@gmail.com> [kees: clarified commit message] Signed-off-by: Kees Cook <keescook@chromium.org>
2016-06-07Add sancov pluginEmese Revfy2-0/+150
The sancov gcc plugin inserts a __sanitizer_cov_trace_pc() call at the start of basic blocks. This plugin is a helper plugin for the kcov feature. It supports all gcc versions with plugin support (from gcc-4.5 on). It is based on the gcc commit "Add fuzzing coverage support" by Dmitry Vyukov (https://gcc.gnu.org/viewcvs/gcc?limit_changes=0&view=revision&revision=231296). Signed-off-by: Emese Revfy <re.emese@gmail.com> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: Michal Marek <mmarek@suse.com>
2016-06-07Add Cyclomatic complexity GCC pluginEmese Revfy2-0/+74
Add a very simple plugin to demonstrate the GCC plugin infrastructure. This GCC plugin computes the cyclomatic complexity of each function. The complexity M of a function's control flow graph is defined as: M = E - N + 2P where E = the number of edges N = the number of nodes P = the number of connected components (exit nodes). Signed-off-by: Emese Revfy <re.emese@gmail.com> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: Michal Marek <mmarek@suse.com>
2016-06-07GCC plugin infrastructureEmese Revfy6-0/+1664
This patch allows to build the whole kernel with GCC plugins. It was ported from grsecurity/PaX. The infrastructure supports building out-of-tree modules and building in a separate directory. Cross-compilation is supported too. Currently the x86, arm, arm64 and uml architectures enable plugins. The directory of the gcc plugins is scripts/gcc-plugins. You can use a file or a directory there. The plugins compile with these options: * -fno-rtti: gcc is compiled with this option so the plugins must use it too * -fno-exceptions: this is inherited from gcc too * -fasynchronous-unwind-tables: this is inherited from gcc too * -ggdb: it is useful for debugging a plugin (better backtrace on internal errors) * -Wno-narrowing: to suppress warnings from gcc headers (ipa-utils.h) * -Wno-unused-variable: to suppress warnings from gcc headers (gcc_version variable, plugin-version.h) The infrastructure introduces a new Makefile target called gcc-plugins. It supports all gcc versions from 4.5 to 6.0. The scripts/gcc-plugin.sh script chooses the proper host compiler (gcc-4.7 can be built by either gcc or g++). This script also checks the availability of the included headers in scripts/gcc-plugins/gcc-common.h. The gcc-common.h header contains frequently included headers for GCC plugins and it has a compatibility layer for the supported gcc versions. The gcc-generate-*-pass.h headers automatically generate the registration structures for GIMPLE, SIMPLE_IPA, IPA and RTL passes. Note that 'make clean' keeps the *.so files (only the distclean or mrproper targets clean all) because they are needed for out-of-tree modules. Based on work created by the PaX Team. Signed-off-by: Emese Revfy <re.emese@gmail.com> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: Michal Marek <mmarek@suse.com>