-
Notifications
You must be signed in to change notification settings - Fork 173
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
RFE: allow filtering on the caller's instruction pointer #113
Comments
However we decide to expose this, we should make sure we support memory address ranges. |
There is a question if we want to make this check per-syscall, or global for the entire filter. I suspect global would most likely be good enough for the time being. It would definitely be easier from an implementation perspective. |
+1 as a user interested in this. I would love not to have to write and maintain this monstrosity :). Disclaimer: this may well still have lurking bugs; I just fixed a previous version that was implicitly only comparing the most significant 32 bits; whoops. EDIT: this definitely is wrong at the boundaries, since the instruction pointer points to the instruction after the syscall instruction. Correctly emulating the 64-bit arithmetic using BPF 32-bit operations to subtract 2 with borrowing (or add 2 with carry) would make this even more fiddly. EDIT again: Actually this is simple enough to fix by adding 2 to the allowed address range boundaries when constructing the filter. EDIT yet again: Actually according to the man page, the instruction_pointer that the filter sees is the address of the syscall instruction. (But the instruction pointer you see in your sigsys signal handler is definitely the instruction after). TLDR this is fiddly and complicated to get right. Anyone coming across this, take this code snippet with a large grain of salt.
|
In addition to the syscall number and syscall arguments the kernel makes the caller's IP available to seccomp-bpf filters, we should consider exposing this in libseccomp.
See a related request on the libseccomp mailing list:
The text was updated successfully, but these errors were encountered: