On Wed, Mar 27, 2019 at 10:59:03AM +0100, Eduardo Otubo wrote: > From: Daniel P. Berrangé <berra...@redhat.com> > > The Mesa library tries to set process affinity on some of its threads in > order to optimize its performance. Currently this results in QEMU being > immediately terminated when seccomp is enabled. > > Mesa doesn't consider failure of the process affinity settings to be > fatal to its operation, but our seccomp policy gives it no choice in > gracefully handling this denial. > > It is reasonable to consider that malicious code using the resource > control syscalls to be a less serious attack than if they were trying > to spawn processes or change UIDs and other such things. Generally > speaking changing the resource control setting will "merely" affect > quality of service of processes on the host. With this in mind, rather > than kill the process, we can relax the policy for these syscalls to > return the EPERM errno value. This allows callers to detect that QEMU > does not want them to change resource allocations, and apply some > reasonable fallback logic. > > The main downside to this is for code which uses these syscalls but does > not check the return value, blindly assuming they will always > succeeed. Returning an errno could result in sub-optimal behaviour. > Arguably though such code is already broken & needs fixing regardless. > > Signed-off-by: Daniel P. Berrangé <berra...@redhat.com> > Reviewed-by: Marc-André Lureau <marcandre.lur...@redhat.com> > Acked-by: Eduardo Otubo <ot...@redhat.com>
Normally the person sending the pull request should be adding a Signed-off-by line, not an Acked-by line, as Acked-by doesn't have any meaning wrt to the DCO. IIUC, we don't really use Acked-by in QEMU. Only case I think it would be used is where a maintainer is giving their approval for a patch to be sent someone else's tree. eg if a seccomp patch had to merge via a block maintainer tree for some reason, then you could give an Acked-by to indicate you are ok with that going via the different tree. 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 :|
