[PATCH RFC 0/9] filter_seccomp: new bpf generation strategies

[Dmitry V. Levin]

Hi,

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> 
> 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

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.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20191025/72181b79/attachment.bin>