https://bugs.kde.org/show_bug.cgi?id=345414
Miroslav Franc <mfr...@gmx.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mfr...@gmx.com
--- Comment #12 from Miroslav Franc <mfr...@gmx.com> ---
Created attachment 160505
--> https://bugs.kde.org/attachment.cgi?id=160505&action=edit
--disable-seccomp=yes feature
I propose an option --disable-seccomp=[no|yes] feature to Valgrind, which would
fake "seccomp" syscall (and an old style "prctl(PR_SET_SECCOMP...)") success if
set to "yes" and would otherwise default to "no".
"prctl" case remains the same unless "yes" is selected and "seccomp" case now
returns ENOSYS unless "yes" is selected.
The patch also adds the option to the --help output, man page, and
"none/tests/linux/seccomp" test case to the testsuite.
The usecase is that some programs only allow switching seccomp off at compile
time. This way, they can be analyzed without recompilation (at the cost of
sandboxing being turned off, because Valgrind is efefctivelly faking seccomp
filter installation without doing anything). The proper emulation of the
seccomp feature is impossible since Linux kernel doesn't allow switching
between two different filters dynamically and partial solution with Valgrind
analyzing cBPF program and whitelisting syscalls it needs for itself is too
much work for very little gain.
I tested the patch with the entire testsuite on x86_64 and s390x architectures
(OpenSUSE Tumbleweed).
Expected behaviour:
$ valgrind -q --disable-seccomp=yes file /etc/passwd
/etc/passwd: ASCII text
$ valgrind -q --disable-seccomp=no file /etc/passwd
Bad system call
$ valgrind -q file /etc/passwd
Bad system call
$ perl tests/vg_regtest none/tests/linux/seccomp
seccomp: valgrind -q --disable-seccomp=yes ./seccomp
== 1 test, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB
failures, 0 post failures ==
--
You are receiving this mail because:
You are watching all bug changes.
