Re: [Qemu-devel] [RFC] Continuous work on sandboxing

[Paolo Bonzini]

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