qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [engineering.redhat.com #311004] two QXL issues in QEMU


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [engineering.redhat.com #311004] two QXL issues in QEMU
Date: Wed, 03 Sep 2014 16:25:11 +0200

  Hi,

> There is a gap in the sequence above wherein it's not clear which function is
> invoked by - watch_func(...), which in turn calls
> dispatcher_handle_recv_read().

(gdb) thread apply all bt

Thread 2 (Thread 0x7fa703fff700 (LWP 25303)):

This is the spice worker thread, reading messages / instructions from a
socket

#0  0x00007fa7230d006d in __memset_sse2 () from /lib64/libc.so.6
#1  0x00007fa723e04f6f in dev_create_primary_surface.isra.92 ()
from /lib64/libspice-server.so.1
#2  0x00007fa723e050cf in handle_dev_create_primary_surface ()
from /lib64/libspice-server.so.1
#3  0x00007fa723df3463 in dispatcher_handle_recv_read ()
from /lib64/libspice-server.so.1
#4  0x00007fa723e16ff5 in red_worker_main ()
from /lib64/libspice-server.so.1
#5  0x00007fa7259d1df3 in start_thread () from /lib64/libpthread.so.0
#6  0x00007fa72313c3dd in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7fa728364a40 (LWP 25299)):

This is the qemu main thread, processing a display update here.

#0  0x00007fa7259d825d in read () from /lib64/libpthread.so.0
#1  0x00007fa723df31a4 in read_safe () from /lib64/libspice-server.so.1
#2  0x00007fa723df3657 in dispatcher_send_message ()
from /lib64/libspice-server.so.1
#3  0x00007fa723df46f0 in red_dispatcher_create_primary_surface_sync ()
   from /lib64/libspice-server.so.1

Has sent a request to the spice worker thread, awaiting answer.

#4  0x00007fa72859160b in qemu_spice_create_host_primary ()
#5  0x00007fa7285918a8 in qemu_spice_display_switch ()
#6  0x00007fa72858c302 in dpy_gfx_replace_surface ()
#7  0x00007fa7285d3303 in vga_update_display ()

Display update in vga mode.  Display resizes are processed in the update
function (triggered by a timer), not as direct response to register
writes.  That function will look at the vbe registers
(VGACommonState->vbe_regs) which are updated in vbe_ioport_write_data().

> Could the memset(2) length argument controlled by an end application in the
> guest? If so, that could be used to write/set arbitrary memory bytes on the
> host, without crashing the Qemu, as the crash requires it to hit an unmapped
> memory area.

User application can't do this, requires root privileges within the
guest.

Wading through the code I've noticed one special spice thing.  There is
a fixed buffer, size 16MB, presented to spice-server as video memory,
which is the actual backing store for the primary surface in case qxl is
in vga mode (and also when using non-qxl video cards with spice).  It is
allocated in qemu_spice_display_init_common().

So, that is the one we are overflowing when using spice, and it can be
written to indirectly (spice-server uses it as storage for the display
content).  I think the memset() does actually save us here:  Due to the
memory block being quite big it gets allocated with mmap(), with
unmapped pages before and after it.  So if the guest makes the screen
resolution too big the memset will crash qemu before the guest has the
chance to do something evil.

For the non-spice case the analysis from my previous mail is correct.

cheers,
  Gerd





reply via email to

[Prev in Thread] Current Thread [Next in Thread]