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
09 Jan, 2017
1 commit
-
There were some bugs in the JNE64 and JLT64 comparision macros. This fixes
them, improves comments, and cleans up the file while we are at it.Reported-by: Stephen Röttger
Signed-off-by: Mathias Svensson
Signed-off-by: Kees Cook
Cc: stable@vger.kernel.org
Signed-off-by: James Morris
01 Nov, 2016
3 commits
-
Previously, the program size was incorrectly truncated to 8 bits,
resulting in broken labels in large programs. Also changes the jump
resolution loop to not rely on undefined behavior (making a pointer
point before the filter array).Signed-off-by: Ricky Zhou
Signed-off-by: Kees Cook -
Either CAP_SYS_ADMIN or PR_SET_NO_NEW_PRIVS is required to enable
seccomp. This allows samples/seccomp/dropper to be run without
CAP_SYS_ADMIN.Signed-off-by: Ricky Zhou
Signed-off-by: Kees Cook -
In f6041c1d, a separate SAMPLES_SECCOMP option was added. This changed
hostprogs-y to hostprogs-m, so adjust it.Signed-off-by: Ricky Zhou
Signed-off-by: Kees Cook
08 Jul, 2016
1 commit
-
Add a separate Kconfig option for SAMPLES_SECCOMP.
Main reason for this is that, just like other samples, it's forced to
be a module.Without this, since the sample is a target only controlled by
CONFIG_SECCOMP_FILTER, the samples will be built before include files are
put in place properly. For example, from an arm64 allmodconfig built with
"make -sk -j 32" (without specific target), the following happens:samples/seccomp/bpf-fancy.c:13:27: fatal error: linux/seccomp.h: No such file or directory
samples/seccomp/bpf-helper.h:20:50: fatal error: linux/seccomp.h: No such file or directory
samples/seccomp/dropper.c:20:27: fatal error: linux/seccomp.h: No such file or directory
samples/seccomp/bpf-direct.c:21:27: fatal error: linux/seccomp.h: No such file or directorySo, just stick to the same format as other samples.
Signed-off-by: Olof Johansson
Signed-off-by: Kees Cook
18 Feb, 2015
1 commit
-
Fixes a potential corruption with uninitialized stack memory in the
seccomp BPF sample program.[akpm@linux-foundation.org: coding-style fixlet]
Signed-off-by: Kees Cook
Reported-by: Robert Swiecki
Tested-by: Robert Swiecki
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
04 Apr, 2014
1 commit
-
The Makefile is designed to use the host toolchain so it may be unsafe
to build the tests if the kernel has been configured and built for
another architecture. This fixes a build problem when the kernel has
been configured and built for the MIPS architecture but the host is not
MIPS (cross-compiled). The MIPS syscalls are only defined if one of the
following is true:1) _MIPS_SIM == _MIPS_SIM_ABI64
2) _MIPS_SIM == _MIPS_SIM_ABI32
3) _MIPS_SIM == _MIPS_SIM_NABI32Of course, none of these make sense on a non-MIPS toolchain and the
following build problem occurs when building on a non-MIPS host.linux/usr/include/linux/kexec.h:50: userspace cannot reference function or variable defined in the kernel
samples/seccomp/bpf-direct.c: In function `emulator':
samples/seccomp/bpf-direct.c:76:17: error: `__NR_write' undeclared (first use in this function)Signed-off-by: Markos Chandras
Reported-by: Paul Gortmaker
Cc: Ralf Baechle
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
05 Feb, 2013
1 commit
-
The seccomp filters are currently built for the build host, not for the
machine that they are going to run on, but they are also built for with
the -m32 flag if the kernel is built for a 32 bit machine, both of which
seems rather odd.It broke allyesconfig on my machine, which is x86-64, but building for
32 bit ARM, with this error message:In file included from /usr/include/stdio.h:28:0,
from samples/seccomp/bpf-fancy.c:15:
/usr/include/features.h:324:26: fatal error: bits/predefs.h: No such file or directorybecause there are no 32 bit libc headers installed on this machine. We
should really be building all the samples for the target machine rather
than the build host, but since the infrastructure for that appears to be
missing right now, let's be a little bit smarter and not pass the '-m32'
flag to the HOSTCC when cross- compiling.Signed-off-by: Arnd Bergmann
Acked-by: Kees Cook
Cc: Heiko Carstens
Cc: James Morris
Acked-by: Will Drewry
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
12 Sep, 2012
1 commit
-
On s390 the flag to force 31 builds is -m31 instead of -m32 unlike
on all (?) other architectures.Fixes this compile error:
HOSTCC samples/seccomp/bpf-direct.o
cc1: error: unrecognized command line option "-m32"
make[2]: *** [samples/seccomp/bpf-direct.o] Error 1Signed-off-by: Heiko Carstens
Acked-by: Kees Cook
Signed-off-by: James Morris
03 Aug, 2012
1 commit
-
The LO_ARG define needs to consider endianness also for 32 bit builds.
The "bpf_fancy" test case didn't work on s390 in 32 bit and compat mode
because the LO_ARG define resulted in a BPF program which read the upper
halve of the 64 bit system call arguments instead of the lower halves.Signed-off-by: Heiko Carstens
Acked-by: Kees Cook
Signed-off-by: James Morris
28 Jun, 2012
1 commit
-
git status should be clean following make allmodconfig && make. Add
a .gitignore file to the samples/seccomp directory to ignore binaries
produced there.Signed-off-by: Chad Williamson
Reviewed-By: Will Drewry
Acked-by: Kees Cook
Signed-off-by: James Morris
19 Apr, 2012
1 commit
-
This change fixes the compilation error triggered here for
i386 allmodconfig in linux-next:
http://kisskb.ellerman.id.au/kisskb/buildresult/6123842/Logic attempting to predict the host architecture has been
removed from the Makefile. Instead, the bpf-direct sample
should now compile on any architecture, but if the architecture
is not supported, it will compile a minimal main() function.This change also ensures the samples are not compiled when
there is no seccomp filter support.(Note, I wasn't able to reproduce the error locally, but
the existing approach was clearly flawed. This tweak
should resolve your issue and avoid other future weirdness.)Reported-by: Paul Gortmaker
Suggested-by: Kees Cook
Signed-off-by: Will Drewry
Signed-off-by: James Morris
14 Apr, 2012
1 commit
-
Documents how system call filtering using Berkeley Packet
Filter programs works and how it may be used.
Includes an example for x86 and a semi-generic
example using a macro-based code generator.Acked-by: Eric Paris
Signed-off-by: Will Drewry
Acked-by: Kees Cookv18: - added acked by
- update no new privs numbers
v17: - remove @compat note and add Pitfalls section for arch checking
(keescook@chromium.org)
v16: -
v15: -
v14: - rebase/nochanges
v13: - rebase on to 88ebdda6159ffc15699f204c33feb3e431bf9bdc
v12: - comment on the ptrace_event use
- update arch support comment
- note the behavior of SECCOMP_RET_DATA when there are multiple filters
(keescook@chromium.org)
- lots of samples/ clean up incl 64-bit bpf-direct support
(markus@chromium.org)
- rebase to linux-next
v11: - overhaul return value language, updates (keescook@chromium.org)
- comment on do_exit(SIGSYS)
v10: - update for SIGSYS
- update for new seccomp_data layout
- update for ptrace option use
v9: - updated bpf-direct.c for SIGILL
v8: - add PR_SET_NO_NEW_PRIVS to the samples.
v7: - updated for all the new stuff in v7: TRAP, TRACE
- only talk about PR_SET_SECCOMP now
- fixed bad JLE32 check (coreyb@linux.vnet.ibm.com)
- adds dropper.c: a simple system call disabler
v6: - tweak the language to note the requirement of
PR_SET_NO_NEW_PRIVS being called prior to use. (luto@mit.edu)
v5: - update sample to use system call arguments
- adds a "fancy" example using a macro-based generator
- cleaned up bpf in the sample
- update docs to mention arguments
- fix prctl value (eparis@redhat.com)
- language cleanup (rdunlap@xenotime.net)
v4: - update for no_new_privs use
- minor tweaks
v3: - call out BPF Berkeley Packet Filter (rdunlap@xenotime.net)
- document use of tentative always-unprivileged
- guard sample compilation for i386 and x86_64
v2: - move code to samples (corbet@lwn.net)
Signed-off-by: James Morris