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
Currently, if we need to hook, say, ioctl request 42, all ioctl requests are trapped to user space, because we use seccomp's add_rule method, like add_rule(ioctl).
We can do better. If we use seccomp's add_rule_conditional method instead, like add_rule_conditional(ioctl, arg2 == 42), only ioctl request 42 is trapped to user space, because comparison check is done in kernel space. This may improve performance.
The text was updated successfully, but these errors were encountered:
Note on using libseccomp: if we want to trap ioctl request 42, but allow ioctl otherwise, we can't do add_rule_conditional(Trap, ioctl, arg2 == 42) then add_rule(Allow, ioctl). The later must be add_rule_conditional(Allow, ioctl, arg2 != 42) instead.
All of the filter rules supplied by the calling application are combined into a union, with additional logic to eliminate redundant syscall filters. For example, if a rule is added which allows a given syscall with a specific set of argument values and later a rule is added which allows the same syscall regardless the argument values then the first, more specific rule, is effectively dropped from the filter by the second more generic rule.
Currently, if we need to hook, say, ioctl request 42, all ioctl requests are trapped to user space, because we use seccomp's
add_rule
method, likeadd_rule(ioctl)
.We can do better. If we use seccomp's
add_rule_conditional
method instead, likeadd_rule_conditional(ioctl, arg2 == 42)
, only ioctl request 42 is trapped to user space, because comparison check is done in kernel space. This may improve performance.The text was updated successfully, but these errors were encountered: