From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58723) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vq6Et-0003VG-Q8 for qemu-devel@nongnu.org; Mon, 09 Dec 2013 14:11:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vq6Em-0007ZT-7i for qemu-devel@nongnu.org; Mon, 09 Dec 2013 14:11:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41182) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vq6El-0007ZL-VW for qemu-devel@nongnu.org; Mon, 09 Dec 2013 14:11:24 -0500 Message-ID: <52A615D4.2070208@redhat.com> Date: Mon, 09 Dec 2013 17:11:16 -0200 From: Lucas Meneghel Rodrigues MIME-Version: 1.0 References: <1386609652-7876-1-git-send-email-otubo@linux.vnet.ibm.com> In-Reply-To: <1386609652-7876-1-git-send-email-otubo@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] seccomp: "-sandbox on" won't kill Qemu when option not built in List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Otubo , qemu-devel@nongnu.org Cc: pmoore@redhat.com, anthony@codemonkey.ws On 12/09/2013 03:20 PM, Eduardo Otubo wrote: > This option was requested by virt-test team so they can run tests with > Qemu and "-sandbox on" set without breaking whole test if host doesn't > have support for seccomp in kernel. It covers two possibilities: > > 1) Host kernel support does not support seccomp, but user installed Qemu > package with sandbox support: Libseccomp will fail -> qemu will fail > nicely and won't stop execution. > > 2) Host kernel has support but Qemu package wasn't built with sandbox > feature. Qemu will fail nicely and won't stop execution. It seems there was a misunderstanding of what we wanted here. The problem we had there happened on a -sandbox bug on Fedora 19 that got one of our team members confused, since qemu did not give any sort of useful output that would allow him to identify the bug was related to -sandbox (qemu was accessing a syscall outside of the whitelist on Fedora 19). He took a while until he figured out -sandbox was the problem, due to the lack of any clues of what was going on. I was not affected due to the fact I was already on Fedora 20 by that time. I assume Eduardo thought that we somehow wanted qemu to just carry on when seccomp requirements could not be fulfilled, but that was not our point. What I thought I'd commented with hum was that some more useful message could be printed to stderr, and perhaps make the qemu process to exit with rc != 0 on such errors, instead of just going dead silently. I still couldn't quite grasp why that could not be done, but if it can't, so be it. No big deal. Lucas