Closed Bug 1438394 Opened 2 years ago Closed 2 years ago

The fglrx detection from bug 1376910 is sometimes not working.

Categories

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

60 Branch
Unspecified
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla60
Tracking Status
firefox60 --- fixed

People

(Reporter: jld, Assigned: gcp)

References

Details

Crash Data

Attachments

(1 file)

I'm seeing content processes being prevented from calling semget(), with fglrx drivers in the stack… and GPU vendor ID equal to "ATI Technologies Inc.", which means the patch in bug 1376910 *should* be allowing access to SysV IPC, including semaphores.  I don't know what's going on here yet.
Assignee: nobody → gpascutto
Crash Signature: [@ libc-2.19.so@0xe9e37 ] → [@ libc-2.19.so@0xe9e37 ] [@ libatiuki.so.1.0@0x440e ]
#3 Linux top crash for the 2-14 Nightly.
(In reply to Andrew McCreight [:mccr8] from comment #1)
> #3 Linux top crash for the 2-14 Nightly.

I accidentally included a 2-15 build in there, so this may not be accurate.
Priority: -- → P1
Some investigation so far doesn't really show anything. The machines with fglrx I have show the detection working properly, mAllowSysVI being set properly when the policy is constructed, etc
Crash Signature: [@ libc-2.19.so@0xe9e37 ] [@ libatiuki.so.1.0@0x440e ] → [@ libc-2.19.so@0xe9e37 ] [@ libatiuki.so.1.0@0x440e ] [@ libc-2.26.so@0xf7a70 ]
Sandbox: seccomp sandbox violation: pid 3444, tid 3444, syscall 64, args 17908779 1 1974 140733924502176 0 0.  Killing process.
Sandbox: JS frame 0: pageLoaded https://get.webgl.org/ line 193
[Parent 3153, Gecko_IOThread] WARNING: pipe error (148): Connection reset by peer: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353
GPU #1
Active	Yes
Description	ATI Technologies Inc. -- AMD Radeon(TM) R7 Graphics     
Vendor ID	ATI Technologies Inc.
Device ID	AMD Radeon(TM) R7 Graphics     
Driver Version	4.5.13399 Compatibility Profile Context 15.201.1151
https://searchfox.org/mozilla-central/source/security/sandbox/linux/launch/SandboxLaunch.cpp#244

We bail out of this function if there are no unprivileged user spaces (as is the case on this Debian). But the check and env variable setting for SysV IPC is later in this function, so we don't reach it.
Comment on attachment 8956908 [details]
Bug 1438394 - Do SysV IPC check before bailing out early.

https://reviewboard.mozilla.org/r/225872/#review231766

::: security/sandbox/linux/launch/SandboxLaunch.cpp:244
(Diff revision 1)
>    // the child process whether this is the case.
>    aOptions->env_map["MOZ_SANDBOXED"] = "1";
>    PreloadSandboxLib(&aOptions->env_map);
>    AttachSandboxReporter(&aOptions->fds_to_remap);
>  
> +  bool needSysVIPC = false;

It looks like this variable isn't needed.

::: security/sandbox/linux/launch/SandboxLaunch.cpp:256
(Diff revision 1)
> +        // Tell the child process so it can adjust its seccomp-bpf
> +        // policy.
> +        aOptions->env_map["MOZ_SANDBOX_ALLOW_SYSV"] = "1";
> +        needSysVIPC = true;
> +      } else {
> +        flags |= CLONE_NEWIPC;

(I hadn't thought of moving the `CLONE_NEWIPC` up like this; it nicely avoids having the same test in two places.)
Attachment #8956908 - Flags: review?(jld) → review+
Pushed by gpascutto@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/9e92145bb572
Do SysV IPC check before bailing out early. r=jld
https://hg.mozilla.org/mozilla-central/rev/9e92145bb572
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla60
For reference, to reproduce this on Ubuntu: `sudo sysctl -w kernel.unprivileged_userns_clone=0` or set `MOZ_ASSUME_USER_NS=0` in the environment.
You need to log in before you can comment on or make changes to this bug.