Closed Bug 1693083 Opened 4 years ago Closed 4 years ago

Sandbox: seccomp sandbox violation by syscall 16

Categories

(Core :: Security: Process Sandboxing, defect, P5)

Product:
Core
Component:
Security: Process Sandboxing
Version:
Firefox 87
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1686681

People

(Reporter: pmenzel+bugzilla.mozilla.org, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

Attachments

(1 file)

nightly-log.txt
56.71 KB, text/plain
Details
Attached file nightly-log.txt —

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0

Steps to reproduce:

Under Debian sid/unstable (Linux 5.10.13) with Mozilla Firefox/Nightly 87.0a1, 20210215162656 and enabled VA-API, browse to some Web site with video content.

MOZ_X11_EGL=1 MOZ_LOG="PlatformDecoderModule:5" nightly

I can only reproduce it with the 5 in MOZ_LOG and not 1.

Actual results:

No video is played (black boxes in BigBlueButton for example) The process crashes and core dump files are created. The messages on the terminal contain several ones similar to the messages below (full log attached):

Sandbox: seccomp sandbox violation: pid 18351, tid 19297, syscall 16, args 2 21505 139935272106912 139935272110212 139935272106976 139935272106672.  K

illing process.
Sandbox: seccomp sandbox violation: pid 19306, tid 19322, syscall 16, args 2 21505 140706743036832 140706743040132 140706743036896 140706743036592. K
illing process.

With

MOZ_X11_EGL=1 MOZ_LOG="PlatformDecoderModule:1" nightly

no crashes are happening, but the GPU is not used for decoding according to sudo intel_gpu_top.

Expected results:

Videos should be decoded with GPU hardware acceleration, and no seccomp sandbox violations should happen.

(No idea, if it’s related to https://bugzilla.mozilla.org/show_bug.cgi?id=1680932 which I got in the past.)

enabled VA-API

Just to confirm, this is a setting you changed, not the default config?

Flags: needinfo?(pmenzel+bugzilla.mozilla.org)

Trying this here (Arch Linux, MOZ_ENABLE_WAYLAND=1, MOZ_LOG=PlatformDecoderModule:5, fresh profile without changes, opening http://demo.nimius.net/video_test/) resulted in two crashes of the RDD process:

With MOZ_LOG, VP8 decoding is broken while H.264 decoding works. Without MOZ_LOG, the first crash disappears and decoding seems to work.

Thank you for the test and confirmation.

Flags: needinfo?(pmenzel+bugzilla.mozilla.org)

Bug 1685463 just got fixed, so that second problem will go away.

Looking at the stacks from comment 2, the first problem specifically exists because logging was enabled, i.e. the logging code is trying to shove things where the sandbox won't allow it. That's not unexpected, and you could work around it with "security.sandbox.content.syscall_whitelist=16". We have some projects in the pipe to make it easier to log things from sandboxed processes but nothing right now - and the logging calls come from inside libav

I think this is a WONTFIX for now?

Severity: -- → S4
Priority: -- → P5
Depends on: 1345046
See Also: → 1344776

I think the FFmpegLibWrapper code should be using av_log_set_callback so FFmpeg calls mozilla logging instead of trying to access the terminal.

(In reply to Gian-Carlo Pascutto [:gcp] from comment #4)

Bug 1685463 just got fixed, so that second problem will go away.

Indeed.

Looking at the stacks from comment 2, the first problem specifically exists because logging was enabled, i.e. the logging code is trying to shove things where the sandbox won't allow it. That's not unexpected, and you could work around it with "security.sandbox.content.syscall_whitelist=16".

Thank you. That indeed worked.

We have some projects in the pipe to make it easier to log things from sandboxed processes but nothing right now - and the logging calls come from inside libav

I think this is a WONTFIX for now?

If that is expected, why can’t logging be disabled in that situation?

If that is expected, why can’t logging be disabled in that situation?

It's possible in theory, perhaps by clearing MOZ_LOG if we know the child process will be too heavily sandboxed. But it's not implemented and I suspect we'd rather fix MOZ_LOG to work in the first place rather than spending time on that.

I don't think this is related to logging, I'm getting it even without logging enabled. There is a backtrace of the crash:

#0 0x00007f8e9c39155d in syscall () at /lib64/libc.so.6
#1 0x00007f8e8899254c in mozilla::SandboxCrash(int, siginfo_t*, void*) (nr=31, info=0x7f8e742fd9f0, void_context=0x7f8e742fd4c0)
at /home/komat/src/security/sandbox/linux/glue/SandboxCrash.cpp:114
#2 0x00007f8e9c8d8aeb in mozilla::SigSysHandler(int, siginfo_t*, void*) (nr=31, info=0x7f8e742fd9f0, void_context=0x7f8e742fd8c0) at /home/komat/src/security/sandbox/linux/Sandbox.cpp:152
#3 0x00007f8e9c7c61e0 in <signal handler called> () at /lib64/libpthread.so.0
#4 0x00007f8e9c38d5db in ioctl () at /lib64/libc.so.6
#5 0x00007f8e7f0d9440 in drmIoctl (fd=fd@entry=21, request=request@entry=3225445376, arg=arg@entry=0x7f8e783f1300) at ../xf86drm.c:191
#6 0x00007f8e7f0d9979 in drmGetVersion (fd=21) at ../xf86drm.c:843
#7 0x00007f8e9b3432d0 in VA_DRM_GetNumCandidates (ctx=<optimized out>, ctx=0x7f8e9c0c8a60, num_candidates=0x7f8e742fe0a4) at va_drm_utils.c:61
#8 va_DisplayContextGetNumCandidates (pDisplayContext=<optimized out>, num_candidates=0x7f8e742fe0a4) at va_drm.c:64
#9 0x00007f8e7848cc7e in va_getDriverNumCandidates (num_candidates=0x7f8e742fe0a4, dpy=0x7f8e9c09f760) at va.c:359
#10 vaInitialize (dpy=0x7f8e9c09f760, major_version=0x7f8e742fe16c, minor_version=0x7f8e742fe168) at va.c:724
#11 0x00007f8e8e19c65f in mozilla::FFmpegVideoDecoder<46465650>::CreateVAAPIDeviceContext() (this=0x7f8e9c0eec00) at /home/komat/src/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp:246
#12 0x00007f8e8e19caec in mozilla::FFmpegVideoDecoder<46465650>::InitVAAPIDecoder() (this=0x7f8e9c0eec00) at /home/komat/src/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp:285
#13 0x00007f8e8e19d3db in mozilla::FFmpegVideoDecoder<46465650>::Init() (this=0x7f8e9c0eec00) at /home/komat/src/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp:387
#14 0x00007f8e8e1146b5 in mozilla::MediaDataDecoderProxy::Init()::$_17::operator()() const (this=0x7f8e7ef40700) at /home/komat/src/dom/media/platforms/wrappers/MediaDataDecoderProxy.cpp:18
#15 0x00007f8e8e114322 in mozilla::detail::ProxyFunctionRunnable<mozilla::MediaDataDecoderProxy::Init()::$_17, mozilla::MozPromise<mozilla::TrackInfo::TrackType, mozilla::MediaResult, true> >::Run() (this=0x7f8e7efaedd0) at /home/komat/src/objdir/dist/include/mozilla/MozPromise.h:1641

And the blocked ioctl call is:

838 drm_public drmVersionPtr drmGetVersion(int fd)
839 {
840 drmVersionPtr retval;
841 drm_version_t *version = drmMalloc(sizeof(*version));
842
843 if (drmIoctl(fd, DRM_IOCTL_VERSION, version)) { <<< HERE
844 drmFreeKernelVersion(version);
845 return NULL;
846 }

So I guess we can enable the DRM_IOCTL_VERSION call in RDD process, can't we?

The sandbox line is:

Sandbox: seccomp sandbox violation: pid 35159, tid 35171, syscall 16, args 21 3225445376 140249879483136 140250483646400 0 140250483646656. Killing process.

Flags: needinfo?(gpascutto)

btw. Yes, it's disabled now but I'd like to look at RDD/VAAPI to make it working as we perhaps want to enabled it for ffmpeg too in some long term, don't we? I guess the RDD setup may me similar for ffmpeg/ffvpx.

The av_log_set_callback() log redirecting is filed as Bug 1697889, I'll look at it.

I don't think this is related to logging, I'm getting it even without logging enabled.

You're getting a different crash, it just happens to be using the ioctl syscall as well. The one in this bug is caused by the logging code calling isatty/tcgetattr, see comment 2.

We have code to handle that (so I guess comment 7 is wrong too in terms of complexity), but it's only in the content policy. It wasn't added to the RDD process when ffmpeg was moved there: https://searchfox.org/mozilla-central/source/security/sandbox/linux/SandboxFilter.cpp#1288

Conversely none of the code knows about DRM_IOCTL_VERSION, so you probably want to track that separately.

Flags: needinfo?(gpascutto)

(In reply to Gian-Carlo Pascutto [:gcp] from comment #11)

Conversely none of the code knows about DRM_IOCTL_VERSION, so you probably want to track that separately.

Okay, filed ad Bug 1698778.
Thanks.

The remaining part of this was already filed, so duping.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: