Re: [Qemu-discuss] golang on linux-user

[Peter Maydell]

On 1 March 2016 at 09:38, Hunter Laux <address@hidden> wrote:
> I was having trouble running golang on linux-user with an aarch64 target.
>
> It turns out that snappy is written in Go. When I tried the xenial aarch64
> preinstall image in qemu, Snappy was broken.
>
> For some reason, it calls sigaction on all the signals.
>
> I noticed do_sigaction in linux-user/signal.c calls the host sigaction.
> Unfortunately, glibc blocks signal 33 and for "SIGSETXID", which I guess is
> just a user signal that pthread names, but thats as far as I got into it.
>
> See here:
> https://sourceware.org/git/?p=glibc.git;a=blob;f=nptl/sigaction.c
>
> Maybe there's some simple cleaner solutions, but here's what I did.
>
> I made a quick fix by calling the __libc_sigaction instead of the
> __sigaction to bypass the check for SIGSETXID. It seems to work, but I'm not
> sure if that's safe. My "one liner" is definitely a hack.

This has been a bug for ages and we probably should try to
fix it. The problem is that the go runtime expects to be able
to register a handler for every signal, but since QEMU is written
in C and uses libc we can't register a handler for some signals
that libc needs to use. SIGSETXID is signal 33, which glibc uses
as part of its setuid/setgid handling.

We can't call __libc_sigaction because then the libc threading code
would no longer be able to correctly handle setuid/setgid -- I suspect
that if your guest Go program makes a setuid syscall with your patch
applied and multiple threads present this will result in it hanging.

This was traditionally a problem only for guests which try to
register SIGRTMAX (64), because QEMU has a hack where it swaps
the guest's SIGRTMIN and SIGRTMAX. This allows guests using libc
to think they have a working SIGRTMIN -- SIGRTMIN is the other
libc-internal signal (used for thread cancellation) -- without
interfering with the host libc use of it. This did cause go to
complain, but now the go runtime has a workaround for it whereby
it ignores signal 64 failures:
https://go-review.googlesource.com/#/c/16853/3/src/runtime/os1_linux.go

SIGSETXID is I think newer, but similar issues apply. In fact
the only reason we haven't noticed problems already with the glibc
runtime is that it ignores failure return when setting up the
signal handler(!):
https://sourceware.org/git/?p=glibc.git;a=blob;f=nptl/nptl-init.c;h=bdbdfedcef956bca51b9473674381d36eac2c751;hb=HEAD#l411
[I think, but have not tested, that this will mean that attempts
to use setuid etc in a program with multiple threads will hang
under QEMU.]

So we probably ought to:
 (1) redirect SIGSETXID from 33 up to SIGRTMAX-1, for the same
reasons we redirect signal 32 up to SIGRTMAX
 (2a) consider returning success for attempts to register SIGRTMAX
and SIGRTMAX-1 handlers in the guest, rather than failure
 (2b) alternatively, ask the go runtime maintainers to extend
their 'ignore signal 64 registration failure' hack to cover 63

For 2a vs 2b, I checked what Valgrind does -- it also returns
failure-EINVAL for its internal-use signal. (Valgrind only needs
64 for internal use, because it doesn't use glibc.)

So I think we should go with (2b).

> After I did that, I kept getting an EXCP_YIELD. I'm not sure how to handle
> this, but ignoring it seems to work. Again, I'm not sure that's safe.

This is pretty much the right thing. EXCP_YIELD is raised by the
'yield' instruction in order to cause execution of guest code to
return to QEMU's main loop for system emulation so we can schedule
a different guest CPU in an SMP config. In userspace emulation it's
not so useful, but since the yield insn is runnable in usermode it
can happen, and just ignoring it and continuing to run code is the
right thing to do. I'll write up a proper patch that includes a
comment about what's going on.

thanks
-- PMM