Closed Bug 1713745 Opened 1 year ago Closed 11 months ago

enable RDD process on OpenBSD, sandbox it with pledge/unveil

Categories

(Core :: Audio/Video: Playback, enhancement)

Unspecified
OpenBSD
enhancement

Tracking

()

RESOLVED FIXED
91 Branch
Tracking Status
firefox91 --- fixed

People

(Reporter: gaston, Assigned: gaston)

Details

Attachments

(6 files)

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.

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..

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 ?

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   
Summary: enable RDD process on OpenBSD → enable RDD process on OpenBSD, sandbox it with pledge/unveil

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'..

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: nobody → landry

frob all the media.rdd-*.enable about knobs to enable RDD on OpenBSD

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 :)

Flags: needinfo?(mfroman)
Flags: needinfo?(jya-moz)

(In reply to Landry Breuil (:gaston) from comment #5)

Created attachment 9224602 [details] [diff] [review]
patch-dom_media_ipc_RDDProcessImpl_cpp

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

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.

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 ?

(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?

Flags: needinfo?(mfroman)
Flags: needinfo?(jya-moz)
Flags: needinfo?(gpascutto)

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..

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);

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

./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.

Flags: needinfo?(gpascutto)

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.

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.

Flags: needinfo?(gpascutto)

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.

Flags: needinfo?(gpascutto) → needinfo?(mfroman)

(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.

Flags: needinfo?(mfroman)

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..

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

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...)

Pushed by gpascutto@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/53549e1b89e7
include nsXULAppAPI.h to reach GeckoProcessType definition r=gcp

(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 :)

Status: NEW → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → 91 Branch

It's not fixed until all patches have landed :)

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

: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...

(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.

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
You need to log in before you can comment on or make changes to this bug.