[PATCH RFC 0/9] filter_seccomp: new bpf generation strategies
Paul Chaignon
paul.chaignon at gmail.com
Wed Oct 16 15:38:43 UTC 2019
Hi all,
On Fri, Aug 23, 2019 at 11:42 AM Paul Chaignon <paul.chaignon at gmail.com>
wrote:
[...]
> x86-64:
> best lin. rev. bin.
> none lin. 36 47 84
> ptrace lin. 39 51 88
> !ptrace rev. 32 23 66
> %desc bin. 239 274 172
> %file bin. 173 213 172
> %fstat lin. 44 63 107
> %ipc lin. 49 63 111
> !%ipc rev. 42 33 87
> %lstat lin. 41 57 96
> %memory,%ipc,%pure,%signal,%network bin. 193 246 176
[...]
> First, one can note that the winning strategy for a given filter is the
> same across all architectures, because the strategies don't impact the
> arch-specific part of the bytecode. The reverse linear strategy is the
> most efficient only when almost all syscalls are being traced, and
> generally by a small amount compared to the linear strategy. The binary
> match strategy is most efficient when there's a large number of traced
> syscalls. Finally, all generated programs are far below both BPF_MAXINSNS
> and the maximum conditional jump offset.
>
> From these evaluations, it's not clear whether the reverse linear strategy
> is worth keeping? The binary match strategy may be worth keeping, but
> probably not its optimization; I think it adds unnecessary complexity, as
> it optimizes cases for which the linear strategy is more efficient anyway.
I'm preparing to send a rebased v2 for this patchset. Given the above
numbers, I will likely drop the reverse linear strategy (patch 7/9) and
the optimizations to the binary match strategy (patch 9/9). Unless
someone thinks I should proceed differently? Also, don't hesitate to ask
if you want to see different evaluations.
Paul
More information about the Strace-devel
mailing list