[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Handling SIGSETXID used by glibc NPTL setuid/setgid
From: |
Laurent Vivier |
Subject: |
Re: [PATCH] Handling SIGSETXID used by glibc NPTL setuid/setgid |
Date: |
Wed, 29 Jan 2020 17:12:40 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 |
Le 28/01/2020 à 10:26, Peter Maydell a écrit :
> On Thu, 16 Jan 2020 at 11:58, Matus Kysel <address@hidden> 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 <address@hidden>
>> ---
>> 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
Peter,
I try to fix this problem and I'd like to find a reproducer for the Go
problem.
I tried to write an "hello world" program and run it in an arm64/bionic
chroot but there is no problem (with and without this patch).
Any hints?
Thanks,
Laurent