aboutsummaryrefslogtreecommitdiff
path: root/ui/vnc.h
AgeCommit message (Collapse)Author
2017-02-08ui: refactor VncDisplay to allow multiple listening socketsDaniel P. Berrange
Currently there is only a single listener for plain VNC and a single listener for websockets VNC. This means that if getaddrinfo() returns multiple IP addresses, for a hostname, the VNC server can only listen on one of them. This is just bearable if listening on wildcard interface, or if the host only has a single network interface to listen on, but if there are multiple NICs and the VNC server needs to listen on 2 or more specific IP addresses, it can't be done. This refactors the VncDisplay state so that it holds an array of listening sockets, but still only listens on one socket. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170203120649.15637-4-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-01-31vnc: track LED state separatelyPierre Ossman
Piggy-backing on the modifier state array made it difficult to send out updates at the proper times. Signed-off-by: Pierre Ossman <ossman@cendio.se> Message-id: 5aa28297d665cee24ddab26bbf4633e4252f97b6.1483978442.git.ossman@cendio.se Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2016-10-13ui: rename vnc_init_state to vnc_start_protocolDaniel P. Berrange
Rename the vnc_init_state method to reflect what its actual purpose is, to discourage future devs from using it for more general state initialization. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 1475163940-26094-10-git-send-email-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2016-10-13ui: move some initialization out of vnc_init_stateDaniel P. Berrange
Most of the fields in VncState are initialized in the vnc_connect() method, but some are done in vnc_init_state() instead. The purpose of having vnc_init_state() is to delay starting of the VNC wire protocol until after the websockets handshake has completed. As such the vnc_init_state() method only needs to be used for initialization that is dependant on the wire protocol running. This also lets us get rid of the initialized boolean flag from the VncState struct. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 1475163940-26094-9-git-send-email-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2016-10-13ui: refactor method for setting up VncDisplay auth typesDaniel P. Berrange
There is a lot of repeated code in the auth type setup method, particularly around checking TLS credential types. Refactor it to reduce duplication and instead of having one method do both plain and websockets at once, call it separately for each. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 1475163940-26094-6-git-send-email-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2016-10-13ui: remove 'ws_tls' field from VncStateDaniel P. Berrange
The 'ws_tls' field in VncState is only ever representing the result of 'tlscreds != NULL' and is thus pointless. Replace use of 'ws_tls' with a direct check against 'tlscreds' Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 1475163940-26094-4-git-send-email-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2016-10-13ui: remove 'enabled' and 'ws_enabled' fields from VncStateDaniel P. Berrange
The 'ws_enabled' field is never used outside of the vnc_display_open method, so can be a local variable. The 'enabled' field is easily replaced by a check for whether 'lsock' is non-NULL. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 1475163940-26094-3-git-send-email-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2016-07-12Clean up ill-advised or unusual header guardsMarkus Armbruster
Cleaned up with scripts/clean-header-guards.pl. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Richard Henderson <rth@twiddle.net>
2016-06-03vnc: add configurable keyboard delayGerd Hoffmann
Limits the rate kbd events from the vnc server are forwarded to the guest, so input devices which are typically low-bandwidth can keep up even on bulky input. v2: update documentation too. v3: spell fixes. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Yang Hongyang <hongyang.yang@easystack.cn> Message-id: 1464762150-25817-1-git-send-email-kraxel@redhat.com
2016-02-23all: Clean up includesPeter Maydell
Clean up includes so that osdep.h is included first and headers which it implies are not included manually. This commit was created with scripts/clean-includes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Eric Blake <eblake@redhat.com>
2015-12-18ui: convert VNC server to use QIOChannelWebsockDaniel P. Berrange
Remove custom websock handling code from the VNC server and use the QIOChannelWebsock class instead. Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-12-18ui: convert VNC server to use QIOChannelTLSDaniel P. Berrange
Switch VNC server over to using the QIOChannelTLS object for the TLS session. This removes all remaining VNC specific code for dealing with TLS handshakes. Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-12-18ui: convert VNC server to use QIOChannelSocketDaniel P. Berrange
The minimal first step conversion to use QIOChannelSocket classes instead of directly using POSIX sockets API. This will later be extended to also cover the TLS, SASL and websockets code. Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-10-20util: pull Buffer code out of VNC moduleDaniel P. Berrange
The Buffer code in the VNC server is useful for the IO channel code, so pull it out into a shared module, QIOBuffer. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-09-15ui: convert VNC server to use QCryptoTLSSessionDaniel P. Berrange
Switch VNC server over to using the QCryptoTLSSession object for the TLS session. This removes the direct use of gnutls from the VNC server code. It also removes most knowledge about TLS certificate handling from the VNC server code. This has the nice effect that all the CONFIG_VNC_TLS conditionals go away and the user gets an actual error message when requesting TLS instead of it being silently ignored. With this change, the existing configuration options for enabling TLS with -vnc are deprecated. Old syntax for anon-DH credentials: -vnc hostname:0,tls New syntax: -object tls-creds-anon,id=tls0,endpoint=server \ -vnc hostname:0,tls-creds=tls0 Old syntax for x509 credentials, no client certs: -vnc hostname:0,tls,x509=/path/to/certs New syntax: -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=no \ -vnc hostname:0,tls-creds=tls0 Old syntax for x509 credentials, requiring client certs: -vnc hostname:0,tls,x509verify=/path/to/certs New syntax: -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=yes \ -vnc hostname:0,tls-creds=tls0 This aligns VNC with the way TLS credentials are to be configured in the future for chardev, nbd and migration backends. It also has the benefit that the same TLS credentials can be shared across multiple VNC server instances, if desired. If someone uses the deprecated syntax, it will internally result in the creation of a 'tls-creds' object with an ID based on the VNC server ID. This allows backwards compat with the CLI syntax, while still deleting all the original TLS code from the VNC server. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-09-15ui: fix return type for VNC I/O functions to be ssize_tDaniel P. Berrange
Various VNC server I/O functions return 'long' and then also pass this to a method accepting 'int'. All these should be ssize_t to match the signature of read/write APIs and thus avoid potential for integer truncation / wraparound. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2015-07-08ui: convert VNC websockets to use crypto APIsDaniel P. Berrange
Remove the direct use of gnutls for hash processing in the websockets code, in favour of using the crypto APIs. This allows the websockets code to be built unconditionally removing countless conditional checks from the VNC code. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1435770638-25715-9-git-send-email-berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-04-01CVE-2015-1779: incrementally decode websocket framesDaniel P. Berrange
The logic for decoding websocket frames wants to fully decode the frame header and payload, before allowing the VNC server to see any of the payload data. There is no size limit on websocket payloads, so this allows a malicious network client to consume 2^64 bytes in memory in QEMU. It can trigger this denial of service before the VNC server even performs any authentication. The fix is to decode the header, and then incrementally decode the payload data as it is needed. With this fix the websocket decoder will allow at most 4k of data to be buffered before decoding and processing payload. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> [ kraxel: fix frequent spurious disconnects, suggested by Peter Maydell ] @@ -361,7 +361,7 @@ int vncws_decode_frame_payload(Buffer *input, - *payload_size = input->offset; + *payload_size = *payload_remain; [ kraxel: fix 32bit build ] @@ -306,7 +306,7 @@ struct VncState - uint64_t ws_payload_remain; + size_t ws_payload_remain; Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2015-03-18ui: remove separate gnutls_session for websockets serverDaniel P. Berrange
The previous change to the auth scheme handling guarantees we can never have nested TLS sessions in the VNC websockets server. Thus we can remove the separate gnutls_session instance. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2015-03-18ui: fix setup of VNC websockets auth scheme with TLSDaniel P. Berrange
The way the websockets TLS code was integrated into the VNC server made it essentially useless. The only time that the websockets TLS support could be used is if the primary VNC server had its existing TLS support disabled. ie QEMU had to be launched with: # qemu -vnc localhost:1,websockets=5902,x509=/path/to/certs Note the absence of the 'tls' flag. This is already a bug, because the docs indicate that 'x509' is ignored unless 'tls' is given. If the primary VNC server had TLS turned on via the 'tls' flag, then this prevented the websockets TLS support from being used, because it activates the VeNCrypt auth which would have resulted in TLS being run over a TLS session. Of course no websockets VNC client supported VeNCrypt so in practice, since the browser clients cannot setup a nested TLS session over the main HTTPS connection, so it would not even get past auth. This patch causes us to decide our auth scheme separately for the main VNC server vs the websockets VNC server. We take account of the fact that if TLS is enabled, then the websockets client will use https, so setting up VeNCrypt is thus redundant as it would lead to nested TLS sessions. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2015-03-18ui: report error if user requests VNC option that is unsupportedDaniel P. Berrange
If the VNC server is built without tls, sasl or websocket support and the user requests one of these features, they are just silently ignored. This is bad because it means the VNC server ends up running in a configuration that is less secure than the user asked for. It also leads to an tangled mass of preprocessor conditionals when configuring the VNC server. This ensures that the tls, sasl & websocket options are always processed and an error is reported back to the user if any of them were disabled at build time. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2015-03-12vnc: drop display+ws_display from VncDisplayGerd Hoffmann
Nobody cares about those strings, they are only used to check whenever the vnc server / websocket support is enabled or not. Add bools for this and drop the strings. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Gonglei <arei.gonglei@huawei.com>
2015-01-22vnc: track & limit connectionsGerd Hoffmann
Also track the number of connections in "connecting" and "shared" state (in addition to the "exclusive" state). Apply a configurable limit to these connections. The logic to apply the limit to connections in "shared" state is pretty simple: When the limit is reached no new connections are allowed. The logic to apply the limit to connections in "connecting" state (this is the state you are in *before* successful authentication) is slightly different: A new connect kicks out the oldest client which is still in "connecting" state. This avoids a easy DoS by unauthenticated users by simply opening connections until the limit is reached. Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2015-01-22vnc: remove vnc_display globalGerd Hoffmann
Replace with a vnc_displays list, so we can have multiple vnc server instances. Add vnc_server_find function to lookup a display by id. With no id supplied return the first vnc server, for backward compatibility reasons. It is not possible (yet) to actually create multiple vnc server instances. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Gonglei <arei.gonglei@huawei.com>
2014-07-25vnc update fixGerd Hoffmann
We need to remember has_updates for each vnc client. Otherwise it might happen that vnc_update_client(has_dirty=1) takes the first exit due to output buffers not being flushed yet and subsequent calls with has_dirty=0 take the second exit, wrongly assuming there is nothing to do because the work defered in the first call is ignored. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Peter Lieven <pl@kamp.de>
2014-07-01ui/vnc: fix potential memory corruption issuesPeter Lieven
this patch makes the VNC server work correctly if the server surface and the guest surface have different sizes. Basically the server surface is adjusted to not exceed VNC_MAX_WIDTH x VNC_MAX_HEIGHT and additionally the width is rounded up to multiple of VNC_DIRTY_PIXELS_PER_BIT. If we have a resolution whose width is not dividable by VNC_DIRTY_PIXELS_PER_BIT we now get a small black bar on the right of the screen. If the surface is too big to fit the limits only the upper left area is shown. On top of that this fixes 2 memory corruption issues: The first was actually discovered during playing around with a Windows 7 vServer. During resolution change in Windows 7 it happens sometimes that Windows changes to an intermediate resolution where server_stride % cmp_bytes != 0 (in vnc_refresh_server_surface). This happens only if width % VNC_DIRTY_PIXELS_PER_BIT != 0. The second is a theoretical issue, but is maybe exploitable by the guest. If for some reason the guest surface size is bigger than VNC_MAX_WIDTH x VNC_MAX_HEIGHT we end up in severe corruption since this limit is nowhere enforced. Signed-off-by: Peter Lieven <pl@kamp.de> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-06-23qapi event: convert VNC eventsWenchao Xia
Since VNC_CONNECTED, VNC_DISCONNECTED, VNC_INITIALIZED share some common functions, convert them in one patch. Signed-off-by: Wenchao Xia <wenchaoqemu@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
2014-03-10ui/vnc: optimize dirty bitmap trackingPeter Lieven
vnc_update_client currently scans the dirty bitmap of each client bitwise which is a very costly operation if only few bits are dirty. vnc_refresh_server_surface does almost the same. this patch optimizes both by utilizing the heavily optimized function find_next_bit to find the offset of the next dirty bit in the dirty bitmaps. The following artifical test (just the bitmap operation part) running vnc_update_client 65536 times on a 2560x2048 surface illustrates the performance difference: All bits clean - vnc_update_client_new: 0.07 secs vnc_update_client_old: 10.98 secs All bits dirty - vnc_update_client_new: 11.26 secs vnc_update_client_old: 20.19 secs Few bits dirty - vnc_update_client_new: 0.08 secs vnc_update_client_old: 10.98 secs The case for all bits dirty is still rather slow, this is due to the implementation of find_and_clear_dirty_height. This will be addresses in a separate patch. Signed-off-by: Peter Lieven <pl@kamp.de> Reviewed-by: Wenchao Xia <xiawenc@linux.vnet.ibm.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-03-10ui/vnc: introduce VNC_DIRTY_PIXELS_PER_BIT macroPeter Lieven
Signed-off-by: Peter Lieven <pl@kamp.de> Reviewed-by: Wenchao Xia <xiawenc@linux.vnet.ibm.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-03-05input: mouse: switch vnc ui to new coreGerd Hoffmann
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2013-05-03TLS support for VNC WebsocketsTim Hardeck
Added TLS support to the VNC QEMU Websockets implementation. VNC-TLS needs to be enabled for this feature to be used. The required certificates are specified as in case of VNC-TLS with the VNC parameter "x509=<path>". If the server certificate isn't signed by a rooth authority it needs to be manually imported in the browser because at least in case of Firefox and Chrome there is no user dialog, the connection just gets canceled. As a side note VEncrypt over Websocket doesn't work atm because TLS can't be stacked in the current implementation. (It also didn't work before) Nevertheless to my knowledge there is no HTML 5 VNC client which supports it and the Websocket connection can be encrypted with regular TLS now so it should be fine for most use cases. Signed-off-by: Tim Hardeck <thardeck@suse.de> Reviewed-by: Anthony Liguori <aliguori@us.ibm.com> Message-id: 1366727581-5772-1-git-send-email-thardeck@suse.de Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-04-29vnc: Support for LED state extensionLei Li
Signed-off-by: Lei Li <lilei@linux.vnet.ibm.com> Reviewed-by: Anthony Liguori <aliguori@us.ibm.com> Message-id: 1366867752-11578-3-git-send-email-lilei@linux.vnet.ibm.com Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-04-16console: gui timer fixesGerd Hoffmann
Make gui update rate adaption code in gui_update() actually work. Sprinkle in a tracepoint so you can see the code at work. Remove the update rate adaption code in vnc and make vnc simply use the generic bits instead. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2013-03-18vnc: stop using DisplayStateGerd Hoffmann
Rework DisplayStateListener callbacks to not use the DisplayState any more. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2013-03-18console: kill DisplayState->opaqueGerd Hoffmann
It's broken by design. There can be multiple DisplayChangeListener instances, so they simply can't store state in the (single) DisplayState struct. Try 'qemu -display gtk -vnc :0', watch it crash & burn. With DisplayChangeListenerOps having a more sane interface now we can simply use the DisplayChangeListener pointer to get access to our private data instead. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2013-01-21vnc: fix possible uninitialized removalsTim Hardeck
Some VncState values are not initialized before the Websocket handshake. If it fails QEMU segfaults during the cleanup. To prevent this behavior intialization checks are added. Signed-off-by: Tim Hardeck <thardeck@suse.de> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-01-21vnc: added initial websocket protocol supportTim Hardeck
This patch adds basic Websocket Protocol version 13 - RFC 6455 - support to QEMU VNC. Binary encoding support on the client side is mandatory. Because of the GnuTLS requirement the Websockets implementation is optional (--enable-vnc-ws). To activate Websocket support the VNC option "websocket"is used, for example "-vnc :0,websocket". The listen port for Websocket connections is (5700 + display) so if QEMU VNC is started with :0 the Websocket port would be 5700. As an alternative the Websocket port could be manually specified by using ",websocket=<port>" instead. Parts of the implementation base on Anthony Liguori's QEMU Websocket patch from 2010 and on Joel Martin's LibVNC Websocket implementation. Signed-off-by: Tim Hardeck <thardeck@suse.de> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-01-21vnc: added buffer_advance functionTim Hardeck
Following Anthony Liguori's Websocket implementation I have added the buffer_advance function to VNC and replaced all related buffer memmove operations with it. Signed-off-by: Tim Hardeck <thardeck@suse.de> Reviewed-by: Anthony Liguori <aliguori@us.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-12-19misc: move include files to include/qemu/Paolo Bonzini
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2012-12-19monitor: move include files to include/monitor/Paolo Bonzini
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2012-12-19ui: move files to ui/ and include/ui/Paolo Bonzini
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2012-11-03Merge branch 'trivial-patches' of git://github.com/stefanha/qemuBlue Swirl
* 'trivial-patches' of git://github.com/stefanha/qemu: pc: Drop redundant test for ROM memory region exec: make some functions static target-ppc: make some functions static ppc: add missing static vnc: add missing static vl.c: add missing static target-sparc: make do_unaligned_access static m68k: Return semihosting errno values correctly cadence_uart: More debug information Conflicts: target-m68k/m68k-semi.c
2012-11-01vnc: add missing staticBlue Swirl
Add missing 'static' qualifiers. Signed-off-by: Blue Swirl <blauwirbel@gmail.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2012-11-01pixman/vnc: use pixman images in vnc.Gerd Hoffmann
The vnc code uses *three* DisplaySurfaces: First is the surface of the actual QemuConsole, usually the guest screen, but could also be a text console (monitor/serial reachable via Ctrl-Alt-<nr> keys). This is left as-is. Second is the current server's view of the screen content. The vnc code uses this to figure which parts of the guest screen did _really_ change to reduce the amount of updates sent to the vnc clients. It is also used as data source when sending out the updates to the clients. This surface gets replaced by a pixman image. The format changes too, instead of using the guest screen format we'll use fixed 32bit rgb framebuffer and convert the pixels on the fly when comparing and updating the server framebuffer. Third surface carries the format expected by the vnc client. That isn't used to store image data. This surface is switched to PixelFormat and a boolean for bigendian byte order. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2012-06-27Remove support for non-threaded VNC serverDaniel P. Berrange
QEMU now has a fundamental requirement for pthreads, so there is no compelling reason to retain support for the non-threaded VNC server. Remove the --{enable,disable}-vnc-thread configure arguments, and all CONFIG_VNC_THREAD conditionals Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-03-14vnc: don't mess up with iohandlers in the vnc threadCorentin Chary
The threaded VNC servers messed up with QEMU fd handlers without any kind of locking, and that can cause some nasty race conditions. Using qemu_mutex_lock_iothread() won't work because vnc_dpy_cpy(), which will wait for the current job queue to finish, can be called with the iothread lock held. Instead, we now store the data in a temporary buffer, and use a bottom half to notify the main thread that new data is available. vnc_[un]lock_ouput() is still needed to access VncState members like abort, csock or jobs_buffer. Signed-off-by: Corentin Chary <corentin.chary@gmail.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-02-10vnc: implement shared flag handling.Gerd Hoffmann
VNC clients send a shared flag in the client init message. Up to now qemu completely ignores this. This patch implements shared flag handling. It comes with three policies: By default qemu behaves as one would expect: Asking for a exclusive access grants exclusive access to the client connecting. There is also a desktop sharing mode which disallows exclusive connects (so one forgetting -shared wouldn't drop everybody else) and a compatibility mode which mimics the traditional (but non-conforming) qemu behavior. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2011-07-23Store VNC auth scheme per-client as well as per-serverDaniel P. Berrange
A future patch will introduce a situation where different clients may have different authentication schemes set. When a new client arrives, copy the 'auth' and 'subauth' fields from VncDisplay into the client's VncState, and use the latter in all authentication functions. * ui/vnc.h: Add 'auth' and 'subauth' to VncState * ui/vnc-auth-sasl.c, ui/vnc-auth-vencrypt.c, ui/vnc.c: Make auth functions pull auth scheme from VncState instead of VncDisplay Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-03-10vnc: Fix stack corruption and other bitmap related bugsStefan Weil
Commit bc2429b9174ac2d3c56b7fd35884b0d89ec7fb02 introduced a severe bug (stack corruption). bitmap_clear was called with a wrong argument which caused out-of-bound writes to the local variable width_mask. This bug was detected with QEMU running on windows. It also occurs with wine: *** stack smashing detected ***: terminated wine: Unhandled illegal instruction at address 0x6115c7 (thread 0009), starting debugger... The bug is not windows specific! Instead of fixing the wrong parameter value, bitmap_clear(), bitmap_set and width_mask were removed, and bitmap_intersect() was replaced by !bitmap_empty(). The new operation is much shorter and equivalent to the old operations. The declarations of the dirty bitmaps in vnc.h were also wrong for 64 bit hosts because of a rounding effect: for these hosts, VNC_MAX_WIDTH is no longer a multiple of (16 * BITS_PER_LONG), so the rounded value of VNC_DIRTY_WORDS was too small. Fix both declarations by using the macro which is designed for this purpose. Cc: Corentin Chary <corentincj@iksaif.net> Cc: Wen Congyang <wency@cn.fujitsu.com> Cc: Gerhard Wiesinger <lists@wiesinger.com> Cc: Anthony Liguori <aliguori@us.ibm.com> Signed-off-by: Stefan Weil <weil@mail.berlios.de> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-02-23vnc: add a non-adaptive optionCorentin Chary
This option allow to disable adaptive behaviors in some encodings. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
generated by cgit v1.2.3 (git 2.26.2) at 2024-12-18 19:22:55 +0000