Empty /proc/self/auxv (linux-user)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Fix Released
|
Undecided
|
Unassigned |
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-
256 /proc/self/auxv
Bad:
$ x86_64-
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:/
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-
index 9b6364a..49285f9 100644
--- a/linux-
+++ b/linux-
@@ -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(
+ gemu_log(
+
/*
* Auxiliary vector is stored in target process stack.
* read in whole auxv vector and copy it to file
shows this output:
$ x86_64-
184467440737095
-352
0
And 352 could be the expected length.
Oops, yes, commit 7c4ee5bcc82e643 broke this -- it switched the order in which we fill in the AUXV info, but forgot to adjust the calculation of the length, which as you've guessed we now get backwards.