From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41895) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWvHN-0003MV-2T for qemu-devel@nongnu.org; Mon, 29 Apr 2013 17:06:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UWvHD-0003tv-Pd for qemu-devel@nongnu.org; Mon, 29 Apr 2013 17:06:32 -0400 Received: from mail-ee0-f41.google.com ([74.125.83.41]:52263) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWvHD-0003sf-He for qemu-devel@nongnu.org; Mon, 29 Apr 2013 17:06:23 -0400 Received: by mail-ee0-f41.google.com with SMTP id c50so2467772eek.14 for ; Mon, 29 Apr 2013 14:06:22 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <517EE0C0.2090504@redhat.com> Date: Mon, 29 Apr 2013 23:06:08 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <517AC9E5.3050204@linux.vnet.ibm.com> <7515044.dYPbKXmJQB@sifl> <517AFCFA.1020407@redhat.com> <517ED0B8.9070607@linux.vnet.ibm.com> In-Reply-To: <517ED0B8.9070607@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Continuous work on sandboxing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Otubo Cc: Paul Moore , qemu-devel@nongnu.org, Eric Paris Il 29/04/2013 21:57, Eduardo Otubo ha scritto: > > > On 04/26/2013 07:17 PM, Paolo Bonzini wrote: >> Il 26/04/2013 23:07, Paul Moore ha scritto: >>>>> 3. Debugging and/or learning mode - third party libraries still >>>>> have the >>>>> problem of interfering in the Qemu's signal mask. According to some >>>>> previous discussions, perhaps patch all external libraries that >>>>> mass up >>>>> with this mask (spice, for example) is a way to solve it. But not sure >>>>> if it worth the time spent. Would like to hear you guys. >>> I think patching all the libraries is a losing battle, I think we >>> need to >>> pursue alternate debugging techniques. >> >> It is really only about patching libraries that create threads _and_ >> block all signals in the newly-created thread (to not interfere with the >> program's own handling of the signals). In this case, the per-thread >> signals (SIGFPE/SIGSEGV/SIGBUS/SIGSYS/SIGILL) should be left unblocked, >> but SIGSYS is often forgotten. > > But otherwise you have a fast way to test third party linked libraries, > I would have to test it each one manually. How many libraries are linked > to Qemu today? I'd wager that most of them are not creating threads. We could specify our own GThread implementation too (see https://developer.gnome.org/glib/2.30/glib-Threads.html#GThreadFunctions) that sets signals correctly, which would cover those libraries that create threads, but do so via glib. Another fix would be to set the signal mask around each call to poll. That's quite expensive however. There are pselect/ppoll, but Linux doesn't implement them so they're also expensive. >> I don't think there are many libraries like this, but fixing SPICE at >> least should definitely be welcome. >> >> In fact QEMU's own util/qemu-thread-posix.c does not unblock those >> signals. Eduardo, can you submit a patch for that? > > I sure can. Thanks, Paolo