[Mesa-dev] [PATCH] RFC: Workaround for pthread_setaffinity_np() seccomp filtering

[Marc-André Lureau]

Hi Eero!

(ex-colleagues, long time ago!)

On Thu, Feb 28, 2019 at 1:37 PM Eero Tamminen <eero.t.tamminen at intel.com> wrote:
>
> Hi,
>
> On 28.2.2019 11.57, Marc-André Lureau wrote:
> > On Thu, Feb 28, 2019 at 1:17 AM Marek Olšák <maraeo at gmail.com> wrote:
> >> I'd rather have something more robust than an env var, like catching SIGSYS.
>
> SIGSYS is info for the invoking parent, not the (Mesa) process doing the
> syscall.
>
>  From "man 2 seccomp":
>
> The process terminates as though killed by a SIGSYS signal.  Even if a
> signal handler has been registered for SIGSYS,  the  handler will be
> ignored in this case and the process always terminates.  To a parent
> process that is waiting on this process (using waitpid(2) or similar),
> the returned wstatus will indicate that its child was terminated as
> though by a SIGSYS signal.
>
>
> > With current qemu in most distros, it defaults to SIGSYS (we switched
> > away from SCMP_ACT_KILL, which had other problems). With more recent
> > qemu/libseccomp, it will default to SCMP_ACT_KILL_PROCESS. In those
> > KILL action cases, mesa will not be able to catch the failing
> > syscalls.
>
> Qemu / libvirt isn't the only thing using seccomp.
>
> For example Docker enables seccomp filters (along with capability
> restrictions) for the invoked containers unless that is explicitly
> disabled:
>         https://docs.docker.com/engine/security/seccomp/
>
> What actually gets filtered, is trivially changeable on Docker command
> line by giving a JSON file specifying the syscall filtering.
>
> Default policy seems to be white-listing affinity syscall:
>         https://github.com/moby/moby/blob/master/profiles/seccomp/default.json
>
>
> Why distro versions of Qemu filter sched_setaffinity() syscall?
>
>

(https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1815889)

Daniel Berrange (berrange) wrote on 2019-02-27: #19

"IMHO that mesa change is not valid. It is settings its affinity to
run on all threads which is definitely *NOT* something we want to be
allowed. Management applications want to control which CPUs QEMU runs
on, and as such Mesa should honour the CPU placement that the QEMU
process has.

This is a great example of why QEMU wants to use seccomp to block
affinity changes to prevent something silently trying to use more CPUs
than are assigned to this QEMU."



-- 
Marc-André Lureau