| Age | Commit message (Collapse) | Author |
|---|
|
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 <heiko.carstens@de.ibm.com>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: James Morris <james.l.morris@oracle.com>
|
|
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 <heiko.carstens@de.ibm.com>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: James Morris <james.l.morris@oracle.com>
|
|
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 <chad@dahc.us>
Reviewed-By: Will Drewry <wad@chromium.org>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: James Morris <james.l.morris@oracle.com>
|
|
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 <paul.gortmaker@windriver.com>
Suggested-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Will Drewry <wad@chromium.org>
Signed-off-by: James Morris <james.l.morris@oracle.com>
|
|
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 <eparis@redhat.com>
Signed-off-by: Will Drewry <wad@chromium.org>
Acked-by: Kees Cook <keescook@chromium.org>
v18: - 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 <james.l.morris@oracle.com>
|
