Closed Bug 1856301 Opened 2 years ago Closed 2 years ago

[openbsd] no mp4 decoding in 119 beta (sandboxing)

Categories

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

Product:
Core
Component:
Audio/Video: Playback
Version:
Firefox 119
Platform:
Unspecified
OpenBSD
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
121 Branch
Tracking Flags:
Tracking Status
firefox120 --- fixed
firefox121 --- fixed

People

(Reporter: gaston, Assigned: gaston)

References

Details

Attachments

(5 files, 2 obsolete files)

MOZ_LOG=PlatformDecoderModule:5 process initialization
50.49 KB, text/plain
Details
log with b5-audio-non-utility=true
16.50 KB, text/plain
Details
log with b5-audio-non-utility=false
5.91 KB, text/plain
Details
Bug 1856301: [OpenBSD] also preload libavcodec.so before sandboxing r?gerard-majax
48 bytes, text/x-phabricator-request
diannaS
: approval-mozilla-release+
Details | Review
Bug 1856301: [OpenBSD] only pass the filename to PR_LoadLibraryWithFlags r?gerard-majax
48 bytes, text/x-phabricator-request
diannaS
: approval-mozilla-release+
Details | Review

something has changed in 119 that breaks decoding video on OpenBSD, at least on twitter/nitter and invidious.
playing the video on https://nitter.unixfox.eu/MotoGP/status/1708761567859237004#m
in the browser console i get this :

Cannot play media. No decoders for requested formats: video/mp4; codecs="avc1.42E01E mp4a.40.2", application/vnd.apple.mpegurl

and the video doesn't start.
going to https://invidious.fdn.fr/watch?v=e4_1hR01B6I i get No compatible source was found for this media.

some change in remote decoding ?

plain youtube and https://piped.video works.

Summary: no mp4 decoding in 119 beta → [openbsd] no mp4 decoding in 119 beta

with MOZ_LOG=PlatformDecoderModule:5 going to https://nitter.unixfox.eu/MotoGP/status/1708761567859237004#m i get this:

[Child 801: Main Thread]: D/PlatformDecoderModule PDMInitializer, Init PDMs in Content process
[Child 801: Main Thread]: D/PlatformDecoderModule Sandbox RDD decoder rejects requested type video/avc
[Child 801: Main Thread]: D/PlatformDecoderModule Sandbox Utility Generic decoder rejects requested type video/avc
[Child 801: Main Thread]: D/PlatformDecoderModule Sandbox RDD decoder supports requested type video/av1
[Child 801: Main Thread]: D/PlatformDecoderModule Sandbox RDD decoder supports requested type video/av1
[Child 801: Main Thread]: D/PlatformDecoderModule Sandbox RDD decoder rejects requested type video/avc
[Child 801: Main Thread]: D/PlatformDecoderModule Sandbox Utility Generic decoder rejects requested type video/avc
Attachment #9356078 - Attachment mime type: text/x-log → text/plain

after a report from another user, i had a deeper look and now i wonder if it's related to sandboxing on OpenBSD.

as of 118 the rdd process only has read/write access to /tmp (for shm temporary files), and very few syscalls per our pledge sandboxing policy.

adding /usr/local/lib seems to changes thing as in now the rdd process apparently 'supports' video/avc

[Child 92806: Main Thread]: D/PlatformDecoderModule Sandbox RDD decoder supports requested type video/avc

but to have mp4 decoding 'working' i also need to add prot_exec to pledge syscall classes, which is an annoyance (allows PROT_EXEC on mmap'ed regions) for a process supposed to do remote data decoding.

so, what changed in 119 regarding video decoding and subprocesses, between utility and rdd ?

Summary: [openbsd] no mp4 decoding in 119 beta → [openbsd] no mp4 decoding in 119 beta (sandboxing)

Maybe bug 1846796? Bug 1855636 disabled the change and has been waiting to uplift to Beta. So maybe you could help us to try it again when the change lands on Beta?

Flags: needinfo?(landry)

(In reply to Alastor Wu [:alwu] from comment #5)

Maybe bug 1846796? Bug 1855636 disabled the change and has been waiting to uplift to Beta. So maybe you could help us to try it again when the change lands on Beta?

mm i'm no sure at all since as i understand it that bug was a regression in 118, while mp4 decoding works fine in 118 and breaks in 119. Or that "webcodecs" thing is the future and should be tested on non-linux too ? i can test things if given proper steps.

ccing :gcp as he's my usual go-to contact for sandboxing changes :)

Flags: needinfo?(landry)

Or that "webcodecs" thing is the future and should be tested on non-linux too ? i can test things if given proper steps.

It certainly is the future (it's a new web api to do low level encoding/decoding), but reuses the same underlying infrastructure. However, we had to modify a code path used today for regular playback and broke something. I don't expect Web Codecs to require any specific testing on non-linux, in the sense that it's essentially exposing internal objects to javascript (with layer in between to make it nice). In any case, there are lots of tests for it.

fwiw, will compare trace logs (MOZ_LOG=OpenBSDSandbox:5;PlatformDecoderModule:5) between 118 and 119 using the following patch:

Index: dom/media/platforms/ffmpeg/FFmpegRuntimeLinker.cpp
--- dom/media/platforms/ffmpeg/FFmpegRuntimeLinker.cpp.orig
+++ dom/media/platforms/ffmpeg/FFmpegRuntimeLinker.cpp
@@ -7,6 +7,7 @@
 #include "FFmpegRuntimeLinker.h"
 #include "FFmpegLibWrapper.h"
 #include "mozilla/ArrayUtils.h"
+#include "mozilla/Logging.h"
 #include "FFmpegLog.h"
 #include "prlink.h"
 
@@ -54,8 +55,11 @@ static const char* sLibs[] = {
     // clang-format on
 };
 
+static LazyLogModule sPledgeLog("OpenBSDSandbox");
+
 /* static */
 bool FFmpegRuntimeLinker::Init() {
+  MOZ_LOG(sPledgeLog, LogLevel::Debug, ("FFmpegRuntimeLinker::Init() called, sLinkStatus=%d,sLinkStatusLibraryName='%s'\n", sLinkStatus, sLinkStatusLibraryName));
   if (sLinkStatus != LinkStatus_INIT) {
     return sLinkStatus == LinkStatus_SUCCEEDED;
   }
@@ -81,6 +85,7 @@ bool FFmpegRuntimeLinker::Init() {
         case FFmpegLibWrapper::LinkResult::Success:
           sLinkStatus = LinkStatus_SUCCEEDED;
           sLinkStatusLibraryName = lib;
+          MOZ_LOG(sPledgeLog, LogLevel::Debug, ("FFmpegRuntimeLinker::Init() returning true, sLinkStatus=%d,sLinkStatusLibraryName='%s'\n", sLinkStatus, sLinkStatusLibraryName));
           return true;
         case FFmpegLibWrapper::LinkResult::NoProvidedLib:
           MOZ_ASSERT_UNREACHABLE("Incorrectly-setup sLibAV");
@@ -126,6 +131,7 @@ bool FFmpegRuntimeLinker::Init() {
       }
     }
   }
+  MOZ_LOG(sPledgeLog, LogLevel::Debug, ("FFmpegRuntimeLinker::Init() returning false, sLinkStatus=%d,sLinkStatusLibraryName='%s'\n", sLinkStatus, sLinkStatusLibraryName));
 
   FFMPEGV_LOG("H264/AAC codecs unsupported without [");
   for (size_t i = 0; i < ArrayLength(sLibs); i++) {

that should tell me if sandboxing was called before/after ffmpeg runtime linker is initialized

with that logging here's what i understand from the rdd/utility communication:

  • the utility process has access to usr/local/lib and is allowed prot_exec via pledge:
[Utility 57398: Main Thread]: D/OpenBSDSandbox /usr/lib: unveil(/usr/lib, r)
[Utility 57398: Main Thread]: D/OpenBSDSandbox /usr/local/lib: unveil(/usr/local/lib, r)
[Utility 57398: Main Thread]: D/OpenBSDSandbox /tmp: unveil(/tmp, rwc)
[Utility 57398: Main Thread]: D/OpenBSDSandbox /etc/firefox/pledge.utility: pledge(stdio tmppath rpath recvfd sendfd prot_exec unix)
  • later on the utility process initializes ffmpeg fine and finds libavcodec:
[Utility 57398: Main Thread]: D/PlatformDecoderModule PDMInitializer, Init PDMs in Utility process
[Utility 57398: Main Thread]: D/OpenBSDSandbox FFmpegRuntimeLinker::Init() called, sLinkStatus=0,sLinkStatusLibraryName=''
[Utility 57398: Main Thread]: D/OpenBSDSandbox FFmpegRuntimeLinker::Init() returning true, sLinkStatus=1,sLinkStatusLibraryName='libavcodec.so'
[Utility 57398: Main Thread]: D/OpenBSDSandbox FFmpegRuntimeLinker::Init() called, sLinkStatus=1,sLinkStatusLibraryName='libavcodec.so'
[Utility 57398: Main Thread]: D/PlatformDecoderModule FFmpeg decoder rejects requested type 'video/avc'
[Utility 57398: Main Thread]: D/PlatformDecoderModule FFmpeg decoder supports requested type 'video/avc'
[Utility 57398: Main Thread]: D/PlatformDecoderModule FFmpeg decoder supports requested type 'video/avc'
  • the parent process says that utility supports all formats ?
[Parent 85294: Main Thread]: D/PlatformDecoderModule Broadcast support from 'Utility Generic', support=H264 SW, VP8 SW, VP9 SW, AV1 SW, AAC SW, FLAC SW, MP3 SW, Opus SW, Vorbis SW, Wave SW
  • a bit later on the RDD process is created with tighter pledge/unveils and fails to find libavcodec:
[(null) 97220: Main Thread]: D/OpenBSDSandbox /tmp: unveil(/tmp, rwc)
[(null) 97220: Main Thread]: D/OpenBSDSandbox /etc/firefox/pledge.rdd: pledge(stdio rpath tmppath recvfd sendfd unix)
[RDD 97220: Main Thread]: D/PlatformDecoderModule PDMInitializer, Init PDMs in RDD process
[RDD 97220: Main Thread]: D/OpenBSDSandbox FFmpegRuntimeLinker::Init() called, sLinkStatus=0,sLinkStatusLibraryName=''
[RDD 97220: Main Thread]: D/OpenBSDSandbox FFmpegRuntimeLinker::Init() returning false, sLinkStatus=8,sLinkStatusLibraryName=''
[RDD 97220: Main Thread]: D/OpenBSDSandbox FFmpegRuntimeLinker::Init() called, sLinkStatus=8,sLinkStatusLibraryName=''
[RDD 97220: Main Thread]: D/PlatformDecoderModule Agnostic decoder rejects requested type 'video/avc'
[RDD 97220: Main Thread]: D/PlatformDecoderModule Agnostic decoder supports requested type 'video/vp9'
[RDD 97220: Main Thread]: D/PlatformDecoderModule Agnostic decoder supports requested type 'video/vp9'

but later on the main process says that RDD supports all formats ?

[Parent 85294: Main Thread]: D/PlatformDecoderModule Broadcast support from 'RDD', support=H264 SW, VP8 SW, VP9 SW, AV1 SW, Theora SW, AAC SW, FLAC SW, MP3 SW, Opus SW, Vorbis SW, Wave SW
[Child 80955: Main Thread]: D/PlatformDecoderModule Sandbox RDD decoder rejects requested type audio/mp4a-latm
[Child 80955: Main Thread]: D/PlatformDecoderModule Sandbox Utility Generic decoder supports requested type audio/mp4a-latm
[Child 80955: Main Thread]: D/PlatformDecoderModule Sandbox Utility Generic decoder supports requested type audio/mp4a-latm
[Child 80955: Main Thread]: D/PlatformDecoderModule Sandbox RDD decoder rejects requested type audio/mp4a-latm
[Child 80955: Main Thread]: D/PlatformDecoderModule Sandbox Utility Generic decoder supports requested type audio/mp4a-latm
[Child 80955: Main Thread]: D/PlatformDecoderModule Sandbox Utility Generic decoder supports requested type audio/mp4a-latm
[Child 80955: Main Thread]: D/PlatformDecoderModule Sandbox RDD decoder supports requested type video/avc
[Child 80955: Main Thread]: D/PlatformDecoderModule Sandbox RDD decoder supports requested type video/avc

(note that i dont understand those tons of 'Sandbox RDD decoder supports/rejectsmsgs aboutvideo/avc` - ofc can provide full log if needed).

after looking a bit at the code, the sandboxing in the rdd process is initialized here:
https://searchfox.org/mozilla-central/source/dom/media/ipc/RDDProcessImpl.cpp#31

and just before initializing it we make sure to preload libmozavcodec.so and libmozavutil.so (that comes from bug #1713745). Should we preload libavcodec.so in addition ? instead of those ? did something change between 118 and 119 that makes firefox use the systemwide avcodec instead of its own ? or mozavcodec is just a wrapper around the systemwide one ? (i have to admit the relationship between all those is unclear to me)

from the port commits history for the sandboxing configs, the fact that utility process has access to prot_exec & usr/local/lib comes from the original sandboxing policy for the now-removed audio decoder utility process in 102 (cf https://github.com/openbsd/ports/commit/3f98d2781f4f51faefa00cb5e58f28317e5fa059) - should the rdd process gain those ?

will do some ktracing to figure out which lib is loaded when, and try to compare the initialization log with the same sequence of events using 118.

Flags: needinfo?(padenot)
Flags: needinfo?(lissyx+mozillians)

on 119b5 where video decoding fails, using ktrace -i -t cn i get this sequence of events:

[09:51] nikki:~/ $kdump|egrep '(rdd|utility|avco)'
 88263 firefox  NAMI  "/etc/firefox/pledge.utility"
 88263 firefox  NAMI  "/etc/firefox/unveil.utility"
 88263 firefox  NAMI  "/usr/local/lib/firefox/libmozavcodec.so.130.0"
 88263 firefox  NAMI  "/usr/local/lib/libavcodec.so.25.0"
 79203 firefox  NAMI  "/usr/local/lib/firefox/libmozavcodec.so.130.0"
 79203 firefox  NAMI  "/etc/firefox/pledge.rdd"
 79203 firefox  NAMI  "/etc/firefox/unveil.rdd"

so 88263 is the utility process (which opens mozavcodec and libavcodec after having been sandboxed) and 79203 is the rdd process - which preloads mozavcoded before sandboxing, doesn't find libavcodec and fails to decode the video.

using the same url on 118.0.1, here's what i get/understand:

[09:55] nikki:~/ $kdump|egrep '(pledge.(rdd|content|utility)|avco)'
 25778 firefox  NAMI  "/etc/firefox/pledge.content"
 80342 firefox  NAMI  "/etc/firefox/pledge.utility"
 25778 firefox  NAMI  "/usr/local/lib/firefox/libmozavcodec.so.130.0"
 25778 firefox  NAMI  "/usr/local/lib/libavcodec.so.25.0"
 80342 firefox  NAMI  "/usr/local/lib/firefox/libmozavcodec.so.130.0"
 80342 firefox  NAMI  "/usr/local/lib/libavcodec.so.25.0"
 28523 firefox  NAMI  "/usr/local/lib/firefox/libmozavcodec.so.130.0"
 28523 firefox  NAMI  "/etc/firefox/pledge.rdd"

25778 is a content process (which also has prot_exec and access to /usr/local/lib), it loads libavcodec like 80342 (the utility process). So in 118.0.1 mp4 decoding works because it happens in the content process (or the utility process) and not in the rdd process ?

using the same MOZ_LOG invocation i dont have the exact same log for the initialization of ffmpeg in the rdd process:

[(null) 83064: Main Thread]: D/OpenBSDSandbox /tmp: unveil(/tmp, rwc)
[(null) 83064: Main Thread]: D/OpenBSDSandbox /etc/firefox/pledge.rdd: pledge(stdio rpath tmppath recvfd sendfd unix)
[RDD 83064: Main Thread]: D/PlatformDecoderModule PDMInitializer, Init PDMs in RDD process
[RDD 83064: Main Thread]: D/PlatformDecoderModule FFVPX: unable to load library /usr/local/lib/firefox/libmozavutil.so.130.0
[RDD 83064: Main Thread]: D/PlatformDecoderModule FFVPX: unable to load library /usr/local/lib/firefox/libmozavcodec.so.130.0
[RDD 83064: Main Thread]: D/OpenBSDSandbox FFmpegRuntimeLinker::Init() called, sLinkStatus=0,sLinkStatusLibraryName=''
[RDD 83064: Main Thread]: D/OpenBSDSandbox FFmpegRuntimeLinker::Init() returning false, sLinkStatus=8,sLinkStatusLibraryName=''
[RDD 83064: Main Thread]: D/PlatformDecoderModule FFMPEG: H264/AAC codecs unsupported without [
[RDD 83064: Main Thread]: D/PlatformDecoderModule FFMPEG:   libavcodec.so
[RDD 83064: Main Thread]: D/PlatformDecoderModule FFMPEG:  ]
[RDD 83064: Main Thread]: D/OpenBSDSandbox FFmpegRuntimeLinker::Init() called, sLinkStatus=8,sLinkStatusLibraryName=''
[RDD 83064: Main Thread]: D/PlatformDecoderModule Agnostic decoder rejects requested type 'video/avc'
[RDD 83064: Main Thread]: D/PlatformDecoderModule Agnostic decoder supports requested type 'video/vp9'

i dont really understand the 'unable to load library' messages since those libs should have be preloaded before initializing the sandboxing of the rdd process, but given the sLinkStatus dance the rdd process doesn't know that the libs were preloaded and keeps thinking they're not here. Maybe i should fix the preloading to also preload libavcodec.so if needed, and preinitialize sLinkStatus to 1 on OpenBSD ?

What is strange is that mp4 decoding works, maybe because in 118 it fallbacked to decoding in the utility/content process if it fails in the rdd process, and its not the case anymore in 119 ?

another option would be to move the sandboxing initialization of the rdd process after all the PDMInitializer bits have been done. I suppose this is the case for linux ? windows sandboxing is initialized similarly to openbsd in https://searchfox.org/mozilla-central/source/dom/media/ipc/RDDProcessImpl.cpp#25...

eg moving the StartOpenBSDSandbox(GeckoProcessType_RDD); call added in https://hg.mozilla.org/integration/autoland/rev/3a9fd9229624
to https://searchfox.org/mozilla-central/source/dom/media/platforms/PDMFactory.cpp#214 so that all external libs are loaded before tightening the rdd process sandbox.

in the list of media/ipc related bugs that i see were fixed in 119 i see bug #1853057 and bug #1850904 but i hardly think what i'm seeing is a regression from those.

fwiw i have working mp4 decoding on 119.0b6 moving the sandbox initialization to https://searchfox.org/mozilla-central/source/dom/media/platforms/PDMFactory.cpp#214. That arises more questions:

  • should the same be done for the utility process ? what is that process supposed to do in addition to audio decoding ? that would allow dropping some privileges from the unveil/pledge config..
  • should i first submit those small patches to phabricator before anything else ?

this unbreaks mp4 decoding on 119.0beta with OpenBSD sandboxing.

as sandboxing is very tight on openbsd (eg no /usr/local/lib access and
no mmap PROT_EXEC rights) and is initialized quite early since bug
#1713745, the rdd process can't dlopen libavcodec.so and thus mp4
decoding fails. A similar failure can be seen with FFVPXRuntimeLinker
which also tries to dlopen libmozavcodec/libmozavutil after having been
sandboxed.

instead of adding too wide rights to the rdd process, move the
sandboxing initialization after InitRddPDMs() when all the platform
decoder modules have been loaded - this way we can keep our tight
sandboxing configuration.

Assignee: nobody → landry
Status: NEW → ASSIGNED
Flags: needinfo?(lissyx+mozillians)

ok there's something weird going on.. at :gerard-majax's request i've tried toggling media.allow-audio-non-utility (cf bug #1850904) on 119.0b5 (so without my patch from D190475) - with the default in b5 (eg false) video decoding fails, but when toggled to true video decoding works.

my patch still stands as it improves the situation wrt sandboxing but it feels .. strange.

attaching two MOZ_LOG=PlatformDecoderModule:5 logs with the pref toggled true/false

[RDD 83064: Main Thread]: D/PlatformDecoderModule FFVPX: unable to load library /usr/local/lib/firefox/libmozavutil.so.130.0
[RDD 83064: Main Thread]: D/PlatformDecoderModule FFVPX: unable to load library /usr/local/lib/firefox/libmozavcodec.so.130.0
[RDD 83064: Main Thread]: D/OpenBSDSandbox FFmpegRuntimeLinker::Init() called, sLinkStatus=0,sLinkStatusLibraryName=''
[RDD 83064: Main Thread]: D/OpenBSDSandbox FFmpegRuntimeLinker::Init() returning false, sLinkStatus=8,sLinkStatusLibraryName=''
[RDD 83064: Main Thread]: D/PlatformDecoderModule FFMPEG: H264/AAC codecs unsupported without [
[RDD 83064: Main Thread]: D/PlatformDecoderModule FFMPEG:   libavcodec.so
[RDD 83064: Main Thread]: D/PlatformDecoderModule FFMPEG:  ]
[RDD 83064: Main Thread]: D/OpenBSDSandbox FFmpegRuntimeLinker::Init() called, sLinkStatus=8,sLinkStatusLibraryName=''

Probably we should first understand why it fails to load, no? Any tracing you could do ? Why libmozavutil.so.130.0 and libmozavcodec.so.130.0 ? My linux builds shows only libmozavutil.so and libmozavcodec.so, i.e., unversionned

(In reply to :gerard-majax from comment #18)

Probably we should first understand why it fails to load, no? Any tracing you could do ? Why libmozavutil.so.130.0 and libmozavcodec.so.130.0 ? My linux builds shows only libmozavutil.so and libmozavcodec.so, i.e., unversionned

it fails to load them because at that point the sandboxing has been configured and /usr doesnt exist anymore for the process. They're versionned because we control the major.minor in the packaging system, and here the issue seems that the library preloading that was initially added when sandboxing rdd apparently doesnt work, because afaict the subsequent dlopen calls should reuse the lib that was preloaded.

i'll try to spend some time on this next month at a hackathon but until then, i wont have a better understanding of what happens here...

more data points, this is getting hairy - after discussing with other developers how our dlopen works, quoting http://man.openbsd.org/dlopen

"If the named shared object has already been loaded by a previous call to dlopen() and not yet unloaded by dlclose(), a handle referring to the resident copy is returned."

i'll have to recheck what happens, but a simple test program doing

dlopen("libavcodec.so", RTLD_LAZY)
unveil(nothing)
dlopen("libavcodec.so", RTLD_NOW | RTLD_LOCAL)

succeeds. so preloading the libavcodec/libavutil as we do since rdd is sandboxed should work. I'll have to recheck again what happens in PR_LoadLibraryWithFlags

note that if using the full path to the lib then

dlopen("/usr/local/lib/libavcodec.so.25.0",RTLD_LAZY);
unveil(nothing);
dlopen("/usr/local/lib/libavcodec.so.25.0",RTLD_NOW|RTLD_LOCAL);

then the second dlopen fails because it cant access the path to the library.

what is interesting is that toggling media.allow-audio-non-utility to true makes everything work, but then apparently decoding doesnt happen in the RDD process.

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

more data points, this is getting hairy - after discussing with other developers how our dlopen works, quoting http://man.openbsd.org/dlopen

"If the named shared object has already been loaded by a previous call to dlopen() and not yet unloaded by dlclose(), a handle referring to the resident copy is returned."

i'll have to recheck what happens, but a simple test program doing

dlopen("libavcodec.so", RTLD_LAZY)
unveil(nothing)
dlopen("libavcodec.so", RTLD_NOW | RTLD_LOCAL)

succeeds. so preloading the libavcodec/libavutil as we do since rdd is sandboxed should work. I'll have to recheck again what happens in PR_LoadLibraryWithFlags

note that if using the full path to the lib then

dlopen("/usr/local/lib/libavcodec.so.25.0",RTLD_LAZY);
unveil(nothing);
dlopen("/usr/local/lib/libavcodec.so.25.0",RTLD_NOW|RTLD_LOCAL);

then the second dlopen fails because it cant access the path to the library.

what is interesting is that toggling media.allow-audio-non-utility to true makes everything work, but then apparently decoding doesnt happen in the RDD process.

I assume since you allow decoding on non utility, then it happens on content, which has more access to the system and can load the libs:

so, making some progress. on 119.0rc2, forcing media.allow-audio-non-utility=false, without https://phabricator.services.mozilla.com/D190475 but with that patch instead:

Index: dom/media/ipc/RDDProcessImpl.cpp
--- dom/media/ipc/RDDProcessImpl.cpp.orig
+++ dom/media/ipc/RDDProcessImpl.cpp
@@ -31,6 +31,7 @@ bool RDDProcessImpl::Init(int aArgc, char* aArgv[]) {
 #elif defined(__OpenBSD__) && defined(MOZ_SANDBOX)
   PR_LoadLibrary("libmozavcodec.so");
   PR_LoadLibrary("libmozavutil.so");
+  PR_LoadLibrary("libavcodec.so");
   StartOpenBSDSandbox(GeckoProcessType_RDD);
 #endif
   Maybe<const char*> parentBuildID =

at rdd process init, it correctly finds the already preloaded libavcodec.so:

[RDD 40179: Main Thread]: D/OpenBSDSandbox FFmpegRuntimeLinker::Init() returning true, sLinkStatus=1,sLinkStatusLibraryName='libavcodec.so'

it seems i have mp4 decoding working, and video decoding happening in the RDD process afaict (and audio in the utility process ?):

[Utility 10024: MediaPDecoder #1]: V/PlatformDecoderModule ProcessDecode: mDuration=21333µs ; mTime=9333µs ; mTimecode=9333µs                                                                                        
[RDD 40179: MediaPDecoder #1]: V/PlatformDecoderModule ProcessDecode: mDuration=40000µs ; mTime=160000µs ; mTimecode=116796µs                                                                                        
[Utility 10024: MediaPDecoder #1]: V/PlatformDecoderModule ProcessDecode: mDuration=21333µs ; mTime=9333µs ; mTimecode=9333µs

but after instrumenting NSPR's dlopen wrappers,

 static PRLibrary*                                                                                                                                                                                                   
 pr_LoadLibraryByPathname(const char *name, PRIntn flags)                                                                                                                                                            
 {
+    PR_LOG(_pr_linker_lm, PR_LOG_ALWAYS, ("[PID=%d] pr_LoadLibraryByPathname(%s,%d)", getpid(), name, flags));
     PRLibrary *lm;
     PRLibrary* result = NULL;
     PRInt32 oserr;

i have strange messages about libmozavcodec.so and libmozavutil.so (which should also be preloaded by that point):

[RDD 40179: Main Thread]: D/PlatformDecoderModule PDMInitializer, Init PDMs in RDD process                                                                                                                           
-1295163304[5e6334bd1c0]: [PID=40179] pr_LoadLibraryByPathname(/usr/local/lib/firefox/libmozavutil.so.131.0,10)                                                                                                      
dlopen: loading: /usr/local/lib/firefox/libmozavutil.so.131.0                                                                                                                                                        
dlopen: failed to open /usr/local/lib/firefox/libmozavutil.so.131.0                                                                                                                                                  
dlopen: /usr/local/lib/firefox/libmozavutil.so.131.0: done (failed).                                                                                                                                                 
dlopen: loading: /usr/local/lib/firefox/libmozavutil.so                                                                                                                                                              
dlopen: failed to open /usr/local/lib/firefox/libmozavutil.so                                                                                                                                                        
dlopen: /usr/local/lib/firefox/libmozavutil.so: done (failed).                                                                                                                                                       
-1295163304[5e6334bd1c0]: [PID=40179] pr_LoadLibraryByPathname(/usr/local/lib/firefox/libmozavcodec.so.131.0,10)                                                                                                     
dlopen: loading: /usr/local/lib/firefox/libmozavcodec.so.131.0                                                                                                                                                       
dlopen: failed to open /usr/local/lib/firefox/libmozavcodec.so.131.0                                                                                                                                                 
dlopen: /usr/local/lib/firefox/libmozavcodec.so.131.0: done (failed).                                                                                                                                                
dlopen: loading: /usr/local/lib/firefox/libmozavcodec.so                                                                                                                                                             
dlopen: failed to open /usr/local/lib/firefox/libmozavcodec.so                                                                                                                                                       
dlopen: /usr/local/lib/firefox/libmozavcodec.so: done (failed).                                                                                                                                                      
[RDD 40179: Main Thread]: D/OpenBSDSandbox FFmpegRuntimeLinker::Init() called, sLinkStatus=0,sLinkStatusLibraryName=''                                                                                               
-1295163304[5e6334bd1c0]: [PID=40179] pr_LoadLibraryByPathname(libavcodec.so,10)           
-1295163304[5e6334bd1c0]: libavcodec.so incr => 2 (find lib)

the dlopens fails at taht point because /usr/local/lib/ isn't unveiled, but since the libs are preloaded they should be found in the dlopen cache. The only difference i can find between those 3 libraries is that libavcodec.so doesnt have a SONAME tag, while libmozavcodec.so and libmozavutil.so do have one:

$objdump -p /usr/local/lib/firefox/libmozavutil.so.131.0 |grep SO
  SONAME      libmozavutil.so.131.0
$objdump -p /usr/local/lib/firefox/libmozavcodec.so.131.0 |grep SO
  SONAME      libmozavcodec.so.131.0
$objdump -p /usr/local/lib/libavcodec.so.25.0 |grep SO

i'll check but iirc that can make a difference wrt dlopen caching.

what is strange is that is that at that point im unsure if decoding via mozavcodec/mozavutil works...

preloading before sandboxing definitely works:

-1295163304[5e6334bd1c0]: [PID=40179] pr_LoadLibraryByPathname(libmozavcodec.so,1)                        
dlopen: loading: libmozavcodec.so     
dlopen: libmozavcodec.so: done (success).
-1295163304[5e6334bd1c0]: Loaded library libmozavcodec.so (load lib)
-1295163304[5e6334bd1c0]: [PID=40179] pr_LoadLibraryByPathname(libmozavutil.so,1)
dlopen: loading: libmozavutil.so
linking /usr/local/lib/firefox/libmozavutil.so.131.0 as dlopen()ed
dlopen: libmozavutil.so: done (success).
-1295163304[5e6334bd1c0]: Loaded library libmozavutil.so (load lib)
-1295163304[5e6334bd1c0]: [PID=40179] pr_LoadLibraryByPathname(libavcodec.so,1)
dlopen: loading: libavcodec.so
...
dlopen: libavcodec.so: done (success).                                                                    
-1295163304[5e6334bd1c0]: Loaded library libavcodec.so (load lib)                       
[(null) 40179: Main Thread]: D/OpenBSDSandbox /tmp: unveil(/tmp, rwc)                 
[(null) 40179: Main Thread]: D/OpenBSDSandbox /etc/firefox/pledge.rdd: pledge(stdio rpath tmppath recvfd sendfd unix)
[RDD 40179: Main Thread]: D/PlatformDecoderModule PDMInitializer, Init PDMs in RDD process

those logs can be very verbose, i'll try to understand a bit better what happens in which order, but with a simpler patch not moving sandboxing initialization later, it seems i have something working with video decoding forced in the rdd process, but im not sure all formats decoding work given that i dont know what uses mozavcodec/mozavutil.

in light of this, I'm wondering if we should do like we do on Windows and check return values of PR_LoadLibrary() for preloading, so we might catch more bugs ?

(In reply to :gerard-majax from comment #23)

in light of this, I'm wondering if we should do like we do on Windows and check return values of PR_LoadLibrary() for preloading, so we might catch more bugs ?

where so ? because in https://searchfox.org/mozilla-central/source/dom/media/ipc/RDDProcessImpl.cpp#28 i dont see the return values being checked on windows..

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

(In reply to :gerard-majax from comment #23)

in light of this, I'm wondering if we should do like we do on Windows and check return values of PR_LoadLibrary() for preloading, so we might catch more bugs ?

where so ? because in https://searchfox.org/mozilla-central/source/dom/media/ipc/RDDProcessImpl.cpp#28 i dont see the return values being checked on windows..

https://searchfox.org/mozilla-central/source/ipc/glue/UtilityAudioDecoderParent.cpp#74-75,87

(In reply to :gerard-majax from comment #25)

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

(In reply to :gerard-majax from comment #23)

in light of this, I'm wondering if we should do like we do on Windows and check return values of PR_LoadLibrary() for preloading, so we might catch more bugs ?

where so ? because in https://searchfox.org/mozilla-central/source/dom/media/ipc/RDDProcessImpl.cpp#28 i dont see the return values being checked on windows..

https://searchfox.org/mozilla-central/source/ipc/glue/UtilityAudioDecoderParent.cpp#74-75,87

right, hadnt understood you were talking about the utility process. Yes it'd be safer if the code ensured the lib was properly preloaded otherwise unexpected things probably happens (runtime breakage at least)

squaring back to this after some time... after adding some debugging code to nspr, here's what i understand:

  • so far we only preload libmozavcodec.so and libmozavutil.so, using their 'generic' names, and trust ld.so to return us the right lib

there are actually two distinct issues, the first one being:

  • we don't preload systemwide libavcodec.so, so when https://searchfox.org/mozilla-central/source/dom/media/platforms/ffmpeg/FFmpegRuntimeLinker.cpp#77 tries to load it after sandboxing, that fails - preloading the libavcodec.so at the same spot as the other fixes that issue, eg mp4 video decoding works and happens in the RDD process.
  • decoding in the RDD process will only happen if media.allow-audio-non-utility is false, otherwise apparently video decoding happens in the content process

second issue:

  • from my understanding the FFVPXRuntimeLinker bits are only used/called by https://searchfox.org/mozilla-central/source/dom/media/webaudio/FFTBlock.h#47 and i'm not sure what exercises those codepaths
  • the preloading done for those libs doesnt trigger the ld.so cache, because the code uses the full path to the lib (eg dlopen("/usr/local/lib/firefox/libmozavutil.so.131.0")), while the preloading was with libmozavutil.so - to 'fix' this i will try to either modify FFVPXRuntimeLinker so that it doesnt use the full path/version, or to preload with the full path. But i still wont know how to call that code..

a simple bit of code reproducing the behaviour showing this:

[15:47] nikki:~/ $cat testunveil.c                                                                                                                                                                                  
#include <dlfcn.h>
#include <stdio.h>
#include <unistd.h>

int main() {
        int r;
        void *mozavcodec, *mozavutil, *avcodec;
        /* preloading calls PR_LoadLibrary("libavcodec.so") with no flags => https://searchfox.org/mozilla-central/source/dom/media/ipc/RDDProcessImpl.cpp#31 */
        avcodec=dlopen("libavcodec.so", 0);
        mozavcodec=dlopen("libmozavcodec.so", 0);
        printf("avcodec is %p, libmozavcodec is %p\n", avcodec, mozavcodec);
        r=unveil("/usr/lib/","r");
        printf("r is %d\n", r);
        /* loading after unveil calls PR_LoadLibraryWithFlags(lspec, PR_LD_NOW | PR_LD_LOCAL) -> https://searchfox.org/mozilla-central/source/dom/media/platforms/ffmpeg/FFmpegRuntimeLinker.cpp#77 */
        avcodec=dlopen("libavcodec.so", RTLD_NOW | RTLD_LOCAL);
        /* ffvpx does this with the soname ? https://searchfox.org/mozilla-central/source/dom/media/platforms/ffmpeg/ffvpx/FFVPXRuntimeLinker.cpp#45 */
        mozavcodec=dlopen("/usr/local/lib/firefox/libmozavcodec.so.131.0", RTLD_NOW | RTLD_LOCAL);
        printf("avcodec is %p, libmozavcodec is %p\n", avcodec, mozavcodec);
}

once unveil is called the process doesnt have access anymore to the actual files, because libavcodec lives under /usr/local - running it gives this:

$LD_LIBRARY_PATH=/usr/local/lib/firefox/ ./testunveil 
avcodec is 0x8987be11800, libmozavcodec is 0x8987be10800
r is 0
avcodec is 0x8987be11800, libmozavcodec is 0x0

i dont know why/how the full path to the lib is used/constructed, but apparently removing the full path helps, eg if the second dlopen is called with libmozavcodec.so.131.0 then it finds the preloaded library.

Thanks!

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

there are actually two distinct issues, the first one being:

you mean next to preloading libmozavcodec.so and libmozavutils.so, you also preload libavcodec.so ? If so, I dont think it's a huge change, should be ok

  • decoding in the RDD process will only happen if media.allow-audio-non-utility is false, otherwise apparently video decoding happens in the content process

Given we want to enforce media.allow-audio-non-utility=false then it makes sense. Curious: does only a few decoding happens in Content instead of RDD ? Or all of it?

we don't preload systemwide libavcodec.so, so when https://searchfox.org/mozilla-central/source/dom/media/platforms/ffmpeg/FFmpegRuntimeLinker.cpp#77 tries to load it after sandboxing, that fails - preloading the libavcodec.so at the same spot as the other fixes that issue, eg mp4 video decoding works and happens in the RDD process.
decoding in the RDD process will only happen if media.allow-audio-non-utility is false, otherwise apparently video decoding happens in the content process

This is expected.

from my understanding the FFVPXRuntimeLinker bits are only used/called by https://searchfox.org/mozilla-central/source/dom/media/webaudio/FFTBlock.h#47 and i'm not sure what exercises those codepaths

It's also used so that we can use the same code in Firefox to use the system's ffmepg (to decode patented formats) and our own vendored ffmpeg (to ensure we can always decode royalty free formats regardless of what is installed on the system).

the preloading done for those libs doesnt trigger the ld.so cache, because the code uses the full path to the lib (eg dlopen("/usr/local/lib/firefox/libmozavutil.so.131.0")), while the preloading was with libmozavutil.so - to 'fix' this i will try to either modify FFVPXRuntimeLinker so that it doesnt use the full path/version, or to preload with the full path. But i still wont know how to call that code..

What would exercise that code would be to play a vp8/vp9 video (e.g. most YouTube videos) or to do something in web audio that uses an FFT, such as https://padenot.github.io/loopa/ (warning flashing animation): just click play: if it makes sound and there's a spectrum drawn on the page it's good.

(In reply to :gerard-majax from comment #28)

Thanks!

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

there are actually two distinct issues, the first one being:

you mean next to preloading libmozavcodec.so and libmozavutils.so, you also preload libavcodec.so ? If so, I dont think it's a huge change, should be ok

yeah i have https://cgit.rhaalovely.net/mozilla-firefox/tree/patches/patch-dom_media_ipc_RDDProcessImpl_cpp?h=beta since some betas and with that video decoding apparently works in the RDD process (when media.allow-audio-non-utility is false)

  • decoding in the RDD process will only happen if media.allow-audio-non-utility is false, otherwise apparently video decoding happens in the content process

Given we want to enforce media.allow-audio-non-utility=false then it makes sense. Curious: does only a few decoding happens in Content instead of RDD ? Or all of it?

i wouldnt know if its all or a few. going through tons of logging output isnt always easy :)

(In reply to Paul Adenot (:padenot) from comment #29)

the preloading done for those libs doesnt trigger the ld.so cache, because the code uses the full path to the lib (eg dlopen("/usr/local/lib/firefox/libmozavutil.so.131.0")), while the preloading was with libmozavutil.so - to 'fix' this i will try to either modify FFVPXRuntimeLinker so that it doesnt use the full path/version, or to preload with the full path. But i still wont know how to call that code..

What would exercise that code would be to play a vp8/vp9 video (e.g. most YouTube videos) or to do something in web audio that uses an FFT, such as https://padenot.github.io/loopa/ (warning flashing animation): just click play: if it makes sound and there's a spectrum drawn on the page it's good.

yeah i have sound and the spectrum on that page, or i get video ads on youtube, the audio decoding is done in the utility process, which hasnt the same tight sandboxing as RDD (even if id like to tighten it further).

[Utility 75567: MediaPDecoder #1]: V/PlatformDecoderModule ProcessDecode: mDuration=4353µs ; mTime=1388843µs ; mTimecode=1388843µs

so this bit works but only because it happens in the utility process, which can dlopen the mozavcodec/mozavutil after sandboxing - i'd like to fix that so that it finds the preloaded library, which would allow to tighten the sandbox.

Now the extra bonus question is, what can tell me if that web audio bit uses an FFT from... systemwide avcodec or libmozavcodec ? when there's systemwide ffmpeg which is found, it's preferred to the vendored one ?

Now the extra bonus question is, what can tell me if that web audio bit uses an FFT from... systemwide avcodec or libmozavcodec ? when there's systemwide ffmpeg which is found, it's preferred to the vendored one ?

Not what but who: me. We don't support getting those FFT functions from a system ffmpeg.

Flags: needinfo?(padenot)

my concern is that if something ends up using the ffvpxruntimelinker codepaths in the RDD process, it will badly fail, because with my debugging-enabled nspr i get this log for the RDD process:

  • preloading of the 3 libs
[PID=33297] pr_LoadLibraryByPathname(libmozavcodec.so,1)                                                                                                                                    
[PID=33297] pr_LoadLibraryByPathname dlopen(libmozavcodec.so) returned d2dbd56b800                        
Loaded library libmozavcodec.so (load lib)                                                                                                                                                  
[PID=33297] pr_LoadLibraryByPathname(libmozavutil.so,1)                                                                                                                                     
[PID=33297] pr_LoadLibraryByPathname dlopen(libmozavutil.so) returned d2d6b702000                                                                                                           
Loaded library libmozavutil.so (load lib)                                                                                                                                                   
[PID=33297] pr_LoadLibraryByPathname(libavcodec.so,1)                                                                                                                                       
[PID=33297] pr_LoadLibraryByPathname dlopen(libavcodec.so) returned d2d44ccb000                                                                                                             
Loaded library libavcodec.so (load lib)

at that point we sandbox the RDD process so it doesnt have access anymore to anything else than /tmp, and then the PDM initialization kicks in

[RDD 33297: Main Thread]: D/PlatformDecoderModule PDMInitializer, Init PDMs in RDD process                                                                                                                           
pr_LoadLibraryByPathname(/usr/local/lib/firefox/libmozavutil.so.131.0,10)                     
[PID=33297] pr_LoadLibraryByPathname dlopen(/usr/local/lib/firefox/libmozavutil.so.131.0) returned 0      
[PID=33297] pr_LoadLibraryByPathname(/usr/local/lib/firefox/libmozavcodec.so.131.0,10)                    
[PID=33297] pr_LoadLibraryByPathname dlopen(/usr/local/lib/firefox/libmozavcodec.so.131.0) returned 0     
[PID=33297] pr_LoadLibraryByPathname(libavcodec.so,10)                                                                                                                                      
libavcodec.so incr => 2 (find lib)

-> only the FFmpegRuntimeLinker::Init succeeds (because the libavcodec.so lib is found in the ld.so cache), FFVPXRuntimeLinker::Init fails to re-dlopen the libs as the ld.so cache is missed (because of the fullpath added by SetNativeLeafName in https://searchfox.org/mozilla-central/source/dom/media/platforms/ffmpeg/ffvpx/FFVPXRuntimeLinker.cpp#90 ?)

(In reply to Paul Adenot (:padenot) from comment #31)

Now the extra bonus question is, what can tell me if that web audio bit uses an FFT from... systemwide avcodec or libmozavcodec ? when there's systemwide ffmpeg which is found, it's preferred to the vendored one ?

Not what but who: me. We don't support getting those FFT functions from a system ffmpeg.

ok good, but are sure those won't be required in the RDD process at some point, for video ?

ok good, but are sure those won't be required in the RDD process at some point, for video ?

The FFT code used by a particular mozavacodec or system avcodec is going to use the FFT code that's found inside this particular mozavcodec or system avcodec, this uses static linking within the same .so.

It just happens that it's a good FFT implementation and useful to implement the Web Audio API, so a Content process fetches those function pointers at runtime and calls those function if it needs to use them.

that matches what i've finally seen, i though the FFT code was called from the utility process, but its apparently indeed called from a content process, eg playing the sound on https://padenot.github.io/loopa/ i see that the funcs are called from a content process with a wide sandboxing.

[Child 18944: Main Thread]: D/OpenBSDSandbox /etc/firefox/pledge.content: pledge(stdio rpath wpath cpath recvfd sendfd prot_exec unix drm ps inet dns getpw)
...
[Child 18944: Main Thread]: D/OpenBSDSandbox FFVPXRuntimeLinker::MozAVLink(/usr/local/lib/firefox/libmozavcodec.so.131.0) called, found 1f417959390                                                                  
[Child 18944: Main Thread]: D/OpenBSDSandbox FFVPXRuntimeLinker::GetRDFTFuncs() called, i have ffvpx funcs

but then, the audio is playing, so why am i seeing ProcessDecode output from an utility process ?

[Child 18944: Main Thread]: D/PlatformDecoderModule PDMInitializer, Init PDMs in Content process
[Child 18944: MediaSupervisor #1]: D/PlatformDecoderModule Sandbox RDD decoder rejects requested type audio/wave; codecs=1
[Child 18944: MediaSupervisor #1]: D/PlatformDecoderModule Sandbox Utility Generic decoder supports requested type audio/wave; codecs=1
[Child 18944: MediaSupervisor #1]: D/PlatformDecoderModule Sandbox Utility Generic decoder supports requested type audio/wave; codecs=1
[Child 18944: MediaSupervisor #1]: D/PlatformDecoderModule Sandbox RDD decoder rejects requested type audio/wave; codecs=1
[Child 18944: MediaSupervisor #1]: D/PlatformDecoderModule Sandbox Utility Generic decoder supports requested type audio/wave; codecs=1
[Utility 96145: MediaSupervisor #3]: D/OpenBSDSandbox FFmpegRuntimeLinker::Init() called, sLinkStatus=1,sLinkStatusLibraryName='libavcodec.so'
[Utility 96145: MediaSupervisor #3]: D/PlatformDecoderModule FFmpeg decoder supports requested type 'audio/wave; codecs=1'
[Utility 96145: MediaSupervisor #3]: D/PlatformDecoderModule FFmpeg decoder supports requested type 'audio/wave; codecs=1'
[Child 18944: RemVidChild]: D/PlatformDecoderModule RemoteMediaDataDecoder[1f42bfe69a0] ::RemoteMediaDataDecoder: 1f42bfe69a0 is created
[Child 18944: RemVidChild]: D/PlatformDecoderModule RemoteMediaDataDecoder[1f42bfe69a0] ::operator(): 1f42bfe69a0 RemoteDecoderChild has been initialized - description: ffvpx audio decoder (Utility Generic remote)
, process: utility+audioDecoder_Generic, codec: pcm_s16le
[Utility 96145: MediaPDecoder #1]: V/PlatformDecoderModule ProcessDecode: mDuration=4353µs ; mTime=0µs ; mTimecode=0µs
...
[Utility 96145: MediaPDecoder #1]: V/PlatformDecoderModule ProcessDecode: mDuration=4353µs ; mTime=2068027µs ; mTimecode=2068027µs
...
[Utility 96145: MediaPDecoder #3]: V/PlatformDecoderModule ProcessDecode: mDuration=0µs ; mTime=0µs ; mTimecode=2102857µs         
[Child 18944: MediaPDecoder #1]: D/PlatformDecoderModule RemoteMediaDataDecoder[1f42bfe69a0] ::~RemoteMediaDataDecoder: 1f42bfe69a0 is released

If it's nightly / early beta, you have the pref set to false, ProcessDecode on Utility is 150% audio. Generally speaking, ProcessDecode on Utility is Audio. If you're worried, hack PROCESS_DECODE_LOG in dom/media/TimeUnits.h to exposse __PRETTY_FUNCTION__ as well ? That should ensure you are right.

But the line [Child 18944: RemVidChild]: D/PlatformDecoderModule RemoteMediaDataDecoder[1f42bfe69a0] ::operator(): 1f42bfe69a0 RemoteDecoderChild has been initialized - description: ffvpx audio decoder (Utility Generic remote), process: utility+audioDecoder_Generic, codec: pcm_s16le is already pretty obvious

but then, the audio is playing, so why am i seeing ProcessDecode output from an utility process ?

This small test page does two things: decode a small audio file and then play it back, looped, and drawing the spectrum using an FFT.

Decoding the file happens in the Utility process, all the rest happens in the Content process.

(In reply to Paul Adenot (:padenot) from comment #38)

but then, the audio is playing, so why am i seeing ProcessDecode output from an utility process ?

This small test page does two things: decode a small audio file and then play it back, looped, and drawing the spectrum using an FFT.

Decoding the file happens in the Utility process, all the rest happens in the Content process.

hah, thanks. That explains !

now i'm trying to hack https://searchfox.org/mozilla-central/source/dom/media/platforms/ffmpeg/ffvpx/FFVPXRuntimeLinker.cpp#90 to avoid passing a full path, i just want a simple filename, but the nsIFile interface isnt helping me much.. right now i'm trying such horror instead:

@@ -35,6 +41,9 @@ static PRLibrary* MozAVLink(nsIFile* aFile) {
 #ifdef XP_WIN
   lspec.type = PR_LibSpec_PathnameU;
   lspec.value.pathname_u = path.get();
+#elif defined(XP_OPENBSD)
+  lspec.type = PR_LibSpec_Pathname;
+  lspec.value.pathname = basename(strdup(path.get()));
 #else
   lspec.type = PR_LibSpec_Pathname;
   lspec.value.pathname = path.get();

but that's gross :)

gross... but it works - with that patch calling basename, in the rdd process which doesnt have access to /usr/local/lib after sandboxing i see that the preloaded libs are found in the ld.so cache (the addresses in memory match now for libmozavcodec and libmozavutil).

1421733528[c21abf6b1c0]: [PID=69437] pr_LoadLibraryByPathname(libmozavcodec.so,1)                                                                                                                                    
1421733528[c21abf6b1c0]: [PID=69437] pr_LoadLibraryByPathname dlopen(libmozavcodec.so) returned c21b1486000                                                                                                          
1421733528[c21abf6b1c0]: Loaded library libmozavcodec.so (load lib)                                                                                                                                                  
[(null) 69437: Main Thread]: D/OpenBSDSandbox RDDProcessImpl::Init(), preloaded libmozavcodec, found c21abf6c870                                                                                                     
1421733528[c21abf6b1c0]: [PID=69437] pr_LoadLibraryByPathname(libmozavutil.so,1)                                                                                                                                     
1421733528[c21abf6b1c0]: [PID=69437] pr_LoadLibraryByPathname dlopen(libmozavutil.so) returned c21b1487000                                                                                                           
1421733528[c21abf6b1c0]: Loaded library libmozavutil.so (load lib)                                                                                                                                                   
[(null) 69437: Main Thread]: D/OpenBSDSandbox RDDProcessImpl::Init(), preloaded libmozavutil, found c21abf3f360                                                                                                      
1421733528[c21abf6b1c0]: [PID=69437] pr_LoadLibraryByPathname(libavcodec.so,1)                                                                                                                                       
1421733528[c21abf6b1c0]: [PID=69437] pr_LoadLibraryByPathname dlopen(libavcodec.so) returned c21b1486800                                                                                                             
1421733528[c21abf6b1c0]: Loaded library libavcodec.so (load lib)                                                                                                                                                     
[(null) 69437: Main Thread]: D/OpenBSDSandbox RDDProcessImpl::Init(), preloaded libavcodec, found c21abf6c360                                                                                                        
[(null) 69437: Main Thread]: D/OpenBSDSandbox /tmp: unveil(/tmp, rwc)                                                                                                                                                
[(null) 69437: Main Thread]: D/OpenBSDSandbox /etc/firefox/pledge.rdd: pledge(stdio rpath tmppath recvfd sendfd unix)                                                                                                
[RDD 69437: Main Thread]: D/PlatformDecoderModule PDMInitializer, Init PDMs in RDD process                                                                                                                           
1421733528[c21abf6b1c0]: [PID=69437] pr_LoadLibraryByPathname(libmozavutil.so.131.0,10)                                                                                                                              
1421733528[c21abf6b1c0]: [PID=69437] pr_LoadLibraryByPathname dlopen(libmozavutil.so.131.0) returned c21b1487000                                                                                                     
1421733528[c21abf6b1c0]: Loaded library libmozavutil.so.131.0 (load lib)                                                                                                                                             
[RDD 69437: Main Thread]: D/OpenBSDSandbox FFVPXRuntimeLinker::MozAVLink(/usr/local/lib/firefox/libmozavutil.so.131.0) called, found c21e81f61e0                                                                     
1421733528[c21abf6b1c0]: [PID=69437] pr_LoadLibraryByPathname(libmozavcodec.so.131.0,10)                                                                                                                             
1421733528[c21abf6b1c0]: [PID=69437] pr_LoadLibraryByPathname dlopen(libmozavcodec.so.131.0) returned c21b1486000                                                                                                    
1421733528[c21abf6b1c0]: Loaded library libmozavcodec.so.131.0 (load lib)                                                                                                                                            
[RDD 69437: Main Thread]: D/OpenBSDSandbox FFVPXRuntimeLinker::MozAVLink(/usr/local/lib/firefox/libmozavcodec.so.131.0) called, found c21e82158a0                              
[RDD 69437: Main Thread]: D/OpenBSDSandbox FFmpegRuntimeLinker::Init() called, sLinkStatus=0,sLinkStatusLibraryName=''                                                         
1421733528[c21abf6b1c0]: [PID=69437] pr_LoadLibraryByPathname(libavcodec.so,10)                                                                                                                                      
1421733528[c21abf6b1c0]: libavcodec.so incr => 2 (find lib)

is this something 'acceptable' ? or there's a better way to strip the full path to the lib ?

Flags: needinfo?(padenot)

passing the full path fails to trigger the ld.so cache that was
populated by preloading libmozavcodec.so and libmozavutil.so

would allow to tighten sandboxing of the utility process.

the usage of basename(strdup()) is horrible so i welcome suggestions
on how to build a filename from an nsIFile.

With the current sandboxing configuration, FFmpegRuntimeLinker::Init()
can't access libavcodec.so, so video decoding fails in the RDD process
and fallbacks to the content process.

With media.allow-audio-non-utility knob (from bug #1850904) toggled
to false enforcing audio decoding in the Utility process, this has the
side effect of enforcing video decoding in the RDD process, and thus
video decoding fails.

Preloading libavcodec.so like it was done for libmozavcodec.so and
libmozavutil.so in bug #1713745 fixes it, as the second dlopen() call
hits the ld.so cache and returns the preloaded library handle.

replaces/supersedes https://phabricator.services.mozilla.com/D190475

Alex is handling the reviews here, he'll know what's best.

Flags: needinfo?(padenot)

makes sure that dlopen() returns the preloaded library handle in
FFVPXRuntimeLinker

https://phabricator.services.mozilla.com/D193350

Attachment #9363110 - Attachment is obsolete: true
Attachment #9357445 - Attachment is obsolete: true
Blocks: 1863873

Comment on attachment 9363113 [details]
Bug 1856301: [OpenBSD] also preload libavcodec.so before sandboxing r?gerard-majax

Beta/Release Uplift Approval Request

  • User impact if declined: audio and video decoding happening on content process in release, blocked in beta, and we are working to enable complete blocking in release on bug 1863873
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): only impacts OpenBSD
  • String changes made/needed:
  • Is Android affected?: Yes
Attachment #9363113 - Flags: approval-mozilla-release?
Attachment #9363279 - Flags: approval-mozilla-release?
Pushed by alissy@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/f6d59e68442d [OpenBSD] only pass the filename to PR_LoadLibraryWithFlags r=gerard-majax

https://hg.mozilla.org/mozilla-central/rev/f6d59e68442d

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
status-firefox121: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 121 Branch

made a mistake, landed only one patch

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Pushed by alissy@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/839befe903d4 [OpenBSD] also preload libavcodec.so before sandboxing r=gerard-majax

https://hg.mozilla.org/mozilla-central/rev/839befe903d4

Status: REOPENED → RESOLVED
Closed: 2 years ago → 2 years ago
status-firefox121: affected → fixed
Resolution: --- → FIXED

fwiw, if it's not backported to mozilla-release (and i can totally understand given that we're already at RC1) i've patches lined up for backport with https://cgit.rhaalovely.net/mozilla-firefox/commit/?h=release&id=e83d52b3ad3f2f6a7831b6b713972eb6e9d720eb so when i update our port to 120 the openbsd users will dogfood that too.

Comment on attachment 9363113 [details]
Bug 1856301: [OpenBSD] also preload libavcodec.so before sandboxing r?gerard-majax

Approved for 120.0rc2

Attachment #9363113 - Flags: approval-mozilla-release? → approval-mozilla-release+
Attachment #9363279 - Flags: approval-mozilla-release? → approval-mozilla-release+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: