When oz-seccomp-trainer generates a candidate seccomp-bpf policy, the order of the system calls in the seccomp-bpf checks compiled into bytecode is based on observed invocation frequency. This improved performance noticeably over a random/arbitrary order.
However, this isn't necessarily true for checks within the context of a single system call, i.e. when there are multiple evaluations of a syscall + argument set. We can possibly improve policy evaluation time and achieve (hopefully) perceptible performance improvement in some applications (video player) by counting invocation frequency of syscall + argument, and then constructing the policy code in evaluation order descending by observed frequency.
Some preliminary testing:
oz-seccomp-trainer policy entry for futex(2):
futex: (arg1 == FUTEX_WAIT) || (arg1 &? FUTEX_WAKE|FUTEX_FD|FUTEX_REQUEUE|FUTEX_CMP_REQUEUE|FUTEX_WAKE_OP|FUTEX_LOCK_PI|FUTEX_UNLOCK_PI|FUTEX_PRIVATE_FLAG) || (arg1 &? FUTEX_WAKE|FUTEX_FD|FUTEX_REQUEUE|FUTEX_TRYLOCK_PI|FUTEX_WAIT_BITSET|FUTEX_WAKE_BITSET|FUTEX_WAIT_REQUEUE_PI|FUTEX_PRIVATE_FLAG) || (arg1 &? FUTEX_CMP_REQUEUE|FUTEX_TRYLOCK_PI|FUTEX_CMP_REQUEUE_PI|FUTEX_PRIVATE_FLAG) || (arg1 &? FUTEX_WAKE|FUTEX_TRYLOCK_PI|FUTEX_WAIT_BITSET|FUTEX_PRIVATE_FLAG|FUTEX_CLOCK_REALTIME)
user@subgraph:/home/user/go/src/github.com/subgraph/oz$ grep futex ~/mpv-futex-test2.out | grep -v seccomp| cut -d , -f2|sort|uniq
FUTEX_CMP_REQUEUE_PI_PRIVATE
FUTEX_CMP_REQUEUE_PRIVATE
FUTEX_LOCK_PI_PRIVATE
FUTEX_UNLOCK_PI
FUTEX_UNLOCK_PI_PRIVATE
FUTEX_WAIT
FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME
FUTEX_WAIT_PRIVATE
FUTEX_WAIT_REQUEUE_PI_PRIVATE
FUTEX_WAKE_OP_PRIVATE
FUTEX_WAKE_PRIVATE
user@subgraph:/home/user/go/src/github.com/subgraph/oz$ grep FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, ~/mpv-futex-test2.out |wc -l
5398
user@subgraph:/home/user/go/src/github.com/subgraph/oz$ grep FUTEX_UNLOCK_PI_PRIVATE /home/user/mpv-futex-test2.out |wc -l
2575
user@subgraph:/home/user/go/src/github.com/subgraph/oz$ grep FUTEX_UNLOCK_PI /home/user/mpv-futex-test2.out |wc -l
2576
user@subgraph:/home/user/go/src/github.com/subgraph/oz$ grep FUTEX_UNLOCK_PI_PRIVATE /home/user/mpv-futex-test2.out |wc -l
2575
user@subgraph:/home/user/go/src/github.com/subgraph/oz$ grep FUTEX_CMP_REQUEUE_PRIVATE /home/user/mpv-futex-test2.out |wc -l
7487
user@subgraph:/home/user/go/src/github.com/subgraph/oz$ grep FUTEX_CMP_REQUEUE_PI_PRIVATE, /home/user/mpv-futex-test2.out |wc -l
215
user@subgraph:/home/user/go/src/github.com/subgraph/oz$ grep FUTEX_WAIT_PRIVATE /home/user/mpv-futex-test2.out |wc -l
15113
user@subgraph:/home/user/go/src/github.com/subgraph/oz$ grep FUTEX_WAKE_OP_PRIVATE /home/user/mpv-futex-test2.out |wc -l
4278
user@subgraph:/home/user/go/src/github.com/subgraph/oz$ grep FUTEX_WAKE_PRIVATE /home/user/mpv-futex-test2.out |wc -l
23181
When oz-seccomp-trainer generates a candidate seccomp-bpf policy, the order of the system calls in the seccomp-bpf checks compiled into bytecode is based on observed invocation frequency. This improved performance noticeably over a random/arbitrary order.
However, this isn't necessarily true for checks within the context of a single system call, i.e. when there are multiple evaluations of a syscall + argument set. We can possibly improve policy evaluation time and achieve (hopefully) perceptible performance improvement in some applications (video player) by counting invocation frequency of syscall + argument, and then constructing the policy code in evaluation order descending by observed frequency.
Some preliminary testing:
oz-seccomp-trainer policy entry for futex(2):
futex: (arg1 == FUTEX_WAIT) || (arg1 &? FUTEX_WAKE|FUTEX_FD|FUTEX_REQUEUE|FUTEX_CMP_REQUEUE|FUTEX_WAKE_OP|FUTEX_LOCK_PI|FUTEX_UNLOCK_PI|FUTEX_PRIVATE_FLAG) || (arg1 &? FUTEX_WAKE|FUTEX_FD|FUTEX_REQUEUE|FUTEX_TRYLOCK_PI|FUTEX_WAIT_BITSET|FUTEX_WAKE_BITSET|FUTEX_WAIT_REQUEUE_PI|FUTEX_PRIVATE_FLAG) || (arg1 &? FUTEX_CMP_REQUEUE|FUTEX_TRYLOCK_PI|FUTEX_CMP_REQUEUE_PI|FUTEX_PRIVATE_FLAG) || (arg1 &? FUTEX_WAKE|FUTEX_TRYLOCK_PI|FUTEX_WAIT_BITSET|FUTEX_PRIVATE_FLAG|FUTEX_CLOCK_REALTIME)
user@subgraph:/home/user/go/src/github.com/subgraph/oz$ grep futex ~/mpv-futex-test2.out | grep -v seccomp| cut -d , -f2|sort|uniq
FUTEX_CMP_REQUEUE_PI_PRIVATE
FUTEX_CMP_REQUEUE_PRIVATE
FUTEX_LOCK_PI_PRIVATE
FUTEX_UNLOCK_PI
FUTEX_UNLOCK_PI_PRIVATE
FUTEX_WAIT
FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME
FUTEX_WAIT_PRIVATE
FUTEX_WAIT_REQUEUE_PI_PRIVATE
FUTEX_WAKE_OP_PRIVATE
FUTEX_WAKE_PRIVATE
user@subgraph:/home/user/go/src/github.com/subgraph/oz$ grep FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, ~/mpv-futex-test2.out |wc -l
5398
user@subgraph:/home/user/go/src/github.com/subgraph/oz$ grep FUTEX_UNLOCK_PI_PRIVATE /home/user/mpv-futex-test2.out |wc -l
2575
user@subgraph:/home/user/go/src/github.com/subgraph/oz$ grep FUTEX_UNLOCK_PI /home/user/mpv-futex-test2.out |wc -l
2576
user@subgraph:/home/user/go/src/github.com/subgraph/oz$ grep FUTEX_UNLOCK_PI_PRIVATE /home/user/mpv-futex-test2.out |wc -l
2575
user@subgraph:/home/user/go/src/github.com/subgraph/oz$ grep FUTEX_CMP_REQUEUE_PRIVATE /home/user/mpv-futex-test2.out |wc -l
7487
user@subgraph:/home/user/go/src/github.com/subgraph/oz$ grep FUTEX_CMP_REQUEUE_PI_PRIVATE, /home/user/mpv-futex-test2.out |wc -l
215
user@subgraph:/home/user/go/src/github.com/subgraph/oz$ grep FUTEX_WAIT_PRIVATE /home/user/mpv-futex-test2.out |wc -l
15113
user@subgraph:/home/user/go/src/github.com/subgraph/oz$ grep FUTEX_WAKE_OP_PRIVATE /home/user/mpv-futex-test2.out |wc -l
4278
user@subgraph:/home/user/go/src/github.com/subgraph/oz$ grep FUTEX_WAKE_PRIVATE /home/user/mpv-futex-test2.out |wc -l
23181