Crashes with an AMD GPU with Mesa >= 19.3.4 and seccomp #3219
Comments
|
|
|
Firefox 73.0 hangs in the same way. |
|
Please try with various |
I've confirmed that disabling seccomp via Edit: Tested this with v73.0 |
|
@leogx9r you had same issue as OP related to amd gpu on gentoo? |
Same issue, different OS. I've experienced this on Arch Linux. It works fine with NVIDIA GPUs so I'd imagine it may be a kernel bug or an updated package causing it as it only started happening recently, as in within the past week to two. To further add on to this issue, when using seccomp, startup takes around 10-15 seconds on an SSD in contrast to just under 2 seconds and GPU compositing fails, falling back to basic CPU rendering. You can check this via |
|
This behavior showed up for me in Arch right now with Mesa 19.3.4. It works fine if I downgrade Mesa packages to 19.3.3, so I'm thinking the problem is related to a change in Mesa 19.3.4. |
|
On 2020-02-14 12:57, Ropid wrote:
This behavior showed up for me in Arch right now with Mesa 19.3.4. It
works fine if I downgrade Mesa packages to 19.3.3, so I'm thinking the
problem is related to a change in Mesa 19.3.4.
Good catch! I don't have one of my failing systems with me at the
moment, but glancing at the Mesa Git repo between 19.3.3 and 19.3.4
shows me
https://gitlab.freedesktop.org/mesa/mesa/commit/ed271a9c2f40f8ec881bf3e4568d35dbfcd9cf70
which introduced a call to `kcmp`, which looks to be blocked by the
default seccomp rules:
```
$ firejail --seccomp.print=4012
[...]
002d: 15 1b 00 00000138 jeq kcmp 0049 (false 002e)
[...]
0049: 06 00 01 00000000 ret KILL
```
Does it work on Mesa 19.3.4 if you start Firefox with `firejail
--ignore=seccomp '--seccomp=!kcmp,!chroot' firefox`?
|
|
Yes, it is blocked:
I don't think that this works, |
|
On 2020-02-14 13:47, rusty-snake wrote:
Yes, it is blocked:
https://github.com/netblue30/firejail/blob/master/etc/templates/syscalls.txt#L36
> f you start Firefox with `firejail
--ignore=seccomp '--seccomp=!kcmp,!chroot' firefox`?
I don't think that this works, `firejail '--seccomp=!kcmp' firefox`
should be enough to add the exception.
I tried that, but that still uses the seccomp rules from the profile:
```
$ firejail '--seccomp=!kcmp' --profile=firefox bash
Reading profile /etc/firejail/firefox.profile
[...]
Seccomp list in: !chroot, check list: @default-keep, prelist: unknown,
```
And `firejail --seccomp.print=$PID` claims it's still blocked.
Compare with this:
```
$ firejail --ignore=seccomp '--seccomp=!kcmp,!chroot' --profile=firefox
bash
[...]
Seccomp list in: !kcmp,!chroot, check list: @default-keep, prelist:
unknown,unknown,
```
```
$ firejail --seccomp.print=10931
[...]
0007: 15 00 01 00000138 jeq kcmp 0008 (false 0009)
0008: 06 00 00 7fff0000 ret ALLOW
```
|
This indeed fixes the issue with the latest mesa version. |
|
I can confirm that |
creideiki
changed the title
Mesa 19.3.4 on AMDGPU started using kcmp(), which is blocked by the default sandbox. Explicitly allow it here until Firejail decides on a permanent solution. Upstream bug: netblue30/firejail#3219
Mesa 19.3.4 on AMDGPU started using kcmp(), which is blocked by the default sandbox. Explicitly allow it here until Firejail decides on a permanent solution. Upstream bug: netblue30/firejail#3219
|
Looking at the Mesa source code, only the AMDGPU code calls Would the best way forward be inserting |
|
Possible all profiles without find no no3d# Copyright © 2020 rusty-snake
#
# Permission to use, copy, modify, and distribute this software for any
# purpose with or without fee is hereby granted, provided that the above
# copyright notice and this permission notice appear in all copies.
#
# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
from os import listdir, readlink
for prg in listdir("/usr/local/bin"):
if readlink("/usr/local/bin/" + prg) == "/usr/bin/firejail":
with open(f"/etc/firejail/{prg}.profile") as prf:
profile = list(prf)
if "no3d\n" in profile:
continue
elif "# Redirect\n" in profile:
if profile[-1][:7] != "include":
print("WARN: cound not find included profile for {prg}.profile")
with open("/etc/firejail/" + profile[-1][8:-1]) as fd:
no3d = False
for line in fd:
if line == "no3d\n":
no3d = True
if not no3d:
print(f"no no3d in {prg}")
else:
print(f"no no3d in {prg}") |
|
FYI: #3267 |
|
I can reproduce this with many profiles under Fedora 32, which ships Mesa 20.0.1. |
This change * reinstates firejail usage for Mozilla products and * changes the firejail invocation to use ``--ignore=seccomp.'' Not depicted in this change was the insertion of ``seccomp !kcmp'' in firefox-common.profile, which by itself appears insufficient (allows the window to draw and nothing else). Issue in question is netblue30/firejail#3219
|
Here is a hacky patch to use in the meantime |
|
Instead of allowing kcmp(), would it work to make it return ENOSYS (or EPERM) instead? Manual page mentions that kcmp() is not always available (needs CONFIG_CHECKPOINT_RESTORE), so the drivers should handle that case. Though if kcmp() is considered safe (comparison of resources of two processes owned by the same user does not seem very dangerous), I wouldn't mind if it was removed. |
It would be great to change seccomp filter to use EPERM/ENOSYS globally. I think KILL was proven unsustainable at this point and security difference is quite negligible. Moreover if we're going to allow syscalls that cause issues then KILL is less secure in the end. |
The problem with that is that the call was introduced to fix a memory leak: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3202
Yes, this makes Mesa's use of it very weird, but I haven't had the time to raise that issue with them. |
Agreed, also systemd has made the change. I'll make a PR. |
|
See #3301. |
|
Even with EPERM this is not fixed. I am using https://gist.github.com/SkewedZeppelin/300447ea70be8aef106b8d8602881134 on my personal builds |
rusty-snake
changed the title
I can confirm. Firejail 0.9.64 on Artix using AMDGPU breaks Steam (see #3267)
For reference, this is what it looks like on 19.3.4 (it hasn't changed too much $ git checkout mesa-19.3.4
HEAD is now at 7a3190eb918 VERSION: bump version for 19.3.4
$ grep -Fnr kcmp src/
src/util/os_file.c:37:#include <linux/kcmp.h>
src/util/os_file.c:140: return syscall(SYS_kcmp, pid, pid, KCMP_FILE, fd1, fd2) == 0;
$ cat src/util/os_file.c
// ...
#if defined(__linux__)
// ...
bool
os_same_file_description(int fd1, int fd2)
{
pid_t pid = getpid();
return syscall(SYS_kcmp, pid, pid, KCMP_FILE, fd1, fd2) == 0;
}
#else
// ...
$ git checkout mesa-20.0.0
HEAD is now at 9abde3412d3 VERSION: bump for 20.0.0 release
$ grep -Fnr os_same_file_description src/
src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c:383: if (os_same_file_description(sws_iter->fd, ws->fd)) {
src/util/os_file.h:39:os_same_file_description(int fd1, int fd2);
src/util/os_file.c:136:os_same_file_description(int fd1, int fd2)
src/util/os_file.c:155:os_same_file_description(int fd1, int fd2)Indeed, but since 20.1.1 it seems that other drivers might also be affected: $ git checkout mesa-20.1.1
HEAD is now at 127c2be9c53 VERSION: bump to 20.1.1 release
$ grep -Fnr os_same_file_description src/
src/gallium/drivers/iris/iris_bufmgr.c:1539: int ret = os_same_file_description(drm_fd, bufmgr->fd);
src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c:375: r = os_same_file_description(sws_iter->fd, ws->fd);
src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c:388: os_log_message("amdgpu: os_same_file_description couldn't "
src/util/os_file.h:45:os_same_file_description(int fd1, int fd2);
src/util/os_file.c:140:os_same_file_description(int fd1, int fd2)
src/util/os_file.c:163:os_same_file_description(int fd1, int fd2)
src/mesa/drivers/dri/i965/brw_bufmgr.c:1642: int ret = os_same_file_description(drm_fd, bufmgr->fd);And the list appears to be increasing... $ git checkout master
Already on 'master'
Your branch is up to date with 'origin/master'.
$ git log --oneline --no-decorate -n 1
483657de323 aco: use mubuf helper in select_gs_copy_shader
$ grep -Fnr os_same_file_description src/
src/gallium/drivers/iris/iris_bufmgr.c:1552: int ret = os_same_file_description(drm_fd, bufmgr->fd);
src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c:379: r = os_same_file_description(sws_iter->fd, ws->fd);
src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c:392: os_log_message("amdgpu: os_same_file_description couldn't "
src/gallium/winsys/etnaviv/drm/etnaviv_drm_winsys.c:66: ret = os_same_file_description(fd1, fd2);
src/gallium/winsys/etnaviv/drm/etnaviv_drm_winsys.c:73: fprintf(stderr, "os_same_file_description couldn't determine if "
src/util/os_file.h:51:os_same_file_description(int fd1, int fd2);
src/util/os_file.c:189:os_same_file_description(int fd1, int fd2)
src/util/os_file.c:212:os_same_file_description(int fd1, int fd2)
src/mesa/drivers/dri/i965/brw_bufmgr.c:1638: int ret = os_same_file_description(drm_fd, bufmgr->fd);Has anyone tested seccomp on i965/iris with Mesa >= 20.1.1? |
|
What about adding |
|
Wouldn't it be simpler to skip detecting AMD GPU and allow |
Since I know that |
|
Maybe there could be an option in firejail.config to automatically append syscalls to the default This way people could easily return to the current behaviour. |
|
Over year and we don't even have a hotfix ... |
kmk3
added
the
graphics
Since not long ago (I unfortunately don't have exact dates or versions for when it happened, but I think it started with Firefox 72.0.2), Firefox hangs at startup under Firejail. This happens on two machines with AMD GPUs, but not on three others with Intel GPUs. All five systems are running up-to-date Gentoo Linux unstable.
Trying on a completely empty profile directory, Firefox gets a little bit through its startup:
And then hangs. The process tree in the sandbox looks like this:
And all threads in the GPU process are hung:
As are the ones in the main Firefox process:
I'm not going to be able to do any deeper debugging for the next couple of days, but if nobody else can reproduce it I'll start looking at older versions of Firefox and removing Firejail profile options this weekend.
The text was updated successfully, but these errors were encountered: