Re: Question about seccomp(2) man page example code

On 10 March 2015 at 18:51, Kees Cook [off-list ref] wrote:

On Tue, Mar 10, 2015 at 10:46 AM, Michael Kerrisk (man-pages)
[off-list ref] wrote:

quoted

Hi Kees,

On 10 March 2015 at 18:41, Kees Cook [off-list ref] wrote:

quoted

On Tue, Mar 10, 2015 at 10:24 AM, Michael Kerrisk (man-pages)
[off-list ref] wrote:

quoted

Hi Kees,

I was looking further at the seccomp(2) man page we put togetehr a
while ago, and in particular at the example [1]. I realized that from
a readability view, the order of the statements is rather contorted,
so that we have branches to the end of the code (labels 5 and 6) to
handle the syscall and arch mismatch cases, rather than swapping the
branch order on the statements labeled 0 and 1, and having the kill
statements immediately follow the test statements.

However, I presume the ordering is as it is for efficiency reasons, so
that the common case involves no branch forward (i.e., a branch offset
of 0). Is that the case? If so, probably something should be said in
the man page.

I've never attempting timing tests to see if branching in the common
path is actually any more expensive, but it's not unreasonable. I

Okay.

quoted

think the main reason it was written this way was actually for size.
There's 1 kill statement, which avoids repeating it, and (I think) is
more readable.

FWIW, I find it less readable ;-). That's because one has to count the
BPF statements to branch over (that's why I added the "[n]" labels to
the code). Also, it makes the code trickier to maintain, since, if one
adds some code in the branched over region, then the branch offset
needs to be modified. Just my 2¢.

Yeah, that does become a pain. :) I wonder if maybe some mention of
libseccomp should be made, since it operates as a front-end for
generating seccomp filters, which makes most of this pain go away.

Good point. I'll add mention of libseccomp to the page.

Cheers,

Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html