Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use seccomp's add_rule_conditional #32

Open
sanxiyn opened this issue Jan 13, 2023 · 1 comment
Open

Use seccomp's add_rule_conditional #32

sanxiyn opened this issue Jan 13, 2023 · 1 comment

Comments

@sanxiyn
Copy link
Contributor

sanxiyn commented Jan 13, 2023

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.

@sanxiyn
Copy link
Contributor Author

sanxiyn commented Mar 13, 2023

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.

This is documented in seccomp_rule_add(3):

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant