Re: [PATCH] Handling SIGSETXID used by glibc NPTL setuid/setgid

[Peter Maydell <peter.maydell@linaro.org>]

On Thu, 16 Jan 2020 at 11:58, Matus Kysel <mkysel@tachyum.com> wrote:
>
> Used same style to handle another glibc reserved signal SIGSETXID (33),
> that is used by glibc NPTL setuid/setgid functions. This should fix problems
> with application using those functions and failing with error
> "qemu:handle_cpu_signal received signal outside vCPU context".
>
> Signed-off-by: Matus Kysel <mkysel@tachyum.com>
> ---
>  linux-user/signal.c | 13 +++++++++----
>  1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/linux-user/signal.c b/linux-user/signal.c
> index 0128bde4d2..c59221fd0a 100644
> --- a/linux-user/signal.c
> +++ b/linux-user/signal.c
> @@ -66,11 +66,16 @@ static uint8_t host_to_target_signal_table[_NSIG] = {
>      [SIGPWR] = TARGET_SIGPWR,
>      [SIGSYS] = TARGET_SIGSYS,
>      /* next signals stay the same */
> -    /* Nasty hack: Reverse SIGRTMIN and SIGRTMAX to avoid overlap with
> -       host libpthread signals.  This assumes no one actually uses SIGRTMAX :-/
> -       To fix this properly we need to do manual signal delivery multiplexed
> -       over a single host signal.  */
> +    /*
> +     * Nasty hack: Swap SIGRTMIN and SIGRTMIN + 1 with SIGRTMAX and SIGRTMAX - 1
> +     * to avoid overlap with host libpthread (NPTL glibc) signals.
> +     * This assumes no one actually uses SIGRTMAX and SIGRTMAX - 1 :-/
> +     * To fix this properly we need to do manual signal delivery multiplexed
> +     * over a single host signal.
> +     */
>      [__SIGRTMIN] = __SIGRTMAX,
> +    [__SIGRTMIN + 1] = __SIGRTMAX - 1,
> +    [__SIGRTMAX - 1] = __SIGRTMIN + 1,
>      [__SIGRTMAX] = __SIGRTMIN,
>  };
>  static uint8_t target_to_host_signal_table[_NSIG];
> --
> 2.17.1

This is a long-standing known problem, but doing this is likely
to break currently-working guest binaries (notably things written
in Go). See for example the discussion on this thread:
https://lists.gnu.org/archive/html/qemu-devel/2019-08/msg03804.html

thanks
-- PMM