You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 30, 2021. It is now read-only.
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?
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:
syscalllabel: xxyyy
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.
It could be better if we can have a configuration file, so that we can determine which syscalls to filter. this might includes:
getpid
seccomp
, such asclock_nanosleep
,rt_sigreturn
.There're could be intersections between 1) & 2).
The text was updated successfully, but these errors were encountered: