1693083 - Sandbox: seccomp sandbox violation by syscall 16

Status: RESOLVED DUPLICATE of bug 1686681

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

Description

[Paul Menzel]

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

Comment 1

[Gian-Carlo Pascutto [:gcp]]

enabled VA-API

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

Comment 2

[Jan Alexander Steffens [:heftig]]

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:

• bp-0f15561b-73d9-4acc-a8d0-36e6a0210225, the one comment #0 encountered
  Denied tcgetattr/isatty

  Sandbox: seccomp sandbox violation: pid 335747, tid 335798, syscall 16, args 2 21505 139898099062304 139898490507200 139898099062368 139898099062064.  Killing process.
  

• bp-93ee1d53-511d-4fed-ba28-020440210225
  Denied pthread_setaffinity_np, bug 1685463

  Sandbox: seccomp sandbox violation: pid 335845, tid 335858, syscall 203, args 335858 128 140173384604976 8 140173384607296 1.  Killing 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.

Comment 3

[Paul Menzel]

Thank you for the test and confirmation.

Comment 4

[Gian-Carlo Pascutto [:gcp]]

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?

Comment 5

[Jan Alexander Steffens [:heftig]]

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

Comment 6

[Paul Menzel]

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

Comment 7

[Gian-Carlo Pascutto [:gcp]]

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.

Comment 8

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

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.

Comment 9

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

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.

Comment 10

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

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

Comment 11

[Gian-Carlo Pascutto [:gcp]]

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.

Comment 12

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

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

Comment 13

[Gian-Carlo Pascutto [:gcp]]

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