Re: [Bug 1907969] Re: linux-user/i386: Segfault when mixing threads and signals

[Laurent Vivier]

Le 16/12/2020 à 09:59, The Lemon Man a écrit :
> I finally understand where the problem is.
> 
> Qemu's user-mode emulation maps guest threads to native ones by spawning a 
> new native one
> and running a forked copy of the CPUX86State in parallel with the main thread.
> 
> This works fine for pretty much every architecture but i386 where the GDT/LDT 
> comes into
> play: the two descriptor tables are shared among all the threads, mimicking 
> the real hw
> behaviour, but since no host task-switching is being performed the TLS entry 
> in the GDT
> become stale.
> 
> Raising a signal makes Qemu reload the GS segment from the GDT, that's why 
> removing that
> line makes the problem disappear.
> 
> The problem is also confined to musl libc because of an interesting 
> implementation choice.
> Once a thread dies Glibc adds the now unused stack to a queue in order to 
> reuse it later,
> while musl frees it right away when it's not needed anymore and, as a 
> consequence, makes
> Qemu segfault.
> 
> As luck has it, after spending too much time debugging this, I found somebody 
> else already
> stumbled across this problem and wrote a patch. 
> 
> https://patchew.org/QEMU/74c9f1d9-4497-31c2-34a7-e21bef7932bd@scieneer.com/mbox
> 
> Too bad the patch flew under the radar...
> 

Could you add a Reviewed-by and/or a tested by to the patch on the ML?

Thanks,
Laurent

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1907969

Title:
  linux-user/i386: Segfault when mixing threads and signals

Status in QEMU:
  New

Bug description:
  Given the following C program, qemu-i386 will surely and certainly segfault 
when executing it.
  The problem is only noticeable if the program is statically linked to musl's 
libc and, as written
  in the title, it only manifests when targeting i386.

  Removing the pthread calls or the second raise() makes it not
  segfault.

  The crash is in some part of the TCG-generated code, right when it tries to 
perform a
  %gs-relative access.

  If you want a quick way of cross-compiling this binary:

  * Download a copy of the Zig compiler from https://ziglang.org/download/
  * Compile it with
    `zig cc -target i386-linux-musl <C-FILE> -o <OUT>`

  ```
  #include <pthread.h>
  #include <signal.h>
  #include <stdio.h>
  #include <string.h>
  #include <sys/types.h>
  #include <unistd.h>
  #include <asm/prctl.h>
  #include <sys/syscall.h>

  void sig_func(int sig)
  {
      write(1, "hi!\n", strlen("hi!\n"));
  }

  void func(void *p) { }

  typedef void *(*F)(void *);

  int main()
  {
      pthread_t tid;

      struct sigaction action;
      action.sa_flags = 0;
      action.sa_handler = sig_func;

      if (sigaction(SIGUSR1, &action, NULL) == -1) {
          return 1;
      }

      // This works.
      raise(SIGUSR1);

      pthread_create(&tid, NULL, (F)func, NULL);
      pthread_join(tid, NULL);

      // This makes qemu segfault.
      raise(SIGUSR1);
  }
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1907969/+subscriptions