I'm pretty sure this is our largest patch set since the original kernelcontribution, and it's certainly the one with the most contributors.While I don't have anything else I know I'm going to submit for themerge window, I would be somewhat surprised if I didn't screw anythingup.

Hi Palmer,Do you plan to land wip-seccomp in 4.20?http://lists.infradead.org/pipermail/linux-riscv/2018-August/001182.htmldavid

I've updated the patches to live on top of 4.19 as well as cleaning upthe Kconfig entry. Unless anyone has any comments I'll add them tofor-next and submit a PR next week.

+config SECCOMP+ bool "Enable seccomp to safely compute untrusted bytecode"++ help+ This kernel feature is useful for number crunching applications+ that may need to compute untrusted bytecode during their+ execution. By using pipes or other transports made available to+ the process as file descriptors supporting the read/write+ syscalls, it's possible to isolate those applications in+ their own address space using seccomp. Once seccomp is+ enabled via prctl(PR_SET_SECCOMP), it cannot be disabled+ and the task is only allowed to execute a few safe syscalls+ defined by each seccomp mode.++ If unsure, say Y. Only embedded should say N here.+endmenu

config HAVE_ARCH_SECCOMP_FILTERboolhelpAn arch should select this symbol if it provides all of these things:- syscall_get_arch()- syscall_get_arguments()- syscall_rollback()- syscall_set_return_value()- SIGSYS siginfo_t support- secure_computing is called from a ptrace_event()-safe context- secure_computing return value is checked and a return value of -1results in the system call being skipped immediately.- seccomp syscall wired up

I only see syscall_get_arch(). Nothing is using TIF_SECCOMP (I'dexpect a masked check in entry.S -- it seems like tracepoints aregetting missed too? I see it handled in ptrace.c but not checked inentry.S?) There's no checking for seccomp in ptrace.c, etc.

At the very least, I think the Kconfigs should not be included in thispatch. The other things are needed, but without everything else,seccomp isn't actually available. :)

Reading the per-arch Kconfigs, I am reminded I still need to moveCONFIG_SECCOMP up into arch/Kconfig. :P

Post by Kees Cookconfig HAVE_ARCH_SECCOMP_FILTERboolhelp- syscall_get_arch()- syscall_get_arguments()- syscall_rollback()- syscall_set_return_value()- SIGSYS siginfo_t support- secure_computing is called from a ptrace_event()-safe context- secure_computing return value is checked and a return value of -1results in the system call being skipped immediately.- seccomp syscall wired up

Oh, and I should add to this list, "passestools/testing/selftests/seccomp/seccomp_bpf test". :)

I think this patch is missing most of the actual seccomp glue?config HAVE_ARCH_SECCOMP_FILTERboolhelp- syscall_get_arch()- syscall_get_arguments()- syscall_rollback()- syscall_set_return_value()- SIGSYS siginfo_t support- secure_computing is called from a ptrace_event()-safe context- secure_computing return value is checked and a return value of -1results in the system call being skipped immediately.- seccomp syscall wired upI only see syscall_get_arch(). Nothing is using TIF_SECCOMP (I'dexpect a masked check in entry.S -- it seems like tracepoints aregetting missed too? I see it handled in ptrace.c but not checked inentry.S?) There's no checking for seccomp in ptrace.c, etc.

Hi RISC-V people:

I strongly, strongly suggest that you rewrite your asm to work the waythat x86's does: have a function called prepare_exit_to_usermode() andmake it work more or less like x86's. Doing all the exit work in asmlike you are is just setting you up for a world of pain.

FYI, while small and far from comprehensive, we do have a test suitewe use for basic validation of the audit kernel bits which may be* https://github.com/linux-audit/audit-testsuite

Currently I checked the following to work:- /proc/self/loginuid (required by DNF [package manager])- auditctl (checked several different example rules from internet)- aulast- aulastlog- ausearch- ausyscall- aureport- autrace (compared some syscalls to strace: order andreturn value/input arguments seems to be correct)

I checked audit-testsuite yesterday and it seems to be only forx86-64 / x86-32. After adjusting it (MODE, syscalls) I am at:

Failed 4/14 test programs. 19/88 subtests failed.

I don't plan to look further in the failure, e.g.:- syscall_socketcall: that's an old stuff and not relevant tonew arches- syscall_module: Fedora kernel currently is not compiledwith kernel loadable module support- filter_exclude: two tests fail because id -Z doesn't printany categories, but "semanage login -l" output is identicalbetween x86_64 and riscv64- netfilter_pkt: don't have CONFIG_IP_NF_MANGLE enabled

Fedora kernel currently has minimal CONFIG_* optionsand is built without loadable module support.

I think this patch is missing most of the actual seccomp glue?config HAVE_ARCH_SECCOMP_FILTERboolhelp- syscall_get_arch()- syscall_get_arguments()- syscall_rollback()- syscall_set_return_value()- SIGSYS siginfo_t support- secure_computing is called from a ptrace_event()-safe context- secure_computing return value is checked and a return value of -1results in the system call being skipped immediately.- seccomp syscall wired upI only see syscall_get_arch(). Nothing is using TIF_SECCOMP (I'dexpect a masked check in entry.S -- it seems like tracepoints aregetting missed too? I see it handled in ptrace.c but not checked inentry.S?) There's no checking for seccomp in ptrace.c, etc.

I strongly, strongly suggest that you rewrite your asm to work the waythat x86's does: have a function called prepare_exit_to_usermode() andmake it work more or less like x86's. Doing all the exit work in asmlike you are is just setting you up for a world of pain.

OK, thanks for the suggestion. Next time we have to change it I'll try to takea look and figure out something sane.