Closed Bug 1410191 Opened 2 years ago Closed 2 years ago
Some sandbox syscall interceptions turn all errors into EPERM
59 bytes, text/x-review-board-request
Some of the trap functions used in the seccomp-bpf policy use syscall() to delegate to a syscall which isn't blocked. However, the trap registry expects return values to work like the actual syscall ABI — errors returned as negative numbers — whereas syscall() works like the other traditional C wrappers and returns -1 with the error in errno. So, when we do `return syscall(...)` in that context, any error means returning -1, which is -EPERM instead of whatever the actual error is. There are several ways to fix this. The simplest might be to use sandbox::Syscall::Call from the Chromium source, which returns the real return value. (Its actual purpose is to make syscalls with a known rIP, so they can be allowed as part of a non-enforcing warn-only policy, but that doesn't make a difference for our sandboxing.)
Comment on attachment 8922166 [details] Bug 1410191 - Correctly handle errors when using syscalls in sandbox trap handlers. https://reviewboard.mozilla.org/r/193186/#review198690
Attachment #8922166 - Flags: review?(gpascutto) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/671e6d994ecb Correctly handle errors when using syscalls in sandbox trap handlers. r=gcp
You need to log in before you can comment on or make changes to this bug.