[Qemu-devel] [Bug 1728116] [NEW] Empty /proc/self/auxv (linux-user)

[Thomas Moschny]

Public bug reported:

The userspace Linux API virtualization used to fake access to
/proc/self/auxv, to provide meaningful data for the guest process.

For newer qemu versions, this fails: The openat() is intercepted, but
there's no content: /proc/self/auxv has length zero (i.e. reading from
it returns 0 bytes).

Good:

$ x86_64-linux-user/qemu-x86_64 /usr/bin/cat /proc/self/auxv | wc -c
256 /proc/self/auxv

Bad:

$ x86_64-linux-user/qemu-x86_64 /usr/bin/cat /proc/self/auxv | wc -c
0 /proc/self/auxv

This worked in 2.7.1, and fails in 2.10.1.

This causes e.g. any procps-ng-based tool to segfault while reading from
/proc/self/auxv in an endless loop (probably worth another bug
report...)

Doing a "git bisect" shows that this commit:
https://github.com/qemu/qemu/commit/7c4ee5bcc introduced the problem.

It might be a simple logic (subtraction in the wrong direction?) or
sign-ness error: Adding some logging (to v2.10.1)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 9b6364a..49285f9 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -7469,6 +7469,9 @@ static int open_self_auxv(void *cpu_env, int fd)
     abi_ulong len = ts->info->auxv_len;
     char *ptr;
 
+    gemu_log(TARGET_ABI_FMT_lu"\n", len);
+    gemu_log(TARGET_ABI_FMT_ld"\n", len);
+
     /*
      * Auxiliary vector is stored in target process stack.
      * read in whole auxv vector and copy it to file

shows this output:

$  x86_64-linux-user/qemu-x86_64 /usr/bin/cat /proc/self/auxv | wc -c
18446744073709551264
-352
0

And 352 could be the expected length.

** Affects: qemu
     Importance: Undecided
         Status: New

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

Title:
  Empty /proc/self/auxv (linux-user)

Status in QEMU:
  New

Bug description:
  The userspace Linux API virtualization used to fake access to
  /proc/self/auxv, to provide meaningful data for the guest process.

  For newer qemu versions, this fails: The openat() is intercepted, but
  there's no content: /proc/self/auxv has length zero (i.e. reading from
  it returns 0 bytes).

  Good:

  $ x86_64-linux-user/qemu-x86_64 /usr/bin/cat /proc/self/auxv | wc -c
  256 /proc/self/auxv

  Bad:

  $ x86_64-linux-user/qemu-x86_64 /usr/bin/cat /proc/self/auxv | wc -c
  0 /proc/self/auxv

  This worked in 2.7.1, and fails in 2.10.1.

  This causes e.g. any procps-ng-based tool to segfault while reading
  from /proc/self/auxv in an endless loop (probably worth another bug
  report...)

  Doing a "git bisect" shows that this commit:
  https://github.com/qemu/qemu/commit/7c4ee5bcc introduced the problem.

  It might be a simple logic (subtraction in the wrong direction?) or
  sign-ness error: Adding some logging (to v2.10.1)

  diff --git a/linux-user/syscall.c b/linux-user/syscall.c
  index 9b6364a..49285f9 100644
  --- a/linux-user/syscall.c
  +++ b/linux-user/syscall.c
  @@ -7469,6 +7469,9 @@ static int open_self_auxv(void *cpu_env, int fd)
       abi_ulong len = ts->info->auxv_len;
       char *ptr;
   
  +    gemu_log(TARGET_ABI_FMT_lu"\n", len);
  +    gemu_log(TARGET_ABI_FMT_ld"\n", len);
  +
       /*
        * Auxiliary vector is stored in target process stack.
        * read in whole auxv vector and copy it to file

  shows this output:

  $  x86_64-linux-user/qemu-x86_64 /usr/bin/cat /proc/self/auxv | wc -c
  18446744073709551264
  -352
  0

  And 352 could be the expected length.

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