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>
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>
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>
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>
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>
Alexander A. Klimov