Update security/sandbox/* components to handle new syscalls
Categories
(Core :: Security: Process Sandboxing, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox127 | --- | fixed |
People
(Reporter: juippis, Assigned: jld, NeedInfo)
References
Details
Attachments
(2 files)
Steps to reproduce:
Start Firefox-124.0.1 with new glibc and libevent.
Actual results:
Browsers is unusable with messages:
[warn] epoll_wait: Function not implemented
[899883] Sandbox: seccomp sandbox violation: pid 899883, tid 899888, syscall 441, args 12 140694333724288 32 0 0 8.
Expected results:
Browser is usable.
Here's a downstream bug with all information:
https://bugs.gentoo.org/928137
Here's also a patch that handles __NR_epoll_pwait2
specifically:
https://bugs.gentoo.org/928137#c10
https://928137.bugs.gentoo.org/attachment.cgi?id=889218
but most likely other new syscalls from Chromium should be synced to Firefox while at it:
https://github.com/chromium/chromium/commit/5e08782516d24de536e75d6bf4ff2bc87be55124
I'm not exactly sure can the whole Chromium's sandbox component be synced all-at-once?
Comment 1•8 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Security' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Updated•8 months ago
|
Assignee | ||
Comment 2•8 months ago
|
||
In the past we've updated the syscall number headers independently from the rest of security/sandbox/chromium
as needed; see e.g. bug 1713776.
Updated•8 months ago
|
Comment 3•8 months ago
•
|
||
Joonas, do you want to submit the patch in Phabricator?
https://firefox-source-docs.mozilla.org/contributing/how_to_submit_a_patch.html
https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html
Assignee | ||
Comment 4•8 months ago
|
||
Gentoo's patch will need some changes: we'll want to update the full list of syscalls, not just add this one syscall to the middle of the list, out of order, the way they did.
In our version of the headers there are example commands that download the relevant source file and generate the defines, for: x86-64 x64-32 arm-64 arm-32 (note that they all specify kernel 5.8 as written, so that should be changed). Copying the new definitions from Chromium should also work, because we don't need anything newer than their latest update for this.
We've also been including changes like this in our diffs against upstream Chromium, although I'm not sure if we need to do that in this case, given that upstream Chromium also has these updates.
Comment 5•8 months ago
|
||
Gentoo's patch is broken on arm64 as epoll_wait
and thus __NR_epoll_wait
doesn't exists. The patch assumes that if __NR_epoll_pwait2
is defined __NR_epoll_wait
will be as well. This is in general not true.
Assignee | ||
Comment 7•7 months ago
|
||
Assignee | ||
Comment 8•7 months ago
|
||
Note that this can't easily be unit-tested, because the tests can't
distinguish between the real ENOSYS
from lack of kernel support and
the fake ENOSYS
from the sandbox.
Comment 10•7 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/ad8cfda2ed0c
https://hg.mozilla.org/mozilla-central/rev/72b15a00b128
Description
•