Allow more fine grained control which syscalls to filter

[wangbj]

It could be better if we can have a configuration file, so that we can determine which syscalls to filter. this might includes:

1) syscalls we don't want to filter at all, such as getpid 2) blacklisted syscalls known to have problems with patching, but can be filtered by seccomp, such as clock_nanosleep, rt_sigreturn.

There're could be intersections between 1) & 2).

[rrnewton]

Do we want a full config file here, or just the ability to read in a text file list syscalls? (By what format names?)

[rrnewton]

When you say "filter" here that means intercept/trap/turn-into-an-event right? "Blacklist" means "intercept and then throw an error" right? And then I suppose "whitelist" means don't intercept at all, just let them through.

In your bullet (2), those are syscalls (e.g. nanosleep) which we may actually want to intercept, right? Filtering by seccomp = converting to signal right? So these are events we can subscribe to, but they are always expensive at runtime, is that correct?

[wangbj]

We can use yml, you're right filter means we'll turn it into a (seccomp) event; for blacklist, there're some syscalls like clock_nanosleep, can be filtered by seccomp, but it isn't safe to patch, because it has instruction sequences like:

syscall
label: xx
yyy

There're code in the same function (glibc wrapper of clock_nanosleep) jumps into the label right after syscall, patching it would cause SIGILL if the jump happens.

clock_nanosleep is not nanosleep, the former provides more control such as which CLOCK to sleep on. You're right seccomp is a lot slower.