[PATCH RFC 0/9] filter_seccomp: new bpf generation strategies
Dmitry V. Levin
ldv at altlinux.org
Fri Oct 25 20:18:29 UTC 2019
On Wed, Oct 16, 2019 at 05:38:43PM +0200, Paul Chaignon wrote:
> Hi all,
> On Fri, Aug 23, 2019 at 11:42 AM Paul Chaignon <paul.chaignon at gmail.com>
> > 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
Why do you suggest to drop the reverse linear strategy?
It wins over the current linear strategy sometimes, and
its implementation is similar to the linear strategy.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: not available
More information about the Strace-devel