From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi Date: Sat, 02 Mar 2019 11:36:02 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1877782681==" Return-path: Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 0D56F6E394 for ; Sat, 2 Mar 2019 11:36:02 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1877782681== Content-Type: multipart/alternative; boundary="15515265610.d8ED.4046" Content-Transfer-Encoding: 7bit --15515265610.d8ED.4046 Date: Sat, 2 Mar 2019 11:36:01 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated https://bugs.freedesktop.org/show_bug.cgi?id=3D109695 --- Comment #9 from Ahzo@tutanota.com --- (In reply to Daniel P. Berrange from comment #3) > (In reply to Ahzo from comment #2) > > To check for the availability of the syscall, one can try it in a child > > process and see if the child is terminated by a signal, e.g. like this: >=20 > Afraid not, QEMU's seccomp filter blocks use of fork() too :-) Maybe it should, at least when using the spawn=3Ddeny option, but currently= it doesn't. That option only blocks the fork, vfork and execve syscalls, but glibc's fork() function uses the clone syscall, and thus continues to work. However, that behavior might be different when using other C library implementations, so it wouldn't be correct to rely on this. One could use clone() instead of fork(), but future versions of qemu might block the clone syscall, as well. Unfortunately, I'm not aware of a proper solution for this bug short of add= ing a new API to the kernel. --=20 You are receiving this mail because: You are the assignee for the bug.= --15515265610.d8ED.4046 Date: Sat, 2 Mar 2019 11:36:01 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated

Commen= t # 9 on bug 10969= 5 from Ahzo@tutanota.co= m 
(In reply to Daniel P. Berrange from comment #3)
> (In reply to Ahzo from comment #2)
> > To check for the availability of the syscall, one can try it in a=
 child
> > process and see if the child is terminated by a signal, e.g. like=
 this:
>=20
> Afraid not, QEMU's seccomp filter blocks use of fork() too :-)

Maybe it should, at least when using the spawn=3Ddeny option, but currently=
 it
doesn't. That option only blocks the fork, vfork and execve syscalls, but
glibc's fork() function uses the clone syscall, and thus continues to work.
However, that behavior might be different when using other C library
implementations, so it wouldn't be correct to rely on this.
One could use clone() instead of fork(), but future versions of qemu might
block the clone syscall, as well.

Unfortunately, I'm not aware of a proper solution for this bug short of add=
ing
a new API to the kernel.

You are receiving this mail because:
  • You are the assignee for the bug.
= --15515265610.d8ED.4046-- --===============1877782681== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVs --===============1877782681==--