seccomp filter overhead is O(n) in the worst case where n is the amount of system calls included in the filter.
This can be partially compensated by reordering BPF instructions in a way that checks for more-often-used calls first. libseccomp provides API for that (rule priorities).
Two possible way to implement it:
A. Assign priorities depending on common expectations (e.g. futex first, then I/O calls, then file and network I/O, also mmap somewhere).
B. Assign priorities depending on the order calls are specified in arguments/configuration and thus leave this job to the policy author.
seccomp filter overhead is O(n) in the worst case where n is the amount of system calls included in the filter.
This can be partially compensated by reordering BPF instructions in a way that checks for more-often-used calls first. libseccomp provides API for that (rule priorities).
Two possible way to implement it:
A. Assign priorities depending on common expectations (e.g. futex first, then I/O calls, then file and network I/O, also mmap somewhere).
B. Assign priorities depending on the order calls are specified in arguments/configuration and thus leave this job to the policy author.