linux-toradex.git/samples/seccomp, branch v4.14-rc3

samples/seccomp: fix 64-bit comparison macros

2017-01-09T06:22:03+00:00

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

samples/seccomp: Support programs with >256 instructions

2016-11-01T15:58:17+00:00

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

samples/seccomp: Enable PR_SET_NO_NEW_PRIVS in dropper

2016-11-01T15:58:10+00:00

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

samples/seccomp: Fix hostprogs variable

2016-11-01T15:57:42+00:00

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

samples/seccomp: Add standalone config option

2016-07-07T17:58:03+00:00

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 directory

So, just stick to the same format as other samples.

Signed-off-by: Olof Johansson 
Signed-off-by: Kees Cook

samples/seccomp: improve label helper

2015-02-17T22:34:55+00:00

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

samples/seccomp/Makefile: do not build tests if cross-compiling for MIPS

2014-04-03T23:21:06+00:00

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_NABI32

Of 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

samples/seccomp: be less stupid about cross compiling

2013-02-05T09:38:49+00:00

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 directory

because 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

samples/seccomp: fix 31 bit build on s390

2012-09-12T02:55:31+00:00

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 1

Signed-off-by: Heiko Carstens 
Acked-by: Kees Cook 
Signed-off-by: James Morris

samples/seccomp: fix endianness bug in LO_ARG define

2012-08-03T04:27:40+00:00

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