enable RDD process on OpenBSD, sandbox it with pledge/unveil
Categories
(Core :: Audio/Video: Playback, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox91 | --- | fixed |
People
(Reporter: gaston, Assigned: gaston)
Details
Attachments
(6 files)
755 bytes,
patch
|
Details | Diff | Splinter Review | |
1.38 KB,
patch
|
Details | Diff | Splinter Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
it was disabled in bug #1536126, but OpenBSD has sandboxing 'working', i just need to figure out what syscalls subsets to enable, and the list of files the process would need to access.
what would it take to enable RDD there ? Right now, setting media.rdd-process.enabled
& media.rdd-vorbis.enabled
to true at runtime doesnt seem to spawn a new process type on OpenBSD when playing an ogg stream, so i guess some build bits need to be taken care of.
Assignee | ||
Comment 1•3 years ago
|
||
hmm it seems i was misled by my testing..
/usr/local/lib/firefox/firefox -contentproc -parentBuildID 20210531204357 -prefsLen 8376 -prefMapSize 246468 -appdir /usr/local/lib/firefox/browser 6428 rdd
that looks like an RDD process, right ? it's just probably not sandboxed-enabled/configured..
Assignee | ||
Comment 2•3 years ago
|
||
i'd be interested to know how i can enable our sandboxing for this rdd process, similar to what was done in bug #1457092 to sandbox main/content processes and bug #1580268 to sandbox the gpu process. Where is the process startup done ?
Assignee | ||
Comment 3•3 years ago
•
|
||
now i'm sure that RDD works (? at least with ogg/vorbis) on OpenBSD, per debug logging, unless it is misleading ?
[09:13] nikki:~/ $MOZ_LOG=PlatformDecoderModule:5 firefox
[Child 35276: Main Thread]: D/PlatformDecoderModule PDMInitializer, Init PDMs in Content process
[Child 35276: MediaSupervisor #1]: D/PlatformDecoderModule Sandbox RDD decoder supports requested type
[Child 35276: MediaSupervisor #1]: D/PlatformDecoderModule Sandbox RDD decoder supports requested type
[RDD 16857: Main Thread]: D/PlatformDecoderModule PDMInitializer, Init PDMs in RDD process
[RDD 16857: Main Thread]: D/PlatformDecoderModule Agnostic decoder rejects requested type
[RDD 16857: Main Thread]: D/PlatformDecoderModule Agnostic decoder rejects requested type
[RDD 16857: Main Thread]: D/PlatformDecoderModule Agnostic decoder rejects requested type
[RDD 16857: Main Thread]: D/PlatformDecoderModule Agnostic decoder supports requested type
[RDD 16857: Main Thread]: D/PlatformDecoderModule Agnostic decoder rejects requested type
[RDD 16857: Main Thread]: D/PlatformDecoderModule Agnostic decoder rejects requested type
[RDD 16857: Main Thread]: D/PlatformDecoderModule Agnostic decoder rejects requested type
[RDD 16857: Main Thread]: D/PlatformDecoderModule Agnostic decoder rejects requested type
[RDD 16857: Main Thread]: D/PlatformDecoderModule Agnostic decoder supports requested type
[RDD 16857: Main Thread]: D/PlatformDecoderModule Agnostic decoder rejects requested type
[RDD 16857: Main Thread]: D/PlatformDecoderModule Agnostic decoder rejects requested type
[RDD 16857: MediaSupervisor #1]: D/PlatformDecoderModule Agnostic decoder supports requested type
[RDD 16857: MediaSupervisor #1]: D/PlatformDecoderModule Agnostic decoder supports requested type
[Child 35276: MediaPDecoder #1]: D/PlatformDecoderModule AudioTrimmer[f088edd8c00] ::PrepareTrimmers: sample[7324444,7324444] no trimming information
[Child 35276: MediaPDecoder #1]: D/PlatformDecoderModule AudioTrimmer[f088edd8c00] ::HandleDecodedResult: No sample returned for sample[7324444,7324444]
[Child 35276: MediaPDecoder #1]: D/PlatformDecoderModule AudioTrimmer[f088edd8c00] ::PrepareTrimmers: sample[7324445,7347664] no trimming information
[Child 35276: MediaPDecoder #2]: D/PlatformDecoderModule AudioTrimmer[f088edd8c00] ::HandleDecodedResult: sample[7324445,7347664] (decoded[7324445,7347664] no trimming needed
[Child 35276: MediaPDecoder #2]: D/PlatformDecoderModule AudioTrimmer[f088edd8c00] ::PrepareTrimmers: sample[7347665,7370884] no trimming information
[Child 35276: MediaPDecoder #1]: D/PlatformDecoderModule AudioTrimmer[f088edd8c00] ::HandleDecodedResult: sample[7347665,7370884] (decoded[7347665,7370884] no trimming needed
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 4•3 years ago
|
||
After some testing with various files from wikimedia commons, i think i've successfully tested ogv, mp3, ogg, webm and vp9. From my understanding of the debug log (if there's a better MOZ_LOG class i'm all ears) all the decoding was done in RDD. Testing on invidio.us, i think this one is done in the main process because it's via ffmpeg ? will recheck.
Initial testing for sandboxing shows that the process only needs access to /tmp
to write shm files (?) and read access to firefox dir to open libmozavcodec.so
and libmozavutil.so
, and for the syscalls subset (see http://man.openbsd.org/pledge.2) only those are needed:
stdio
rpath
tmppath
recvfd
sendfd
unix # users getsockopt
prot_exec # uses mmap
- confirmation from ppl knowledgable in this RDD process would comfort those findings :) Other ways to test/debug welcome too ! It would be nice to have bug #1627953 implemented too, helps 'user knowledge'..
Assignee | ||
Comment 5•3 years ago
|
||
start sandboxing at the same spot as windows.. i see that windows has LoadLibraryW
to early load a library before sandboxing, if nspr/gecko has something similar for unix/linux that might allow tightening even more the rdd process sandboxing
Assignee | ||
Comment 6•3 years ago
|
||
frob all the media.rdd-*.enable
about knobs to enable RDD on OpenBSD
Assignee | ||
Comment 7•3 years ago
|
||
to properly read sandboxing config files on OpenBSD, this chunk is also needed in dom/ipc/ContentChild.cpp
:
1 @@ -4784,9 +4801,19 @@ bool StartOpenBSDSandbox(GeckoProcessType type) {
2 OpenBSDFindPledgeUnveilFilePath("unveil.content", unveilFile);
3 break;
4 -
5 + case GeckoProcessType_RDD:
6 + OpenBSDFindPledgeUnveilFilePath("pledge.rdd", pledgeFile);
7 + OpenBSDFindPledgeUnveilFilePath("unveil.rdd", unveilFile);
8 + break;
9 +
i know its a bit rough, but feedback welcome before i start embarking on a moz-phab fight :)
Assignee | ||
Comment 8•3 years ago
•
|
||
(In reply to Landry Breuil (:gaston) from comment #5)
Created attachment 9224602 [details] [diff] [review]
patch-dom_media_ipc_RDDProcessImpl_cppstart sandboxing at the same spot as windows.. i see that windows has
LoadLibraryW
to early load a library before sandboxing, if nspr/gecko has something similar for unix/linux that might allow tightening even more the rdd process sandboxing
i think i should be able to just use
PR_LoadLibrary("libmozavcodec.so");
PR_LoadLibrary("libmozavutil.so");
before enabling sandboxing, and if this works i could remove the need to unveil /usr/local/lib/firefox
. Will try that in my next 90.0b2 build before submitting the patchset to phabricator for comments.
Assignee | ||
Comment 9•3 years ago
|
||
thinking a bit more about it, i'm not sure useing PR_LoadLibrary
from NSPR preloads the library in the process memory space (eg ti's usually used along PR_FindFunctionSymbol
), hopefully removing the need for further late loading ? what triggers the loading of those libs on other platforms ?
Comment 10•3 years ago
|
||
(In reply to Landry Breuil (:gaston) from comment #7)
to properly read sandboxing config files on OpenBSD, this chunk is also needed in
dom/ipc/ContentChild.cpp
:1 @@ -4784,9 +4801,19 @@ bool StartOpenBSDSandbox(GeckoProcessType type) { 2 OpenBSDFindPledgeUnveilFilePath("unveil.content", unveilFile); 3 break; 4 - 5 + case GeckoProcessType_RDD: 6 + OpenBSDFindPledgeUnveilFilePath("pledge.rdd", pledgeFile); 7 + OpenBSDFindPledgeUnveilFilePath("unveil.rdd", unveilFile); 8 + break; 9 +
i know its a bit rough, but feedback welcome before i start embarking on a moz-phab fight :)
Landry, this is really a question for the sandbox team.
Gian-Carlo, who should take a look at this?
Assignee | ||
Comment 11•3 years ago
|
||
doing the PR_LoadLibrary()
dance before enabling sandboxing seems to do the trick, no need to unveil() them as they're already available for further decoding.
:mjf: well, i also welcome feedback from the 'team that worked on RDD' whether it's safe to enable it on non-Tier1 platforms, and what corner cases should be tested..
Assignee | ||
Comment 12•3 years ago
|
||
Otherwise the build fails on OpenBSD:
In file included from security/sandbox/common/SandboxSettings.cpp:7:
/usr/obj/m-c/dist/include/mozilla/SandboxSettings.h:39:26: error: unknown type name 'GeckoProcessType'
bool StartOpenBSDSandbox(GeckoProcessType type);
Assignee | ||
Comment 13•3 years ago
|
||
Depends on D116633
Assignee | ||
Comment 14•3 years ago
|
||
As it's done on windows, preload libmozavcodec.so and libmozavutil.so
before sandboxing, this way this allows for a tighter sandboxing
(no filesystem access but /tmp for shm files, no prot_exec pledge..)
Depends on D116634
Assignee | ||
Comment 15•3 years ago
|
||
Depends on D116635
Comment 16•3 years ago
|
||
./mach try auto
https://treeherder.mozilla.org/#/jobs?repo=try&revision=c08fd70c63542e813c66c9349e3b06629df13f6f
I put testing-exception-unchanged as this should be NPOTB but let's check to be sure.
Comment 17•3 years ago
|
||
i know its a bit rough, but feedback welcome before i start embarking on a moz-phab fight :)
LGTM, logical extension of the support code that we already have.
Assignee | ||
Comment 18•3 years ago
|
||
sorry gian-carlo, but since the revisions are 'accepted', what needs to be done to get those (and the others from other bugs) landed ? Afaict i dont have lando access, previously one was supposed to set checking-needed on the whiteboard (or was it keywords) in the bug but i'm not sure its still the case nowadays so i'm a bit lost in the workflow changes... guidance welcome :)
the moz-phab doc seems to assume that you have lando access if you use moz-phab... or i didnt look at the right place.
Comment 19•3 years ago
|
||
I was looking at https://bugzilla.mozilla.org/show_bug.cgi?id=1713745#c11 and assuming you wanted to hold them here until the RDD process is OK to go on OpenBSD. If you want them landed, I can do that for you.
mjf, I think the question in that comment is for you.
Comment 20•3 years ago
|
||
(In reply to Landry Breuil (:gaston) from comment #11)
doing the
PR_LoadLibrary()
dance before enabling sandboxing seems to do the trick, no need to unveil() them as they're already available for further decoding.:mjf: well, i also welcome feedback from the 'team that worked on RDD' whether it's safe to enable it on non-Tier1 platforms, and what corner cases should be tested..
The media team (probably starting w/ :jbauman or :chunmin) may have more to say on the subject since they are the current caretakers of RDD. Originally, we enabled RDD decoding and tested all the RDD supported media formats to see that they continued to work, and that RDD process became visibly busy during the media decode.
Assignee | ||
Comment 21•3 years ago
|
||
i've been using rdd & socket sandboxing patches for this beta cycle on my machines and some other OpenBSD developers tried them without fallback, i've tested various videos from invidio.us, tested webrtc, videos/audios with various formats from wikimedia commons, so i think we're good to go..
Comment 22•3 years ago
|
||
FTR, for RDD we should have test coverage improving soon, you might want to try and run some locally? https://bugzilla.mozilla.org/show_bug.cgi?id=1652156
Comment 23•3 years ago
|
||
Afaict i dont have lando access, previously one was supposed to set checking-needed on the whiteboard (or was it keywords) in the bug but i'm not sure its still the case nowadays so i'm a bit lost in the workflow changes... guidance welcome :) the moz-phab doc seems to assume that you have lando access if you use moz-phab... or i didnt look at the right place.
Setting checkin-needed in Phabricator would work, but it might have delays due to people being on PTO. Fastest is just asking the reviewer.
(If you want direct access, I'd vouch for you...)
Comment 24•3 years ago
|
||
Pushed by gpascutto@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/53549e1b89e7 include nsXULAppAPI.h to reach GeckoProcessType definition r=gcp
Assignee | ||
Comment 25•3 years ago
|
||
(In reply to Gian-Carlo Pascutto [:gcp] from comment #23)
Afaict i dont have lando access, previously one was supposed to set checking-needed on the whiteboard (or was it keywords) in the bug but i'm not sure its still the case nowadays so i'm a bit lost in the workflow changes... guidance welcome :) the moz-phab doc seems to assume that you have lando access if you use moz-phab... or i didnt look at the right place.
Setting checkin-needed in Phabricator would work, but it might have delays due to people being on PTO. Fastest is just asking the reviewer.
(If you want direct access, I'd vouch for you...)
i used to have L3 access some years ago (see bug #651684, then bug #761072) when one could directly push to m-c, and i think those got revoked at some point for being not much used for a while...not sure i have the time to contribute that much those days that would make it necessary again :)
Comment 26•3 years ago
|
||
bugherder |
Assignee | ||
Comment 27•3 years ago
|
||
It's not fixed until all patches have landed :)
Updated•3 years ago
|
Assignee | ||
Comment 28•3 years ago
|
||
:gcp, if you can land the accepted revisions from this bug and also bug #1623086 and bug #1713999 that would clear my wip queue :)
Thanks and sorry for the hassle...
Comment 29•3 years ago
|
||
(In reply to Landry Breuil (:gaston) from comment #28)
:gcp, if you can land the accepted revisions from this bug and also bug #1623086 and bug #1713999 that would clear my wip queue :)
Thanks and sorry for the hassle...
I'm going to take care of it.
Comment 30•3 years ago
|
||
Pushed by gpascutto@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/070d5d5f4e0e Look for unveil/pledge config files for RDD process sandboxing on OpenBSD r=gcp https://hg.mozilla.org/integration/autoland/rev/3a9fd9229624 Sandbox the RDD process on OpenBSD r=gcp https://hg.mozilla.org/integration/autoland/rev/fc39a4abf389 push all the knobs to enable RDD on OpenBSD r=gcp
Comment 31•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/070d5d5f4e0e
https://hg.mozilla.org/mozilla-central/rev/3a9fd9229624
https://hg.mozilla.org/mozilla-central/rev/fc39a4abf389
Description
•