https://bugs.kde.org/show_bug.cgi?id=345414
--- Comment #17 from Miroslav Franc <mfr...@gmx.com> --- (In reply to Mark Wielaard from comment #15) > Also note this patch that implements more of seccomp: > https://sourceforge.net/p/valgrind/mailman/message/46305485/ To be honest. I was not trying to implement seccomp. I was trying to find a way to turn it off. :-) I took a look at the patch from the mailing list. Seeing "[PATCH 1/2]", is there a second part to it? I see only one. I'm not subscribed to valgrind-devel and the sourceforge web interface isn't the nicest one I have seen. If I read the valgrind-devel patch correctly, it does... for SECCOMP_SET_MODE_STRICT 1/ make seccomp call visible two --trace-syscalls=yes 2/ say nothing about it's arguments for SECCOMP_SET_MODE_FILTER 1/ make seccomp call visible two --trace-syscalls=yes 2/ tell valgrind it reads 3 arguments from registers 3/ tell valgrind it reads a memory from the third argument pointer (size of 1?) I doesn't deal with SECCOMP_GET_ACTION_AVAIL and SECCOMP_GET_NOTIF_SIZES at all. In other words it does slightly less then what is currently being done for the same operations invoked via older prctl syscall, because that tells valgrind it reads 2 arguments from registers in case of SECCOMP_MODE_STRICT additionally. To be fair, strict mode is a lost cause anyway for the simplests of programs, unless they are specifically designed to run in it. It breaks even "int main(void) {}" if you link against glibc, since glibc started invoking exit_group(0) for all programs at some point (which is a syscall not allowed in seccomp strict mode). When I was writing the patch, I tried to preserve the prctl syscall case while mark seccomp syscall as unimplemented. What I could do is basically copy paste the prctl syscall case onto seccomp syscall case and tweak it and see how to handle additional SECCOMP_GET_ACTION_AVAIL and SECCOMP_GET_NOTIF_SIZES operations. -- You are receiving this mail because: You are watching all bug changes.
