summaryrefslogtreecommitdiffstats
path: root/ui/vnc.c
Commit message (Collapse)AuthorAgeFilesLines
* authz: delete existing ACL implementationDaniel P. Berrange2019-02-261-12/+25
| | | | | | | | | | | | | | | | The 'qemu_acl' type was a previous non-QOM based attempt to provide an authorization facility in QEMU. Because it is non-QOM based it cannot be created via the command line and requires special monitor commands to manipulate it. The new QAuthZ subclasses provide a superset of the functionality in qemu_acl, so the latter can now be deleted. The HMP 'acl_*' monitor commands are converted to use the new QAuthZSimple data type instead in order to provide temporary backwards compatibility. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* qapi: Generate QAPIEvent stuff into separate filesMarkus Armbruster2019-02-181-1/+2
| | | | | | | | | | | | Having to include qapi-events.h just for QAPIEvent is suboptimal, but quite tolerable now. It'll become problematic when we have events conditional on the target, because then qapi-events.h won't be usable from target-independent code anymore. Avoid that by generating it into separate files. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20190214152251.2073-6-armbru@redhat.com>
* keymap: fix keyup mappingsGerd Hoffmann2019-02-051-1/+1
| | | | | | | | | | | | | | | | | | It is possible that the modifier state on keyup is different from the modifier state on keydown. In that case the keycode lookup can end up with different keys in case multiple keysym -> keycode mappings exist, because it picks the mapping depending on modifier state. To fix that change the lookup logic for keyup events. Instead of looking at the modifier state check the key state and prefer a keycodes where the key is in "down" state right now. Fixes: abb4f2c965 keymap: consider modifier state when picking a mapping Buglink: https://bugs.launchpad.net/bugs/1738283 Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1658676 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-id: 20190122092814.14919-9-kraxel@redhat.com
* keymap: pass full keyboard state to keysym2scancodeGerd Hoffmann2019-02-051-4/+1Star
| | | | | | | | | | Pass the keyboard state tracker handle down to keysym2scancode(), so the code can fully inspect the keyboard state as needed. No functional change. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-id: 20190122092814.14919-8-kraxel@redhat.com
* kbd-state: use state tracker for vncGerd Hoffmann2019-02-051-87/+33Star
| | | | | | | | | Use the new keyboard state tracked for vnc. Allows to drop the vnc-specific modifier state tracking code. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-id: 20190122092814.14919-7-kraxel@redhat.com
* vnc: detect and optimize pageflipsGerd Hoffmann2019-01-211-3/+22
| | | | | | | | | | | | | | | | | When size and format of the display surface stays the same we can just tag the guest display as dirty and be done with it. There is no need need to resize the vnc server display or to touch the vnc client dirty bits. On the next refresh cycle vnc_refresh_server_surface() will check for actual display content changes and update the client dirty bits as needed. The desktop resize and framebuffer format notifications to the vnc client will be skipped too. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-id: 20190116101049.8929-1-kraxel@redhat.com
* avoid TABs in files that only contain a fewPaolo Bonzini2019-01-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most files that have TABs only contain a handful of them. Change them to spaces so that we don't confuse people. disas, standard-headers, linux-headers and libdecnumber are imported from other projects and probably should be exempted from the check. Outside those, after this patch the following files still contain both 8-space and TAB sequences at the beginning of the line. Many of them have a majority of TABs, or were initially committed with all tabs. bsd-user/i386/target_syscall.h bsd-user/x86_64/target_syscall.h crypto/aes.c hw/audio/fmopl.c hw/audio/fmopl.h hw/block/tc58128.c hw/display/cirrus_vga.c hw/display/xenfb.c hw/dma/etraxfs_dma.c hw/intc/sh_intc.c hw/misc/mst_fpga.c hw/net/pcnet.c hw/sh4/sh7750.c hw/timer/m48t59.c hw/timer/sh_timer.c include/crypto/aes.h include/disas/bfd.h include/hw/sh4/sh.h libdecnumber/decNumber.c linux-headers/asm-generic/unistd.h linux-headers/linux/kvm.h linux-user/alpha/target_syscall.h linux-user/arm/nwfpe/double_cpdo.c linux-user/arm/nwfpe/fpa11_cpdt.c linux-user/arm/nwfpe/fpa11_cprt.c linux-user/arm/nwfpe/fpa11.h linux-user/flat.h linux-user/flatload.c linux-user/i386/target_syscall.h linux-user/ppc/target_syscall.h linux-user/sparc/target_syscall.h linux-user/syscall.c linux-user/syscall_defs.h linux-user/x86_64/target_syscall.h slirp/cksum.c slirp/if.c slirp/ip.h slirp/ip_icmp.c slirp/ip_icmp.h slirp/ip_input.c slirp/ip_output.c slirp/mbuf.c slirp/misc.c slirp/sbuf.c slirp/socket.c slirp/socket.h slirp/tcp_input.c slirp/tcpip.h slirp/tcp_output.c slirp/tcp_subr.c slirp/tcp_timer.c slirp/tftp.c slirp/udp.c slirp/udp.h target/cris/cpu.h target/cris/mmu.c target/cris/op_helper.c target/sh4/helper.c target/sh4/op_helper.c target/sh4/translate.c tcg/sparc/tcg-target.inc.c tests/tcg/cris/check_addo.c tests/tcg/cris/check_moveq.c tests/tcg/cris/check_swap.c tests/tcg/multiarch/test-mmap.c ui/vnc-enc-hextile-template.h ui/vnc-enc-zywrle.h util/envlist.c util/readline.c The following have only TABs: bsd-user/i386/target_signal.h bsd-user/sparc64/target_signal.h bsd-user/sparc64/target_syscall.h bsd-user/sparc/target_signal.h bsd-user/sparc/target_syscall.h bsd-user/x86_64/target_signal.h crypto/desrfb.c hw/audio/intel-hda-defs.h hw/core/uboot_image.h hw/sh4/sh7750_regnames.c hw/sh4/sh7750_regs.h include/hw/cris/etraxfs_dma.h linux-user/alpha/termbits.h linux-user/arm/nwfpe/fpopcode.h linux-user/arm/nwfpe/fpsr.h linux-user/arm/syscall_nr.h linux-user/arm/target_signal.h linux-user/cris/target_signal.h linux-user/i386/target_signal.h linux-user/linux_loop.h linux-user/m68k/target_signal.h linux-user/microblaze/target_signal.h linux-user/mips64/target_signal.h linux-user/mips/target_signal.h linux-user/mips/target_syscall.h linux-user/mips/termbits.h linux-user/ppc/target_signal.h linux-user/sh4/target_signal.h linux-user/sh4/termbits.h linux-user/sparc64/target_syscall.h linux-user/sparc/target_signal.h linux-user/x86_64/target_signal.h linux-user/x86_64/termbits.h pc-bios/optionrom/optionrom.h slirp/mbuf.h slirp/misc.h slirp/sbuf.h slirp/tcp.h slirp/tcp_timer.h slirp/tcp_var.h target/i386/svm.h target/sparc/asi.h target/xtensa/core-dc232b/xtensa-modules.inc.c target/xtensa/core-dc233c/xtensa-modules.inc.c target/xtensa/core-de212/core-isa.h target/xtensa/core-de212/xtensa-modules.inc.c target/xtensa/core-fsf/xtensa-modules.inc.c target/xtensa/core-sample_controller/core-isa.h target/xtensa/core-sample_controller/xtensa-modules.inc.c target/xtensa/core-test_kc705_be/core-isa.h target/xtensa/core-test_kc705_be/xtensa-modules.inc.c tests/tcg/cris/check_abs.c tests/tcg/cris/check_addc.c tests/tcg/cris/check_addcm.c tests/tcg/cris/check_addoq.c tests/tcg/cris/check_bound.c tests/tcg/cris/check_ftag.c tests/tcg/cris/check_int64.c tests/tcg/cris/check_lz.c tests/tcg/cris/check_openpf5.c tests/tcg/cris/check_sigalrm.c tests/tcg/cris/crisutils.h tests/tcg/cris/sys.c tests/tcg/i386/test-i386-ssse3.c ui/vgafont.h Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20181213223737.11793-3-pbonzini@redhat.com> Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com> Acked-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Eric Blake <eblake@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Stefan Markovic <smarkovic@wavecomp.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* vnc: Clean up error reporting in vnc_init_func()Markus Armbruster2018-10-191-4/+4
| | | | | | | | | | | | | | | | Calling error_report() in a function that takes an Error ** argument is suspicious. vnc_init_func() does that, and then fails without setting an error. Its caller main(), via qemu_opts_foreach(), is fine with it, but clean it up anyway. While there, drop a "Failed to start VNC server: " error message prefix that doesn't really add value. Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20181017082702.5581-28-armbru@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
* ui: Convert vnc_display_init(), init_keyboard_layout() to ErrorFei Li2018-10-191-5/+10
| | | | | | | | | Signed-off-by: Fei Li <fli@suse.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20181017082702.5581-27-armbru@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
* vnc: call sasl_server_init() only when requiredMarc-André Lureau2018-10-011-7/+8
| | | | | | | | | | | | | | | | | | | | | | | VNC server is calling sasl_server_init() during startup of QEMU, even if SASL auth has not been enabled. This may create undesirable warnings like "Could not find keytab file: /etc/qemu/krb5.tab" when the user didn't configure SASL on host and started VNC server. Instead, only initialize SASL when needed. Note that HMP/QMP "change vnc" calls vnc_display_open() again, which will initialize SASL if needed. Fix assignment in if condition, while touching this code. Related to: https://bugzilla.redhat.com/show_bug.cgi?id=1609327 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-id: 20180907063634.359-1-marcandre.lureau@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* qapi: Drop qapi_event_send_FOO()'s Error ** argumentPeter Xu2018-08-281-4/+3Star
| | | | | | | | | | | | | | | | | | | The generated qapi_event_send_FOO() take an Error ** argument. They can't actually fail, because all they do with the argument is passing it to functions that can't fail: the QObject output visitor, and the @qmp_emit callback, which is either monitor_qapi_event_queue() or event_test_emit(). Drop the argument, and pass &error_abort to the QObject output visitor and @qmp_emit instead. Suggested-by: Eric Blake <eblake@redhat.com> Suggested-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20180815133747.25032-4-peterx@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Commit message rewritten, update to qapi-code-gen.txt corrected] Signed-off-by: Markus Armbruster <armbru@redhat.com>
* ui/vnc: Remove useless parenthesis around DIV_ROUND_UP macroPhilippe Mathieu-Daudé2018-08-241-1/+2
| | | | | | | | | | | | Patch created mechanically by rerunning: $ spatch --sp-file scripts/coccinelle/round.cocci \ --macro-file scripts/cocci-macro-file.h \ --dir . --in-place Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20180704153919.12432-7-f4bug@amsat.org> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* vnc: remove support for deprecated tls, x509, x509verify optionsDaniel P. Berrangé2018-08-241-91/+0Star
| | | | | | | | | | | | The 'tls-creds' option accepts the name of a TLS credentials object. This replaced the usage of 'tls', 'x509' and 'x509verify' options in 2.5.0. These deprecated options were grandfathered in when the deprecation policy was introduded in 2.10.0, so can now finally be removed. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-id: 20180725092751.21767-3-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* vnc: add magic cookie to VncStateGerd Hoffmann2018-05-151-1/+9
| | | | | | | | Set magic cookie on initialization. Clear on cleanup. Sprinkle a bunch of assert()s checking the cookie, to verify the pointer is valid. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20180507102254.12107-1-kraxel@redhat.com
* vnc: fix use-after-freeGerd Hoffmann2018-04-271-2/+3
| | | | | | | | | | | | | | | When vnc_client_read() return value is -1 vs is not valid any more. Fixes: d49b87f0d1e0520443a990fc610d0f02bc63c556 Reported-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Marc-André Lureau <marcandre.lureau@redhat.com> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180420084820.3873-1-kraxel@redhat.com
* vnc: deal with surface NULL pointersGerd Hoffmann2018-03-121-0/+10
| | | | | | | | | | | | | | | | | | | | | Secondary displays in multihead setups are allowed to have a NULL DisplaySurface. Typically user interfaces handle this by hiding the window which shows the display in question. This isn't an option for vnc though because it simply hasn't a concept of windows or outputs. So handle the situation by showing a placeholder DisplaySurface instead. Also check in console_select whenever a surface is preset in the first place before requesting an update. This fixes a segfault which can be triggered by switching to an unused display (via vtrl-alt-<nr>) in a multihead setup, for example using -device virtio-vga,max_outputs=2. Cc: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Christian Borntraeger <borntraeger@de.ibm.com> Message-id: 20180308161803.6152-1-kraxel@redhat.com
* qapi: Move qapi-schema.json to qapi/, rename generated filesMarkus Armbruster2018-03-021-1/+1
| | | | | | | | | | | | | | | | | | | Move qapi-schema.json to qapi/, so it's next to its modules, and all files get generated to qapi/, not just the ones generated for modules. Consistently name the generated files qapi-MODULE.EXT: qmp-commands.[ch] become qapi-commands.[ch], qapi-event.[ch] become qapi-events.[ch], and qmp-introspect.[ch] become qapi-introspect.[ch]. This gets rid of the temporary hacks in scripts/qapi/commands.py, scripts/qapi/events.py, and scripts/qapi/common.py. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180211093607.27351-28-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com> [eblake: Fix trailing dot in tpm.c, undo temporary hack for OSX toolchain] Signed-off-by: Eric Blake <eblake@redhat.com>
* Include less of the generated modular QAPI headersMarkus Armbruster2018-03-021-1/+1
| | | | | | | | | | | | | | | | | | | | | In my "build everything" tree, a change to the types in qapi-schema.json triggers a recompile of about 4800 out of 5100 objects. The previous commit split up qmp-commands.h, qmp-event.h, qmp-visit.h, qapi-types.h. Each of these headers still includes all its shards. Reduce compile time by including just the shards we actually need. To illustrate the benefits: adding a type to qapi/migration.json now recompiles some 2300 instead of 4800 objects. The next commit will improve it further. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180211093607.27351-24-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> [eblake: rebase to master] Signed-off-by: Eric Blake <eblake@redhat.com>
* keymap: consider modifier state when picking a mappingGerd Hoffmann2018-02-221-2/+7
| | | | | | | | | | Pass the modifier state to the keymap lookup function. In case multiple keysym -> keycode mappings exist look at the modifier state and prefer the mapping where the modifier state matches. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-id: 20180222070513.8740-6-kraxel@redhat.com
* ui: check VNC audio frequency limit at time of reading from clientDaniel P. Berrangé2018-02-161-9/+13
| | | | | | | | | | | | | | The 'vs->as.freq' value is a signed integer, which is read from an unsigned 32-bit int field on the wire. There is thus a risk of overflow on 32-bit platforms. Move the frequency limit checking to be done at time of read before casting to a signed integer. Reported-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180205114938.15784-4-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* ui: avoid risk of 32-bit int overflow in VNC buffer checkDaniel P. Berrangé2018-02-161-2/+2
| | | | | | | | | | | | | | | | For very large framebuffers, it is theoretically possible for the result of 'vs->throttle_output_offset * VNC_THROTTLE_OUTPUT_LIMIT_SCALE' to exceed the size of a 32-bit int. For this to happen in practice, the video RAM would have to be set to a large enough value, which is not likely today. None the less we can be paranoid against future growth by using division instead of multiplication when checking the limits. Reported-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180205114938.15784-2-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* vnc: fix segfault in closed connection handlingKlim Kireev2018-02-161-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On one of our client's node, due to trying to read from closed ioc, a segmentation fault occured. Corresponding backtrace: 0 object_get_class (obj=obj@entry=0x0) 1 qio_channel_readv_full (ioc=0x0, iov=0x7ffe55277180 ... 2 qio_channel_read (ioc=<optimized out> ... 3 vnc_client_read_buf (vs=vs@entry=0x55625f3c6000, ... 4 vnc_client_read_plain (vs=0x55625f3c6000) 5 vnc_client_read (vs=0x55625f3c6000) 6 vnc_client_io (ioc=<optimized out>, condition=G_IO_IN, ... 7 g_main_dispatch (context=0x556251568a50) 8 g_main_context_dispatch (context=context@entry=0x556251568a50) 9 glib_pollfds_poll () 10 os_host_main_loop_wait (timeout=<optimized out>) 11 main_loop_wait (nonblocking=nonblocking@entry=0) 12 main_loop () at vl.c:1909 13 main (argc=<optimized out>, argv=<optimized out>, ... Having analyzed the coredump, I understood that the reason is that ioc_tag is reset on vnc_disconnect_start and ioc is cleaned in vnc_disconnect_finish. Between these two events due to some reasons the ioc_tag was set again and after vnc_disconnect_finish the handler is running with freed ioc, which led to the segmentation fault. The patch checks vs->disconnecting in places where we call qio_channel_add_watch and resets handler if disconnecting == TRUE to prevent such an occurrence. Signed-off-by: Klim Kireev <klim.kireev@virtuozzo.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-id: 20180207094844.21402-1-klim.kireev@virtuozzo.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* vnc: remove bogus object_unref on client socketDaniel P. Berrangé2018-02-161-1/+0Star
| | | | | | | | | | | | vnc_listen_io() does not own the reference on the 'cioc' parameter is it passed, so should not be unref'ing it. Fixes: 13e1d0e71e78a925848258391a6e616b6b5ae219 Reported-by: Bandan Das <bsd@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180215102602.10864-1-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* Move include qemu/option.h from qemu-common.h to actual usersMarkus Armbruster2018-02-091-0/+1
| | | | | | | | | | | | | | | | | | qemu-common.h includes qemu/option.h, but most places that include the former don't actually need the latter. Drop the include, and add it to the places that actually need it. While there, drop superfluous includes of both headers, and separate #include from file comment with a blank line. This cleanup makes the number of objects depending on qemu/option.h drop from 4545 (out of 4743) to 284 in my "build everything" tree. Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180201111846.21846-20-armbru@redhat.com> [Semantic conflict with commit bdd6a90a9e in block/nvme.c resolved]
* Eliminate qapi/qmp/types.hMarkus Armbruster2018-02-091-1/+0Star
| | | | | | | | | | | | | | qapi/qmp/types.h is a convenience header to include a number of qapi/qmp/ headers. Since we rarely need all of the headers qapi/qmp/types.h includes, we bypass it most of the time. Most of the places that use it don't need all the headers, either. Include the necessary headers directly, and drop qapi/qmp/types.h. Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180201111846.21846-9-armbru@redhat.com>
* Drop superfluous includes of qapi/qmp/qerror.hMarkus Armbruster2018-02-091-1/+0Star
| | | | | | | Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180201111846.21846-6-armbru@redhat.com>
* Include qapi/error.h exactly where neededMarkus Armbruster2018-02-091-0/+1
| | | | | | | | | | | | | | This cleanup makes the number of objects depending on qapi/error.h drop from 1910 (out of 4743) to 1612 in my "build everything" tree. While there, separate #include from file comment with a blank line, and drop a useless comment on why qemu/osdep.h is included first. Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180201111846.21846-5-armbru@redhat.com> [Semantic conflict with commit 34e304e975 resolved, OSX breakage fixed]
* ui: convert VNC server to QIONetListenerDaniel P. Berrange2018-02-021-140/+55Star
| | | | | | | | | | | The VNC server already has the ability to listen on multiple sockets. Converting it to use the QIONetListener APIs though, will reduce the amount of code in the VNC server and improve the clarity of what is left. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20180201164514.10330-1-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* ui: avoid sign extension using client width/heightDaniel P. Berrange2018-01-251-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pixman returns a signed int for the image width/height, but the VNC protocol only permits a unsigned int16. Effective framebuffer size is determined by the guest, limited by the video RAM size, so the dimensions are unlikely to exceed the range of an unsigned int16, but this is not currently validated. With the current use of 'int' for client width/height, the calculation of offsets in vnc_update_throttle_offset() suffers from integer size promotion and sign extension, causing coverity warnings *** CID 1385147: Integer handling issues (SIGN_EXTENSION) /ui/vnc.c: 979 in vnc_update_throttle_offset() 973 * than that the client would already suffering awful audio 974 * glitches, so dropping samples is no worse really). 975 */ 976 static void vnc_update_throttle_offset(VncState *vs) 977 { 978 size_t offset = >>> CID 1385147: Integer handling issues (SIGN_EXTENSION) >>> Suspicious implicit sign extension: "vs->client_pf.bytes_per_pixel" with type "unsigned char" (8 bits, unsigned) is promoted in "vs->client_width * vs->client_height * vs->client_pf.bytes_per_pixel" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "vs->client_width * vs->client_height * vs->client_pf.bytes_per_pixel" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. 979 vs->client_width * vs->client_height * vs->client_pf.bytes_per_pixel; Change client_width / client_height to be a size_t to avoid sign extension and integer promotion. Then validate that dimensions are in range wrt the RFB protocol u16 limits. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20180118155254.17053-1-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* ui: mix misleading comments & return types of VNC I/O helper methodsDaniel P. Berrange2018-01-121-14/+15
| | | | | | | | | | | | | | | While the QIOChannel APIs for reading/writing data return ssize_t, with negative value indicating an error, the VNC code passes this return value through the vnc_client_io_error() method. This detects the error condition, disconnects the client and returns 0 to indicate error. Thus all the VNC helper methods should return size_t (unsigned), and misleading comments which refer to the possibility of negative return values need fixing. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-14-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* ui: add trace events related to VNC client throttlingDaniel P. Berrange2018-01-121-0/+23
| | | | | | | | | | | The VNC client throttling is quite subtle so will benefit from having trace points available for live debugging. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-13-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* ui: place a hard cap on VNC server output buffer sizeDaniel P. Berrange2018-01-121-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous patches fix problems with throttling of forced framebuffer updates and audio data capture that would cause the QEMU output buffer size to grow without bound. Those fixes are graceful in that once the client catches up with reading data from the server, everything continues operating normally. There is some data which the server sends to the client that is impractical to throttle. Specifically there are various pseudo framebuffer update encodings to inform the client of things like desktop resizes, pointer changes, audio playback start/stop, LED state and so on. These generally only involve sending a very small amount of data to the client, but a malicious guest might be able to do things that trigger these changes at a very high rate. Throttling them is not practical as missed or delayed events would cause broken behaviour for the client. This patch thus takes a more forceful approach of setting an absolute upper bound on the amount of data we permit to be present in the output buffer at any time. The previous patch set a threshold for throttling the output buffer by allowing an amount of data equivalent to one complete framebuffer update and one seconds worth of audio data. On top of this it allowed for one further forced framebuffer update to be queued. To be conservative, we thus take that throttling threshold and multiply it by 5 to form an absolute upper bound. If this bound is hit during vnc_write() we forceably disconnect the client, refusing to queue further data. This limit is high enough that it should never be hit unless a malicious client is trying to exploit the sever, or the network is completely saturated preventing any sending of data on the socket. This completes the fix for CVE-2017-15124 started in the previous patches. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-12-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* ui: fix VNC client throttling when forced update is requestedDaniel P. Berrange2018-01-121-4/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The VNC server must throttle data sent to the client to prevent the 'output' buffer size growing without bound, if the client stops reading data off the socket (either maliciously or due to stalled/slow network connection). The current throttling is very crude because it simply checks whether the output buffer offset is zero. This check is disabled if the client has requested a forced update, because we want to send these as soon as possible. As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM. They can first start something in the guest that triggers lots of framebuffer updates eg play a youtube video. Then repeatedly send full framebuffer update requests, but never read data back from the server. This can easily make QEMU's VNC server send buffer consume 100MB of RAM per second, until the OOM killer starts reaping processes (hopefully the rogue QEMU process, but it might pick others...). To address this we make the throttling more intelligent, so we can throttle full updates. When we get a forced update request, we keep track of exactly how much data we put on the output buffer. We will not process a subsequent forced update request until this data has been fully sent on the wire. We always allow one forced update request to be in flight, regardless of what data is queued for incremental updates or audio data. The slight complication is that we do not initially know how much data an update will send, as this is done in the background by the VNC job thread. So we must track the fact that the job thread has an update pending, and not process any further updates until this job is has been completed & put data on the output buffer. This unbounded memory growth affects all VNC server configurations supported by QEMU, with no workaround possible. The mitigating factor is that it can only be triggered by a client that has authenticated with the VNC server, and who is able to trigger a large quantity of framebuffer updates or audio samples from the guest OS. Mostly they'll just succeed in getting the OOM killer to kill their own QEMU process, but its possible other processes can get taken out as collateral damage. This is a more general variant of the similar unbounded memory usage flaw in the websockets server, that was previously assigned CVE-2017-15268, and fixed in 2.11 by: commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493 Author: Daniel P. Berrange <berrange@redhat.com> Date: Mon Oct 9 14:43:42 2017 +0100 io: monitor encoutput buffer size from websocket GSource This new general memory usage flaw has been assigned CVE-2017-15124, and is partially fixed by this patch. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-11-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* ui: fix VNC client throttling when audio capture is activeDaniel P. Berrange2018-01-121-8/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The VNC server must throttle data sent to the client to prevent the 'output' buffer size growing without bound, if the client stops reading data off the socket (either maliciously or due to stalled/slow network connection). The current throttling is very crude because it simply checks whether the output buffer offset is zero. This check must be disabled if audio capture is enabled, because when streaming audio the output buffer offset will rarely be zero due to queued audio data, and so this would starve framebuffer updates. As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM. They can first start something in the guest that triggers lots of framebuffer updates eg play a youtube video. Then enable audio capture, and simply never read data back from the server. This can easily make QEMU's VNC server send buffer consume 100MB of RAM per second, until the OOM killer starts reaping processes (hopefully the rogue QEMU process, but it might pick others...). To address this we make the throttling more intelligent, so we can throttle when audio capture is active too. To determine how to throttle incremental updates or audio data, we calculate a size threshold. Normally the threshold is the approximate number of bytes associated with a single complete framebuffer update. ie width * height * bytes per pixel. We'll send incremental updates until we hit this threshold, at which point we'll stop sending updates until data has been written to the wire, causing the output buffer offset to fall back below the threshold. If audio capture is enabled, we increase the size of the threshold to also allow for upto 1 seconds worth of audio data samples. ie nchannels * bytes per sample * frequency. This allows the output buffer to have a mixture of incremental framebuffer updates and audio data queued, but once the threshold is exceeded, audio data will be dropped and incremental updates will be throttled. This unbounded memory growth affects all VNC server configurations supported by QEMU, with no workaround possible. The mitigating factor is that it can only be triggered by a client that has authenticated with the VNC server, and who is able to trigger a large quantity of framebuffer updates or audio samples from the guest OS. Mostly they'll just succeed in getting the OOM killer to kill their own QEMU process, but its possible other processes can get taken out as collateral damage. This is a more general variant of the similar unbounded memory usage flaw in the websockets server, that was previously assigned CVE-2017-15268, and fixed in 2.11 by: commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493 Author: Daniel P. Berrange <berrange@redhat.com> Date: Mon Oct 9 14:43:42 2017 +0100 io: monitor encoutput buffer size from websocket GSource This new general memory usage flaw has been assigned CVE-2017-15124, and is partially fixed by this patch. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-10-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* ui: refactor code for determining if an update should be sent to the clientDaniel P. Berrange2018-01-121-7/+20
| | | | | | | | | | | | The logic for determining if it is possible to send an update to the client will become more complicated shortly, so pull it out into a separate method for easier extension later. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-9-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* ui: correctly reset framebuffer update state after processing dirty regionsDaniel P. Berrange2018-01-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | According to the RFB protocol, a client sends one or more framebuffer update requests to the server. The server can reply with a single framebuffer update response, that covers all previously received requests. Once the client has read this update from the server, it may send further framebuffer update requests to monitor future changes. The client is free to delay sending the framebuffer update request if it needs to throttle the amount of data it is reading from the server. The QEMU VNC server, however, has never correctly handled the framebuffer update requests. Once QEMU has received an update request, it will continue to send client updates forever, even if the client hasn't asked for further updates. This prevents the client from throttling back data it gets from the server. This change fixes the flawed logic such that after a set of updates are sent out, QEMU waits for a further update request before sending more data. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-8-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* ui: introduce enum to track VNC client framebuffer update request stateDaniel P. Berrange2018-01-121-10/+11
| | | | | | | | | | | | Currently the VNC servers tracks whether a client has requested an incremental or forced update with two boolean flags. There are only really 3 distinct states to track, so create an enum to more accurately reflect permitted states. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-7-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* ui: avoid pointless VNC updates if framebuffer isn't dirtyDaniel P. Berrange2018-01-121-1/+1
| | | | | | | | | | | | | | | The vnc_update_client() method checks the 'has_dirty' flag to see if there are dirty regions that are pending to send to the client. Regardless of this flag, if a forced update is requested, updates must be sent. For unknown reasons though, the code also tries to sent updates if audio capture is enabled. This makes no sense as audio capture state does not impact framebuffer contents, so this check is removed. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-5-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* ui: remove redundant indentation in vnc_client_updateDaniel P. Berrange2018-01-121-55/+57
| | | | | | | | | | | Now that previous dead / unreachable code has been removed, we can simplify the indentation in the vnc_client_update method. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-4-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* ui: remove unreachable code in vnc_update_clientDaniel P. Berrange2018-01-121-5/+1Star
| | | | | | | | | | | | | | | | | | | | | | | A previous commit: commit 5a8be0f73d6f60ff08746377eb09ca459f39deab Author: Gerd Hoffmann <kraxel@redhat.com> Date: Wed Jul 13 12:21:20 2016 +0200 vnc: make sure we finish disconnect Added a check for vs->disconnecting at the very start of the vnc_update_client method. This means that the very next "if" statement check for !vs->disconnecting always evaluates true, and is thus redundant. This in turn means the vs->disconnecting check at the very end of the method never evaluates true, and is thus unreachable code. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-3-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* ui: remove 'sync' parameter from vnc_update_clientDaniel P. Berrange2018-01-121-8/+3Star
| | | | | | | | | | | There is only one caller of vnc_update_client and that always passes false for the 'sync' parameter. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-2-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* vnc: fix debug spellingMarc-André Lureau2018-01-121-1/+1
| | | | | | Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171220140618.12701-1-marcandre.lureau@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* ui: Always remove an old VNC channel watch before adding a new oneBrandon Carpenter2017-10-041-0/+4
| | | | | | | | Also set saved handle to zero when removing without adding a new watch. Signed-off-by: Brandon Carpenter <brandon.carpenter@cypherpath.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
* ui: add tracing of VNC authentication processDaniel P. Berrange2017-09-291-18/+18
| | | | | | | | | Trace anything related to authentication in the VNC protocol handshake Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170921121528.23935-3-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* ui: add tracing of VNC operations related to QIOChannelDaniel P. Berrange2017-09-291-3/+8
| | | | | | | | | Trace anything which opens/closes/wraps a QIOChannel in the VNC server. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170921121528.23935-2-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* qapi: Mechanically convert FOO_lookup[...] to FOO_str(...)Markus Armbruster2017-09-041-3/+3
| | | | | | Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1503564371-26090-14-git-send-email-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
* vnc: use DIV_ROUND_UPMarc-André Lureau2017-08-311-1/+1
| | | | | | | | I used the clang-tidy qemu-round check to generate the fix: https://github.com/elmarco/clang-tools-extra Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Richard Henderson <rth@twiddle.net>
* vnc: use QEMU_ALIGN_DOWNMarc-André Lureau2017-08-311-4/+4
| | | | | | | | I used the clang-tidy qemu-round check to generate the fix: https://github.com/elmarco/clang-tools-extra Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Richard Henderson <rth@twiddle.net>
* ui/vnc: fix leak of SocketAddress **Philippe Mathieu-Daudé2017-07-311-18/+18
| | | | | | | | | | Extract the (correct) cleaning code as a new function vnc_free_addresses() then use it to remove the memory leaks. Reported-by: Clang Static Analyzer Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
* vnc: Set default kbd delay to 10msAlexander Graf2017-07-171-1/+1
| | | | | | | | | | | | | | | | | | The current VNC default keyboard delay is 1ms. With that we're constantly typing faster than the guest receives keyboard events from an XHCI attached USB HID device. The default keyboard delay time in the input layer however is 10ms. I don't know how that number came to be, but empirical tests on some OpenQA driven ARM systems show that 10ms really is a reasonable default number for the delay. This patch moves the VNC delay also to 10ms. That way our default is much safer (good!) and also consistent with the input layer default (also good!). Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 1499863425-103133-1-git-send-email-agraf@suse.de Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-14 11:37:47 +0200