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
60
61
62
63
64
65
66
67
68
69
70
71
72
|
x86: 0.599
virtual: 0.563
kernel: 0.432
device: 0.342
vnc: 0.331
performance: 0.308
mistranslation: 0.302
socket: 0.288
network: 0.276
ppc: 0.271
architecture: 0.265
files: 0.212
graphic: 0.199
hypervisor: 0.194
peripherals: 0.193
PID: 0.191
semantic: 0.175
boot: 0.157
debug: 0.155
register: 0.153
TCG: 0.141
arm: 0.134
risc-v: 0.132
permissions: 0.117
VMM: 0.107
i386: 0.102
user-level: 0.087
KVM: 0.060
assembly: 0.037
SPICE session's connection_id's are not unique
From: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920897
=====
When creating a virtual machine with qemu (e.g. via libvirt) including a SPICE server, the client_id of the SPICE session is not unique. For example, starting multiple virtual machines on the same libvirtd, the client_id is the same for all virtual machine's SPICE sessions.
A description of the client_id can be found in
https://www.spice-space.org/static/docs/spice_protocol.pdf under section 2.11. c) :
"UINT32 connection_id - In case of a new session (i.e., channel type is RED_CHANNEL_MAIN) this field is set to zero, and in response the server will allocate session id and will send it via the RedLinkReply message. In case of all other channel types, this field will be equal to the allocated session id"
The relevant code for generating client ids in libspice-server1 can be found here: https://gitlab.freedesktop.org/spice/spice/blob/v0.12.8/server/reds.c#L1614
This uses rand() to generate the random id, but qemu (at least in the case of qemu-system-x86) fails to initialize the RNG seed (with e.g. srand()).
The result is, that every SPICE session started (by e.g. libvirtd) has the same client_id. Usually, this is not a problem, but running something like a SPICE proxy, relying on the client_id to correctly route connections, this creates problems.
Adding something like 'srand(time(NULL));' to qemu (in vl.c) solves this issue. Related (as seen in some VNC patches, e.g. 'CVE-2017-15124/04-ui-avoid-pointless-VNC-updates-if-framebuffer-isn-t-.patch/ui/vnc.c' ): srand(time(NULL)+getpid()+getpid()*987654+rand());
Tested on Debian 9.7 with kernel 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux.
=====
This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:
https://gitlab.com/qemu-project/qemu/-/issues/163
|