[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