16 Jun, 2018
1 commit
-
As we move stuff around, some doc references are broken. Fix some of
them via this script:
./scripts/documentation-file-ref-check --fixManually checked if the produced result is valid, removing a few
false-positives.Acked-by: Takashi Iwai
Acked-by: Masami Hiramatsu
Acked-by: Stephen Boyd
Acked-by: Charles Keepax
Acked-by: Mathieu Poirier
Reviewed-by: Coly Li
Signed-off-by: Mauro Carvalho Chehab
Acked-by: Jonathan Corbet
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
03 Apr, 2017
1 commit
-
Add the following:
(1) A new system keyring that is used to store information about
blacklisted certificates and signatures.(2) A new key type (called 'blacklist') that is used to store a
blacklisted hash in its description as a hex string. The key accepts
no payload.(3) The ability to configure a list of blacklisted hashes into the kernel
at build time. This is done by setting
CONFIG_SYSTEM_BLACKLIST_HASH_LIST to the filename of a list of hashes
that are in the form:"", "", ..., ""
where each is a hex string representation of the hash and must
include all necessary leading zeros to pad the hash to the right size.The above are enabled with CONFIG_SYSTEM_BLACKLIST_KEYRING.
Once the kernel is booted, the blacklist keyring can be listed:
root@andromeda ~]# keyctl show %:.blacklist
Keyring
723359729 ---lswrv 0 0 keyring: .blacklist
676257228 ---lswrv 0 0 \_ blacklist: 123412341234c55c1dcc601ab8e172917706aa32fb5eaf826813547fdf02dd46The blacklist cannot currently be modified by userspace, but it will be
possible to load it, for example, from the UEFI blacklist database.A later commit will make it possible to load blacklisted asymmetric keys in
here too.Signed-off-by: David Howells
12 Apr, 2016
2 commits
-
Add a secondary system keyring that can be added to by root whilst the
system is running - provided the key being added is vouched for by a key
built into the kernel or already added to the secondary keyring.Rename .system_keyring to .builtin_trusted_keys to distinguish it more
obviously from the new keyring (called .secondary_trusted_keys).The new keyring needs to be enabled with CONFIG_SECONDARY_TRUSTED_KEYRING.
If the secondary keyring is enabled, a link is created from that to
.builtin_trusted_keys so that the the latter will automatically be searched
too if the secondary keyring is searched.Signed-off-by: David Howells
-
Make the system trusted keyring depend on the asymmetric key type as
there's not a lot of point having it if you can't then load asymmetric keys
onto it.This requires the ASYMMETRIC_KEY_TYPE to be made a bool, not a tristate, as
the Kconfig language doesn't then correctly force ASYMMETRIC_KEY_TYPE to
'y' rather than 'm' if SYSTEM_TRUSTED_KEYRING is 'y'.Making SYSTEM_TRUSTED_KEYRING *select* ASYMMETRIC_KEY_TYPE instead doesn't
work as the Kconfig interpreter then wrongly complains about dependency
loops.Signed-off-by: David Howells
26 Feb, 2016
1 commit
-
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 -c
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
Signed-off-by: David Howells
Acked-by: Mimi Zohar
14 Aug, 2015
1 commit
-
Move certificate handling out of the kernel/ directory and into a certs/
directory to get all the weird stuff in one place and move the generated
signing keys into this directory.Signed-off-by: David Howells
Reviewed-by: David Woodhouse