[PATCH v3 0/2] filter_seccomp: new bpf generation strategy
Dmitry V. Levin
ldv at altlinux.org
Mon Nov 4 12:14:12 UTC 2019
On Mon, Nov 04, 2019 at 12:36:07PM +0100, Paul Chaignon wrote:
> On Sun, Nov 03, 2019 at 07:01:24PM +0300, Dmitry V. Levin wrote:
> > On Thu, Oct 31, 2019 at 08:55:12PM +0100, Paul Chaignon wrote:
> > We still can do better with test coverage of these new features, though.
> Any specific cases you'd like us to test?
> The third test case in tests/filter_seccomp.in should already be
> triggering the use of the new binary match strategy. (Not that I think
> it's enough.)
From the test coverage I can see that bpf code is generated both for
linear and binary match strategies, and at least one of these strategies
generates bpf code that passes tests. As far as I can tell, there is no
way to see whether the bpf code generated e.g. by the new binary match
strategy is actually tested.
> Some of the corner cases are also a bit hard to test (e.g., jump offset
> overflow and oversized filter) because I currently am unable to come up
> with a trace set that triggers them.
Could you prove they cannot be triggered? ;)
> I had a look at the Codecov reporting, but it looks kinda weird:
> exec_or_die() is supposedly never executed, as if Codecov is only tracing
> the tracer process...?
This looks rather like a bug in gcov used in the travis build (maybe
the gcc version is too old) because in local coverage tests I see that
exec_or_die is covered.
When gcc --coverage (or analogue) is used, it wraps all forks and execs
in a special way, see
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: not available
More information about the Strace-devel