Introducing new filtering architecture.

[Nikolay Marchuk]

On 06.06.2017 00:14, Eugene Syromiatnikov wrote:
>> where action is equal with 'qualifier',
> As Masatake pointed out already, it is probably a good idea to include
> backtrace printing to a list of possible actions. I suggest "backtrace",
> "stacktrace" or "callstack" as a possible name for it. The same goes for
> path tracing, since there is no specific qualifier for it at the moment,
> one has to be chosen (like "path").
I described only basic filtering architecture, which allows adding of
new filters or actions without changing the common way of processing.
Useful actions will be added after implementation of common mechanism.
Current set of action: trace, inject, read/write, raw, abbrev, verbose.
And path tracing will be implemented as filter.

>>  caller pid
> What do you mean by "caller" here?
It is filtering by pid of tracee. Maybe "tracee pid" is better.
>>  callnum [<=, >=] number
> pcap support relops (>, <, >=, <=, =, !=) only for arithmetic
expressions, which
> include "length operator, and special packet data accessors"; in case of
> strace this probably should be replaced with something strace-specific.
> One thing, as I understood, is the call serial number, is it correct? Not
> sure about semantic here, which calls should be counted towards it — all
> or only successfully filtered (by which action? Are you going to have
> some per-action/per-filter state?) ones?
Yes, it is call serial number. I think there should be two counters:
for all syscalls and for visible syscalls(filtered by trace action).
>>  command cmd
> What did you mean here? argv[0] of the tracee or something else?
It is command argument of syscalls like ioctl, fcntl...
>> ...
> For completeness sake, I'd like to cover the complete list of
primitives which
> are already supported by strace:
>  * abbrev
>  * verbose
>  * raw
>  * read/write
I think, they should be implemented as filter actions, because they can
have different filters.
> There are also some options for which it could make sense to be
configured with
> a filter expression:
>  * hexadecimal output of strings (-x, -xx)
>  * FD decoding (-y, -yy)
>  * (aforementioned) Execution stack trace printing (-k)
This options will be implemented as filter actions.
> Note that pcap-filter(7) allows omitting of repeated qualifiers (as in
> "tcp dst port ftp or ftp-data"), are you going to support the similar
> feature?
I think this feature is not useful for strace. It can be confusing, when
both sets of values and
omitting of qualifiers are supported.
>> Filtering architecture.
>> The new entry point of filtering is filter_main() in
>> trace_syscall_entering after getting arguments of syscall. It runs every
>> filter action and set tcp->qual_flg value.
>> Filter actions have boolean expression and filters attached to it. Each
>> filter type processes one expression primitive. Filter action runs every
>> attached filter with current tcp and passes results to boolean
>> expression and applies if it is true.
>> This architecture allows independent implementation of filters or
>> expressions and encapsulates filtering mechanism parts.
> Do you mean by "boolean expression" filter expression which was
> designated as "expr" earlier?
Parser should extract filters from expression for independent
computation and optimization of filters and expression.
> I'm not sure how to interpret the phrase "Filter action runs every
> attached filter with current tcp and passes results to boolean
expression".
> Are you referring to process of expression evaluation? If so, can you
> please describe, how should the expression
>     "syscall %net and ( syscall %file or not fd 3 and path /my/file)"
> be evaluated?
Parser splits it into filters (syscall %net, syscall %fd, path /my/file)
and expression ([1] and ([2] or (not [3] and [4])). Expression can be
simplified as boolean expression, some filters can be merged for
optimization. Every filter is evaluated to bool, and expression
evaluates array of bools to one bool.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20170606/f305e00f/attachment.bin>