09 Jan, 2020
1 commit
-
commit a5b0dc5a46c221725c43bd9b01570239a4cd78b1 upstream.
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
Acked-by: Ard Biesheuvel
Reviewed-by: Masahiro Yamada
Link: https://lore.kernel.org/r/20191211133951.401933-1-arnd@arndb.de
Cc: stable@vger.kernel.org
Signed-off-by: Kees Cook
Signed-off-by: Greg Kroah-Hartman
01 Aug, 2019
1 commit
-
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
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
15 Jul, 2019
1 commit
-
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
Acked-by: Kees Cook
01 Jun, 2019
1 commit
-
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
21 May, 2019
2 commits
-
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
Signed-off-by: Greg Kroah-Hartman -
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"
Fixes: 189af4657186 ("ARM: smp: add support for per-task stack canaries")
Cc: stable@vger.kernel.org
Signed-off-by: Kees Cook
14 May, 2019
1 commit
-
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
11 May, 2019
1 commit
-
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
compilerHOSTCXX -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_SETSigned-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
25 Apr, 2019
2 commits
-
This moves the stackleak plugin options to Kconfig.hardening's memory
initialization menu.Signed-off-by: Kees Cook
Reviewed-by: Alexander Popov
Acked-by: Masahiro Yamada -
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
Acked-by: Masahiro Yamada
10 Mar, 2019
1 commit
-
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
06 Mar, 2019
1 commit
-
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/
Link: http://lkml.kernel.org/r/20190111185842.13978-1-aryabinin@virtuozzo.com
Signed-off-by: Andrey Ryabinin
Acked-by: Will Deacon [arm64]
Cc: Qian Cai
Cc: Alexander Potapenko
Cc: Dmitry Vyukov
Cc: Catalin Marinas
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
05 Mar, 2019
1 commit
-
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 initializationsThere 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_allThe 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.3395x kernel build (4-way parallel)
Mean: 261.98s
Std Dev: 1.53CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF:
5x hackbench -g 20 -l 1000
Mean: 10.540s
Std Dev: 0.2335x kernel build (4-way parallel)
Mean: 260.52s
Std Dev: 1.31CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL:
5x hackbench -g 20 -l 1000
Mean: 10.320
Std Dev: 0.4135x kernel build (4-way parallel)
Mean: 260.10
Std Dev: 0.86This 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
Reviewed-by: Ard Biesheuvel
21 Jan, 2019
2 commits
-
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 -
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
28 Dec, 2018
1 commit
-
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
13 Dec, 2018
1 commit
-
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
07 Dec, 2018
1 commit
-
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
05 Sep, 2018
4 commits
-
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 -
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 -
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 -
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% slowdownTest #2: hackbench -s 4096 -l 2000 -g 15 -f 25 -P
4.2% slowdownSo 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
27 Aug, 2018
1 commit
-
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
24 Aug, 2018
1 commit
-
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
Signed-off-by: Kees Cook
Reviewed-by: Masahiro Yamada
25 Jul, 2018
2 commits
-
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
Signed-off-by: Kees Cook -
Collect relevant code into the scripts/gcc-plugins directory.
Signed-off-by: Masahiro Yamada
Signed-off-by: Kees Cook
03 Jul, 2018
1 commit
-
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
Signed-off-by: Kees Cook
11 Jun, 2018
2 commits
-
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
Acked-by: Kees Cook -
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
Reviewed-by: Kees Cook
31 Mar, 2018
1 commit
-
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
Reviewed-by: Tetsuo Handa
Acked-by: Casey Schaufler
Signed-off-by: James Morris
06 Feb, 2018
2 commits
-
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
Signed-off-by: Kees Cook -
GCC requires another #include to get the gcc-plugins to build cleanly.
Signed-off-by: Valdis Kletnieks
Signed-off-by: Kees Cook
02 Nov, 2017
1 commit
-
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
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
08 Aug, 2017
2 commits
-
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
Signed-off-by: Kees Cook
02 Aug, 2017
1 commit
-
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
23 Jun, 2017
4 commits
-
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
Signed-off-by: Kees Cook -
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
Signed-off-by: Kees Cook -
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
Cc: David S. Miller
Signed-off-by: Kees Cook -
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
Cc: James Morris
Signed-off-by: Kees Cook