| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
There are some issues in the test_fortify Makefile code.
Problem 1: cc-disable-warning invokes compiler dozens of times
To see how many times the cc-disable-warning is evaluated, change
this code:
$(call cc-disable-warning,fortify-source)
to:
$(call cc-disable-warning,$(shell touch /tmp/fortify-$$$$)fortify-source)
Then, build the kernel with CONFIG_FORTIFY_SOURCE=y. You will see a
large number of '/tmp/fortify-<PID>' files created:
$ ls -1 /tmp/fortify-* | wc
80 80 1600
This means the compiler was invoked 80 times just for checking the
-Wno-fortify-source flag support.
$(call cc-disable-warning,fortify-source) should be added to a simple
variable instead of a recursive variable.
Problem 2: do not recompile string.o when the test code is updated
The test cases are independent of the kernel. However, when the test
code is updated, $(obj)/string.o is rebuilt and vmlinux is relinked
due to this dependency:
$(obj)/string.o: $(obj)/$(TEST_FORTIFY_LOG)
always-y is suitable for building the log files.
Problem 3: redundant code
clean-files += $(addsuffix .o, $(TEST_FORTIFY_LOGS))
... is unneeded because the top Makefile globally cleans *.o files.
This commit fixes these issues and makes the code readable.
Signed-off-by: Masahiro Yamada <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Kees Cook <[email protected]>
|
|
This allows kernel developer to embed a default bootconfig file in
the kernel instead of embedding it in the initrd. This will be good
for who are using the kernel without initrd, or who needs a default
bootconfigs.
This needs to set two kconfigs: CONFIG_BOOT_CONFIG_EMBED=y and set
the file path to CONFIG_BOOT_CONFIG_EMBED_FILE.
Note that you still need 'bootconfig' command line option to load the
embedded bootconfig. Also if you boot using an initrd with a different
bootconfig, the kernel will use the bootconfig in the initrd, instead
of the default bootconfig.
Link: https://lkml.kernel.org/r/164921227943.1090670.14035119557571329218.stgit@devnote2
Cc: Padmanabha Srinivasaiah <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Randy Dunlap <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Cc: Sami Tolvanen <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Cc: Linux Kbuild mailing list <[email protected]>
Signed-off-by: Masami Hiramatsu <[email protected]>
Signed-off-by: Steven Rostedt (Google) <[email protected]>
|
|
While the run-time testing of FORTIFY_SOURCE is already present in
LKDTM, there is no testing of the expected compile-time detections. In
preparation for correctly supporting FORTIFY_SOURCE under Clang, adding
additional FORTIFY_SOURCE defenses, and making sure FORTIFY_SOURCE
doesn't silently regress with GCC, introduce a build-time test suite that
checks each expected compile-time failure condition.
As this is relatively backwards from standard build rules in the
sense that a successful test is actually a compile _failure_, create
a wrapper script to check for the correct errors, and wire it up as
a dummy dependency to lib/string.o, collecting the results into a log
file artifact.
Signed-off-by: Kees Cook <[email protected]>
|
|
The pattern prefixed with '/' matches files in the same directory,
but not ones in sub-directories.
Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Miguel Ojeda <[email protected]>
Acked-by: Rob Herring <[email protected]>
Acked-by: Andra Paraschiv <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Acked-by: Gabriel Krisman Bertazi <[email protected]>
|
|
Add SPDX License Identifier to all .gitignore files.
Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
Some .gitignore files have comments like "Generated files",
"Ignore generated files" at the header part, but they are
too obvious.
Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
Patch series "add crc64 calculation as kernel library", v5.
This patchset adds basic implementation of crc64 calculation as a Linux
kernel library. Since bcache already does crc64 by itself, this patchset
also modifies bcache code to use the new crc64 library routine.
Currently bcache is the only user of crc64 calculation, another potential
user is bcachefs which is on the way to be in mainline kernel. Therefore
it makes sense to make crc64 calculation to be a public library.
bcache uses crc64 as storage checksum, if a change of crc lib routines
results an inconsistent result, the unmatched checksum may make bcache
'think' the on-disk is corrupted, such a change should be avoided or
detected as early as possible. Therefore a patch is being prepared which
adds a crc test framework, to check consistency of different calculations.
This patch (of 2):
Add the re-write crc64 calculation routines for Linux kernel. The CRC64
polynomical arithmetic follows ECMA-182 specification, inspired by CRC
paper of Dr. Ross N. Williams (see
http://www.ross.net/crc/download/crc_v3.txt) and other public domain
implementations.
All the changes work in this way,
- When Linux kernel is built, host program lib/gen_crc64table.c will be
compiled to lib/gen_crc64table and executed.
- The output of gen_crc64table execution is an array called as lookup
table (a.k.a POLY 0x42f0e1eba9ea369) which contain 256 64-bit long
numbers, this table is dumped into header file lib/crc64table.h.
- Then the header file is included by lib/crc64.c for normal 64bit crc
calculation.
- Function declaration of the crc64 calculation routines is placed in
include/linux/crc64.h
Currently bcache is the only user of crc64_be(), another potential user is
bcachefs which is on the way to be in mainline kernel. Therefore it makes
sense to move crc64 calculation into lib/crc64.c as public code.
[[email protected]: fix review comments from v4]
Link: http://lkml.kernel.org/r/[email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Coly Li <[email protected]>
Co-developed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-by: Hannes Reinecke <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Andy Shevchenko <[email protected]>
Cc: Michael Lyle <[email protected]>
Cc: Kent Overstreet <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Kate Stewart <[email protected]>
Cc: Eric Biggers <[email protected]>
Cc: Randy Dunlap <[email protected]>
Cc: Noah Massey <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Implement a simple static OID registry that allows the mapping of an encoded
OID to an enum value for ease of use.
The OID registry index enum appears in the:
linux/oid_registry.h
header file. A script generates the registry from lines in the header file
that look like:
<sp*>OID_foo,<sp*>/*<sp*>1.2.3.4<sp*>*/
The actual OID is taken to be represented by the numbers with interpolated
dots in the comment.
All other lines in the header are ignored.
The registry is queries by calling:
OID look_up_oid(const void *data, size_t datasize);
This returns a number from the registry enum representing the OID if found or
OID__NR if not.
Signed-off-by: David Howells <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>
|
|
This still leaves driver and architecture-specific subdirectories alone,
but gets rid of the bulk of the "generic" generated files that we should
ignore.
Signed-off-by: Linus Torvalds <[email protected]>
|