qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCHv2 1/2] signal: added a wrapper for sigprocmask f


From: Alex Barcelo
Subject: Re: [Qemu-devel] [PATCHv2 1/2] signal: added a wrapper for sigprocmask function
Date: Thu, 18 Oct 2012 00:06:26 +0200

On Wed, Oct 17, 2012 at 5:01 PM, Peter Maydell <address@hidden> wrote:
> On 17 October 2012 15:18, Alex Barcelo <address@hidden> wrote:
>> Create a wrapper for signal mask changes initiated by the guest;
>> this will give us a place to put code which prevents the guest
>> from changing the handling of signals used by QEMU itself
>> internally.
>>
>> The wrapper is called from all the guest-initiated sigprocmask, but
>> is not called from internal qemu sigprocmask calls.
>>
>> Signed-off-by: Alex Barcelo <address@hidden>
>
> In my comments on v1 of this patch I wrote:
> "I think all the uses of sigprocmask() in linux-user/signal.c also
> need to be do_sigprocmask(), as they are the guest trying to control
> its signal mask (via the mask it specifies for running signal handlers,
> or the mask it passes back when restoring context on return from a
> signal handler)."

I saw sigprocmask being used only inside sigreturn functions (hope I
checked it correctly). I thought (maybe wrongly) that sigreturn should
not be wrapped, just as internal sigprocmask calls are not proxyfied
through do_sigprocmask.

Sigreturn functions should not be called from guest directly, so they
should not be a threat. And if some application uses it... well, then
it is its fault, as POSIX does not guarantee any behavior (am I
right?)

Do you think, despite that, that those calls should be done through
do_sigprocmask? The scenario where this may be relevant is in SIGSEGV
interrupt service routines (because the sigreturn may tamper with
SIGSEGV). In this scenario... I don't know how will anything behave,
so I can't tell if it is worth doing it, or if there is any real case
where qemu-user behavior is improving.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]