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

Daniel P. Berrangé berrange at redhat.com
Wed Mar 13 13:50:10 UTC 2019


On Wed, Mar 13, 2019 at 02:29:28PM +0100, Marc-André Lureau wrote:
> Hi
> 
> On Wed, Mar 13, 2019 at 8:53 AM Mathias Fröhlich
> <Mathias.Froehlich at gmx.net> wrote:
> >
> > Marek, Marc-Andre,
> >
> > On Wednesday, 13 March 2019 00:03:26 CET Marek Olšák wrote:
> > > The env var workaround is fine.
> > >
> > > Thread affinity is used for cache topology related optimizations. I think
> > > it's a mistake to treat it only as a resource allocation tool.
> >
> > For a shorter term solution to the problem.
> > One Idea that comes into my mind:
> >
> > Can we check the currently set thread affinity mask if it still contains the
> > cpu we are aiming for and narrow the mask down to our cpu if we can do
> > that by narrowing. If we would need to assign our thread to a cpu that
> > we are not bound anymore just do nothing.
> >
> 
> getaffinity() is also blocked by current qemu policy.

I think we could consider that a bug. Blocking this syscall while still
allowing read of /proc/self/status achieves little from a security pov
as the affinity is still visible. It is just protecting against a bug
in the impl of getaffinity in the kernel which is unlikely to be worth
caring about & a bug in /proc impl is probably more likely! 

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


More information about the mesa-dev mailing list