1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
|
Empty /proc/self/auxv (linux-user)
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.
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.
I've just sent this patch which fixes this bug:
https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg01199.html
(it turns out it wasn't quite as simple as getting the sign wrong, we were subtracting two things that were totally wrong).
Fix has been released with QEMU 2.11:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=f516511ea84d8bb3395d6e
|