#
c8424e77 |
| 04-Jul-2019 |
Thiago Jung Bauermann <bauerman@linux.ibm.com> |
MODSIGN: Export module signature definitions
IMA will use the module_signature format for append signatures, so export the relevant definitions and factor out the code which verifies that the append
MODSIGN: Export module signature definitions
IMA will use the module_signature format for append signatures, so export the relevant definitions and factor out the code which verifies that the appended signature trailer is valid.
Also, create a CONFIG_MODULE_SIG_FORMAT option so that IMA can select it and be able to use mod_check_sig() without having to depend on either CONFIG_MODULE_SIG or CONFIG_MODULES.
s390 duplicated the definition of struct module_signature so now they can use the new <linux/module_signature.h> header instead.
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Acked-by: Jessica Yu <jeyu@kernel.org> Reviewed-by: Philipp Rudo <prudo@linux.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
show more ...
|
#
2b8481be |
| 04-Jun-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
kbuild: remove build_unifdef target in scripts/Makefile
Since commit 2aedcd098a94 ("kbuild: suppress annoying "... is up to date." message"), if_changed and friends nicely suppress "is up to date" m
kbuild: remove build_unifdef target in scripts/Makefile
Since commit 2aedcd098a94 ("kbuild: suppress annoying "... is up to date." message"), if_changed and friends nicely suppress "is up to date" messages.
We do not need per-Makefile tricks.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
show more ...
|
#
28ba53c0 |
| 28-Apr-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
unicode: refactor the rule for regenerating utf8data.h
scripts/mkutf8data is used only when regenerating utf8data.h, which never happens in the normal kernel build. However, it is irrespectively bui
unicode: refactor the rule for regenerating utf8data.h
scripts/mkutf8data is used only when regenerating utf8data.h, which never happens in the normal kernel build. However, it is irrespectively built if CONFIG_UNICODE is enabled.
Moreover, there is no good reason for it to reside in the scripts/ directory since it is only used in fs/unicode/.
Hence, move it from scripts/ to fs/unicode/.
In some cases, we bypass build artifacts in the normal build. The conventional way to do so is to surround the code with ifdef REGENERATE_*.
For example,
- 7373f4f83c71 ("kbuild: add implicit rules for parser generation") - 6aaf49b495b4 ("crypto: arm,arm64 - Fix random regeneration of S_shipped")
I rewrote the rule in a more kbuild'ish style.
In the normal build, utf8data.h is just shipped from the check-in file.
$ make [ snip ] SHIPPED fs/unicode/utf8data.h CC fs/unicode/utf8-norm.o CC fs/unicode/utf8-core.o CC fs/unicode/utf8-selftest.o AR fs/unicode/built-in.a
If you want to generate utf8data.h based on UCD, put *.txt files into fs/unicode/, then pass REGENERATE_UTF8DATA=1 from the command line. The mkutf8data tool will be automatically compiled to generate the utf8data.h from the *.txt files.
$ make REGENERATE_UTF8DATA=1 [ snip ] HOSTCC fs/unicode/mkutf8data GEN fs/unicode/utf8data.h CC fs/unicode/utf8-norm.o CC fs/unicode/utf8-core.o CC fs/unicode/utf8-selftest.o AR fs/unicode/built-in.a
I renamed the check-in utf8data.h to utf8data.h_shipped so that this will work for the out-of-tree build.
You can update it based on the latest UCD like this:
$ make REGENERATE_UTF8DATA=1 fs/unicode/ $ cp fs/unicode/utf8data.h fs/unicode/utf8data.h_shipped
Also, I added entries to .gitignore and dontdiff.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
show more ...
|
#
955405d1 |
| 25-Apr-2019 |
Gabriel Krisman Bertazi <krisman@collabora.com> |
unicode: introduce UTF-8 character database
The decomposition and casefolding of UTF-8 characters are described in a prefix tree in utf8data.h, which is a generate from the Unicode Character Databas
unicode: introduce UTF-8 character database
The decomposition and casefolding of UTF-8 characters are described in a prefix tree in utf8data.h, which is a generate from the Unicode Character Database (UCD), published by the Unicode Consortium, and should not be edited by hand. The structures in utf8data.h are meant to be used for lookup operations by the unicode subsystem, when decoding a utf-8 string.
mkutf8data.c is the source for a program that generates utf8data.h. It was written by Olaf Weber from SGI and originally proposed to be merged into Linux in 2014. The original proposal performed the compatibility decomposition, NFKD, but the current version was modified by me to do canonical decomposition, NFD, as suggested by the community. The changes from the original submission are:
* Rebase to mainline. * Fix out-of-tree-build. * Update makefile to build 11.0.0 ucd files. * drop references to xfs. * Convert NFKD to NFD. * Merge back robustness fixes from original patch. Requested by Dave Chinner.
The original submission is archived at:
<https://linux-xfs.oss.sgi.narkive.com/Xx10wjVY/rfc-unicode-utf-8-support-for-xfs>
The utf8data.h file can be regenerated using the instructions in fs/unicode/README.utf8data.
- Notes on the update from 8.0.0 to 11.0:
The structure of the ucd files and special cases have not experienced any changes between versions 8.0.0 and 11.0.0. 8.0.0 saw the addition of Cherokee LC characters, which is an interesting case for case-folding. The update is accompanied by new tests on the test_ucd module to catch specific cases. No changes to mkutf8data script were required for the updates.
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
show more ...
|
#
1e5ff84f |
| 19-Feb-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
scripts/gdb: do not descend into scripts/gdb from scripts
Currently, Kbuild descends from scripts/Makefile to scripts/gdb/Makefile just for creating symbolic links, but it does not need to do it so
scripts/gdb: do not descend into scripts/gdb from scripts
Currently, Kbuild descends from scripts/Makefile to scripts/gdb/Makefile just for creating symbolic links, but it does not need to do it so early.
Merge the two descending paths to simplify the code.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
show more ...
|
#
ce2fd53a |
| 28-Nov-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
kbuild: descend into scripts/gcc-plugins/ via scripts/Makefile
Now that 'archprepare' depends on 'scripts', Kbuild can descend into scripts/gcc-plugins in a more standard way.
Signed-off-by: Masahi
kbuild: descend into scripts/gcc-plugins/ via scripts/Makefile
Now that 'archprepare' depends on 'scripts', Kbuild can descend into scripts/gcc-plugins in a more standard way.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Kees Cook <keescook@chromium.org>
show more ...
|
#
60df1aee |
| 28-Nov-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
kbuild: move modpost out of 'scripts' target
I am eagar to build under the scripts/ directory only with $(HOSTCC), but scripts/mod/ highly depends on the $(CC) and target arch headers. That it why t
kbuild: move modpost out of 'scripts' target
I am eagar to build under the scripts/ directory only with $(HOSTCC), but scripts/mod/ highly depends on the $(CC) and target arch headers. That it why the 'scripts' target must depend on 'asm-generic', 'gcc-plugins', and $(autoksyms_h).
Move it to the 'prepare0' stage. I know this is a cheesy workaround, but better than the current situation.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
show more ...
|
Revision tags: v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17, v4.16, v4.15 |
|
#
37c8a5fa |
| 10-Jan-2018 |
Rob Herring <robh@kernel.org> |
kbuild: consolidate Devicetree dtb build rules
There is nothing arch specific about building dtb files other than their location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. The dep
kbuild: consolidate Devicetree dtb build rules
There is nothing arch specific about building dtb files other than their location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. The dependencies and supported targets are all slightly different. Also, a cross-compiler for each arch is needed, but really the host compiler preprocessor is perfectly fine for building dtbs. Move the build rules to a common location and remove the arch specific ones. This is done in a single step to avoid warnings about overriding rules.
The build dependencies had been a mixture of 'scripts' and/or 'prepare'. These pull in several dependencies some of which need a target compiler (specifically devicetable-offsets.h) and aren't needed to build dtbs. All that is really needed is dtc, so adjust the dependencies to only be dtc.
This change enables support 'dtbs_install' on some arches which were missing the target.
Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Paul Burton <paul.burton@mips.com> Acked-by: Ley Foon Tan <ley.foon.tan@intel.com> Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Michal Marek <michal.lkml@markovi.net> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Michal Simek <monstr@monstr.eu> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Chris Zankel <chris@zankel.net> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: linux-kbuild@vger.kernel.org Cc: linux-snps-arc@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Cc: uclinux-h8-devel@lists.sourceforge.jp Cc: linux-mips@linux-mips.org Cc: nios2-dev@lists.rocketboards.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-xtensa@linux-xtensa.org Signed-off-by: Rob Herring <robh@kernel.org>
show more ...
|
#
8377bd2b |
| 09-Jul-2018 |
Laura Abbott <labbott@redhat.com> |
kbuild: Rename HOST_LOADLIBES to KBUILD_HOSTLDLIBS
In preparation for enabling command line LDLIBS, re-name HOST_LOADLIBES to KBUILD_HOSTLDLIBS as the internal use only flags. Also rename existing u
kbuild: Rename HOST_LOADLIBES to KBUILD_HOSTLDLIBS
In preparation for enabling command line LDLIBS, re-name HOST_LOADLIBES to KBUILD_HOSTLDLIBS as the internal use only flags. Also rename existing usage to HOSTLDLIBS for consistency. This should not have any visible effects.
Signed-off-by: Laura Abbott <labbott@redhat.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
show more ...
|
#
c417fbce |
| 25-Jun-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
kbuild: move bin2c back to scripts/ from scripts/basic/
Commit 8370edea81e3 ("bin2c: move bin2c in scripts/basic") moved bin2c to the scripts/basic/ directory, incorrectly stating "Kexec wants to us
kbuild: move bin2c back to scripts/ from scripts/basic/
Commit 8370edea81e3 ("bin2c: move bin2c in scripts/basic") moved bin2c to the scripts/basic/ directory, incorrectly stating "Kexec wants to use bin2c and it wants to use it really early in the build process. See arch/x86/purgatory/ code in later patches."
Commit bdab125c9301 ("Revert "kexec/purgatory: Add clean-up for purgatory directory"") and commit d6605b6bbee8 ("x86/build: Remove unnecessary preparation for purgatory") removed the redundant purgatory build magic entirely.
That means that the move of bin2c was unnecessary in the first place.
fixdep is the only host program that deserves to sit in the scripts/basic/ directory.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
show more ...
|
Revision tags: v4.13.16, v4.14 |
|
#
b2441318 |
| 01-Nov-2017 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine
License cleanup: add SPDX GPL-2.0 license identifier to files with no license
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>
show more ...
|
Revision tags: v4.13.5, v4.13, v4.12 |
|
#
52b3f239 |
| 23-Jun-2017 |
Jonathan Corbet <corbet@lwn.net> |
Docs: clean up some DocBook loose ends
There were a few bits and pieces left over from the now-disused DocBook toolchain; git rid of them.
Reported-by: Markus Heiser <markus.heiser@darmarit.de> Sig
Docs: clean up some DocBook loose ends
There were a few bits and pieces left over from the now-disused DocBook toolchain; git rid of them.
Reported-by: Markus Heiser <markus.heiser@darmarit.de> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
show more ...
|
Revision tags: v4.10.17 |
|
#
cb43fb57 |
| 14-May-2017 |
Mauro Carvalho Chehab <mchehab@s-opensource.com> |
docs: remove DocBook from the building system
Now that we don't have any DocBook anymore, remove it from the building system.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
Revision tags: v4.10.16, v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9, v4.10.8, v4.10.7, v4.10.6, v4.10.5, v4.10.4, v4.10.3, v4.10.2, v4.10.1, v4.10, v4.9, openbmc-4.4-20161121-1, v4.4.33, v4.4.32, v4.4.31, v4.4.30, v4.4.29, v4.4.28, v4.4.27, v4.7.10, openbmc-4.4-20161021-1, v4.7.9, v4.4.26, v4.7.8, v4.4.25, v4.4.24, v4.7.7, v4.8, v4.4.23, v4.7.6, v4.7.5, v4.4.22, v4.4.21, v4.7.4, v4.7.3, v4.4.20, v4.7.2, v4.4.19, openbmc-4.4-20160819-1, v4.7.1, v4.4.18, v4.4.17, openbmc-4.4-20160804-1, v4.4.16, v4.7, openbmc-4.4-20160722-1, openbmc-20160722-1, openbmc-20160713-1, v4.4.15, v4.6.4, v4.6.3, v4.4.14, v4.6.2, v4.4.13, openbmc-20160606-1, v4.6.1, v4.4.12 |
|
#
6b90bd4b |
| 23-May-2016 |
Emese Revfy <re.emese@gmail.com> |
GCC plugin infrastructure
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
GCC plugin infrastructure
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>
show more ...
|
Revision tags: openbmc-20160521-1, v4.4.11, openbmc-20160518-1, v4.6, v4.4.10, openbmc-20160511-1, openbmc-20160505-1, v4.4.9, v4.4.8, v4.4.7, openbmc-20160329-2, openbmc-20160329-1, openbmc-20160321-1, v4.4.6, v4.5, v4.4.5, v4.4.4, v4.4.3, openbmc-20160222-1, v4.4.2, openbmc-20160212-1, openbmc-20160210-1, openbmc-20160202-2, openbmc-20160202-1, v4.4.1, openbmc-20160127-1, openbmc-20160120-1, v4.4, openbmc-20151217-1, openbmc-20151210-1, openbmc-20151202-1 |
|
#
c4c36105 |
| 24-Nov-2015 |
Mehmet Kayaalp <mkayaalp@linux.vnet.ibm.com> |
KEYS: Reserve an extra certificate symbol for inserting without recompiling
Place a system_extra_cert buffer of configurable size, right after the system_certificate_list, so that inserted keys can
KEYS: Reserve an extra certificate symbol for inserting without recompiling
Place a system_extra_cert buffer of configurable size, right after the system_certificate_list, so that inserted keys can be readily processed by the existing mechanism. Added script takes a key file and a kernel image and inserts its contents to the reserved area. The system_certificate_list_size is also adjusted accordingly.
Call the script as:
scripts/insert-sys-cert -b <vmlinux> -c <certfile>
If vmlinux has no symbol table, supply System.map file with -s flag. Subsequent runs replace the previously inserted key, instead of appending the new one.
Signed-off-by: Mehmet Kayaalp <mkayaalp@linux.vnet.ibm.com> Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
show more ...
|
Revision tags: openbmc-20151123-1, openbmc-20151118-1, openbmc-20151104-1, v4.3, openbmc-20151102-1, openbmc-20151028-1 |
|
#
b479bfd0 |
| 27-Sep-2015 |
Ben Hutchings <ben@decadent.org.uk> |
DocBook: Use a fixed encoding for output
Currently the encoding of documents generated by DocBook depends on the current locale. Make the output reproducible independently of the locale, by setting
DocBook: Use a fixed encoding for output
Currently the encoding of documents generated by DocBook depends on the current locale. Make the output reproducible independently of the locale, by setting the encoding to UTF-8 (LC_CTYPE=C.UTF-8) by preference, or ASCII (LC_CTYPE=C) as a fallback.
LC_CTYPE can normally be overridden by LC_ALL, but the top-level Makefile unsets that.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk> [jc: added check-lc_ctype to .gitignore] Signed-off-by: Jonathan Corbet <corbet@lwn.net>
show more ...
|
Revision tags: v4.3-rc1, v4.2, v4.2-rc8, v4.2-rc7, v4.2-rc6, v4.2-rc5, v4.2-rc4 |
|
#
770f2b98 |
| 20-Jul-2015 |
David Woodhouse <David.Woodhouse@intel.com> |
modsign: Use extract-cert to process CONFIG_SYSTEM_TRUSTED_KEYS
Fix up the dependencies somewhat too, while we're at it.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Da
modsign: Use extract-cert to process CONFIG_SYSTEM_TRUSTED_KEYS
Fix up the dependencies somewhat too, while we're at it.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: David Howells <dhowells@redhat.com>
show more ...
|
#
1329e8cc |
| 20-Jul-2015 |
David Woodhouse <David.Woodhouse@intel.com> |
modsign: Extract signing cert from CONFIG_MODULE_SIG_KEY if needed
Where an external PEM file or PKCS#11 URI is given, we can get the cert from it for ourselves instead of making the user drop signi
modsign: Extract signing cert from CONFIG_MODULE_SIG_KEY if needed
Where an external PEM file or PKCS#11 URI is given, we can get the cert from it for ourselves instead of making the user drop signing_key.x509 in place for us.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: David Howells <dhowells@redhat.com>
show more ...
|
#
3f1e1bea |
| 20-Jul-2015 |
David Howells <dhowells@redhat.com> |
MODSIGN: Use PKCS#7 messages as module signatures
Move to using PKCS#7 messages as module signatures because:
(1) We have to be able to support the use of X.509 certificates that don't have a
MODSIGN: Use PKCS#7 messages as module signatures
Move to using PKCS#7 messages as module signatures because:
(1) We have to be able to support the use of X.509 certificates that don't have a subjKeyId set. We're currently relying on this to look up the X.509 certificate in the trusted keyring list.
(2) PKCS#7 message signed information blocks have a field that supplies the data required to match with the X.509 certificate that signed it.
(3) The PKCS#7 certificate carries fields that specify the digest algorithm used to generate the signature in a standardised way and the X.509 certificates specify the public key algorithm in a standardised way - so we don't need our own methods of specifying these.
(4) We now have PKCS#7 message support in the kernel for signed kexec purposes and we can make use of this.
To make this work, the old sign-file script has been replaced with a program that needs compiling in a previous patch. The rules to build it are added here.
Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: Vivek Goyal <vgoyal@redhat.com>
show more ...
|
Revision tags: v4.2-rc3, v4.2-rc2, v4.2-rc1, v4.1, v4.1-rc8, v4.1-rc7, v4.1-rc6, v4.1-rc5, v4.1-rc4, v4.1-rc3, v4.1-rc2, v4.1-rc1, v4.0, v4.0-rc7, v4.0-rc6, v4.0-rc5, v4.0-rc4, v4.0-rc3, v4.0-rc2, v4.0-rc1 |
|
#
3ee7b3fa |
| 17-Feb-2015 |
Jan Kiszka <jan.kiszka@siemens.com> |
scripts/gdb: add infrastructure
This provides the basic infrastructure to load kernel-specific python helper scripts when debugging the kernel in gdb.
The loading mechanism is based on gdb loading
scripts/gdb: add infrastructure
This provides the basic infrastructure to load kernel-specific python helper scripts when debugging the kernel in gdb.
The loading mechanism is based on gdb loading for <objfile>-gdb.py when opening <objfile>. Therefore, this places a corresponding link to the main helper script into the output directory that contains vmlinux.
The main scripts will pull in submodules containing Linux specific gdb commands and functions. To avoid polluting the source directory with compiled python modules, we link to them from the object directory.
Due to gdb.parse_and_eval and string redirection for gdb.execute, we depend on gdb >= 7.2.
This feature is enabled via CONFIG_GDB_SCRIPTS.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Acked-by: Michal Marek <mmarek@suse.cz> [kbuild stuff] Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Wessel <jason.wessel@windriver.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Borislav Petkov <bp@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
Revision tags: v3.19, v3.19-rc7, v3.19-rc6, v3.19-rc5, v3.19-rc4, v3.19-rc3, v3.19-rc2, v3.19-rc1, v3.18, v3.18-rc7, v3.18-rc6, v3.18-rc5, v3.18-rc4, v3.18-rc3, v3.18-rc2, v3.18-rc1, v3.17, v3.17-rc7, v3.17-rc6, v3.17-rc5, v3.17-rc4, v3.17-rc3, v3.17-rc2, v3.17-rc1 |
|
#
8370edea |
| 08-Aug-2014 |
Vivek Goyal <vgoyal@redhat.com> |
bin2c: move bin2c in scripts/basic
This patch series does not do kernel signature verification yet. I plan to post another patch series for that. Now distributions are already signing PE/COFF bzIm
bin2c: move bin2c in scripts/basic
This patch series does not do kernel signature verification yet. I plan to post another patch series for that. Now distributions are already signing PE/COFF bzImage with PKCS7 signature I plan to parse and verify those signatures.
Primary goal of this patchset is to prepare groundwork so that kernel image can be signed and signatures be verified during kexec load. This should help with two things.
- It should allow kexec/kdump on secureboot enabled machines.
- In general it can help even without secureboot. By being able to verify kernel image signature in kexec, it should help with avoiding module signing restrictions. Matthew Garret showed how to boot into a custom kernel, modify first kernel's memory and then jump back to old kernel and bypass any policy one wants to.
This patch (of 15):
Kexec wants to use bin2c and it wants to use it really early in the build process. See arch/x86/purgatory/ code in later patches.
So move bin2c in scripts/basic so that it can be built very early and be usable by arch/x86/purgatory/
Signed-off-by: Vivek Goyal <vgoyal@redhat.com> Cc: Borislav Petkov <bp@suse.de> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Eric Biederman <ebiederm@xmission.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Greg Kroah-Hartman <greg@kroah.com> Cc: Dave Young <dyoung@redhat.com> Cc: WANG Chao <chaowang@redhat.com> Cc: Baoquan He <bhe@redhat.com> Cc: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
Revision tags: v3.16, v3.16-rc7, v3.16-rc6, v3.16-rc5, v3.16-rc4, v3.16-rc3, v3.16-rc2, v3.16-rc1, v3.15, v3.15-rc8, v3.15-rc7, v3.15-rc6, v3.15-rc5, v3.15-rc4, v3.15-rc3, v3.15-rc2 |
|
#
c43cecad |
| 16-Apr-2014 |
Masahiro Yamada <yamada.m@jp.panasonic.com> |
kbuild: do not add "selinux" to subdir- twice
scripts/Makefile adds "selinux" to subdir-y or subdir- twice.
subdir-$(CONFIG_MODVERSIONS) += genksyms subdir-y += mod subdir
kbuild: do not add "selinux" to subdir- twice
scripts/Makefile adds "selinux" to subdir-y or subdir- twice.
subdir-$(CONFIG_MODVERSIONS) += genksyms subdir-y += mod subdir-$(CONFIG_SECURITY_SELINUX) += selinux <--- here subdir-$(CONFIG_DTC) += dtc
# Let clean descend into subdirs subdir- += basic kconfig package selinux <--- again
The latter is redundant.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
show more ...
|
Revision tags: v3.15-rc1, v3.14, v3.14-rc8, v3.14-rc7, v3.14-rc6, v3.14-rc5, v3.14-rc4, v3.14-rc3, v3.14-rc2, v3.14-rc1 |
|
#
bfdfaeae |
| 19-Jan-2014 |
Masahiro Yamada <yamada.m@jp.panasonic.com> |
kbuild: specify build_docproc as a phony target
PHONY target is more suitable for "build_docproc" target.
Because PHONY targets are always executed, they do not have to take FORCE as a prerequisite
kbuild: specify build_docproc as a phony target
PHONY target is more suitable for "build_docproc" target.
Because PHONY targets are always executed, they do not have to take FORCE as a prerequisite.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
show more ...
|
Revision tags: v3.13, v3.13-rc8, v3.13-rc7, v3.13-rc6, v3.13-rc5, v3.13-rc4, v3.13-rc3, v3.13-rc2, v3.13-rc1, v3.12, v3.12-rc7, v3.12-rc6, v3.12-rc5, v3.12-rc4, v3.12-rc3, v3.12-rc2, v3.12-rc1, v3.11, v3.11-rc7, v3.11-rc6, v3.11-rc5, v3.11-rc4, v3.11-rc3, v3.11-rc2, v3.11-rc1, v3.10, v3.10-rc7, v3.10-rc6, v3.10-rc5, v3.10-rc4, v3.10-rc3, v3.10-rc2, v3.10-rc1, v3.9, v3.9-rc8, v3.9-rc7, v3.9-rc6, v3.9-rc5, v3.9-rc4, v3.9-rc3, v3.9-rc2, v3.9-rc1, v3.8, v3.8-rc7, v3.8-rc6, v3.8-rc5, v3.8-rc4, v3.8-rc3, v3.8-rc2, v3.8-rc1, v3.7, v3.7-rc8, v3.7-rc7, v3.7-rc6, v3.7-rc5, v3.7-rc4, v3.7-rc3, v3.7-rc2, v3.7-rc1, v3.6, v3.6-rc7 |
|
#
4520c6a4 |
| 21-Sep-2012 |
David Howells <dhowells@redhat.com> |
X.509: Add simple ASN.1 grammar compiler
Add a simple ASN.1 grammar compiler. This produces a bytecode output that can be fed to a decoder to inform the decoder how to interpret the ASN.1 stream it
X.509: Add simple ASN.1 grammar compiler
Add a simple ASN.1 grammar compiler. This produces a bytecode output that can be fed to a decoder to inform the decoder how to interpret the ASN.1 stream it is trying to parse.
Action functions can be specified in the grammar by interpolating:
({ foo })
after a type, for example:
SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING ({ do_key_data }) }
The decoder is expected to call these after matching this type and parsing the contents if it is a constructed type.
The grammar compiler does not currently support the SET type (though it does support SET OF) as I can't see a good way of tracking which members have been encountered yet without using up extra stack space.
Currently, the grammar compiler will fail if more than 256 bytes of bytecode would be produced or more than 256 actions have been specified as it uses 8-bit jump values and action indices to keep space usage down.
Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
show more ...
|
Revision tags: v3.6-rc6, v3.6-rc5, v3.6-rc4, v3.6-rc3, v3.6-rc2, v3.6-rc1, v3.5, v3.5-rc7, v3.5-rc6, v3.5-rc5, v3.5-rc4, v3.5-rc3, v3.5-rc2, v3.5-rc1, v3.4, v3.4-rc7 |
|
#
6520fe55 |
| 08-May-2012 |
H. Peter Anvin <hpa@linux.intel.com> |
x86, realmode: 16-bit real-mode code support for relocs tool
A new option is added to the relocs tool called '--realmode'. This option causes the generation of 16-bit segment relocations and 32-bit
x86, realmode: 16-bit real-mode code support for relocs tool
A new option is added to the relocs tool called '--realmode'. This option causes the generation of 16-bit segment relocations and 32-bit linear relocations for the real-mode code. When the real-mode code is moved to the low-memory during kernel initialization, these relocation entries can be used to relocate the code properly.
In the assembly code 16-bit segment relocations must be relative to the 'real_mode_seg' absolute symbol. Linear relocations must be relative to a symbol prefixed with 'pa_'.
16-bit segment relocation is used to load cs:ip in 16-bit code. Linear relocations are used in the 32-bit code for relocatable data references. They are declared in the linker script of the real-mode code.
The relocs tool is moved to arch/x86/tools/relocs.c, and added new target archscripts that can be used to build scripts needed building an architecture. be compiled before building the arch/x86 tree.
[ hpa: accelerating this because it detects invalid absolute relocations, a serious bug in binutils 2.22.52.0.x which currently produces bad kernels. ]
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Link: http://lkml.kernel.org/r/1336501366-28617-2-git-send-email-jarkko.sakkinen@intel.com Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@intel.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Cc: <stable@vger.kernel.org>
show more ...
|