aboutsummaryrefslogtreecommitdiff
path: root/vnc.h
AgeCommit message (Collapse)Author
2010-04-09Remove magic numbers for VNC message IDs from codeDaniel P. Berrange
The code processing incoming & sending outgoing messages from/to clients used embedded magic numbers for all message IDs. This made the code a little hard to follow. Add constants in the vnc.h header file for all message IDs and use them in the code Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-19input: make vnc use mouse mode notifiersAnthony Liguori
When we switch to absolute mode, we send out a notification (if the client supports it). Today, we only send this notification when the client sends us a mouse event and we're in the wrong mode. Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-03-17vnc: add no-lock-key-sync optionGerd Hoffmann
Add an option to disable the heuristics which try to keep capslock and numlock state for guest and host in sync. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-03-09kbd keds: vncGerd Hoffmann
Use led status notification support in vnc. The qemu vnc server keeps track of the capslock and numlock states based on the key presses it receives from the vnc client. But this fails in case the guests idea of the capslock and numlock state changes for other reasons. One case is guest reboot (+ keyboard reset). Another case are more recent windows versions which reset capslock state before presenting the login screen. Usually guests use the keyboard leds to signal the capslock and numlock state to the user, so we can use this to better keep track of capslock and numlock state in the qemu vnc server. Also toggle the numlock and capslock states on keydown events (instead of keyup). Guests do the same. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-02-10Increase VNC_MAX_WIDTHBrian Jackson
Increase VNC_MAX_WIDTH to match "commonly available" consumer level monitors available these days. This also closes KVM bug 2907597 Signed-off-by: Brian Jackson <iggy@theiggy.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-02-10vnc: Migrate to using QTAILQ instead of custom implementationAmit Shah
Just a 1-1 conversion for now. Signed-off-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-01-19VNC: Cache client info at connection timeLuiz Capitulino
When a disconnection happens the client's socket on QEMU side may become invalid, this way it won't be possible to query it to get client information, which is going to be needed by the future QMP VNC_DISCONNECTED event. To always have this information available we query the socket at connection time and cache the client info in struct VncState. Two function are introduced to perform this job. vnc_client_cache_addr() is called right when the connection is made, however the authentication information is not available at that moment so vnc_client_cache_auth() is called from protocol_client_init() to get auth info. Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2009-10-01Revert "Get rid of _t suffix"Anthony Liguori
In the very least, a change like this requires discussion on the list. The naming convention is goofy and it causes a massive merge problem. Something like this _must_ be presented on the list first so people can provide input and cope with it. This reverts commit 99a0949b720a0936da2052cb9a46db04ffc6db29. Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2009-10-01Get rid of _t suffixmalc
Some not so obvious bits, slirp and Xen were left alone for the time being. Signed-off-by: malc <av1474@comtv.ru>
2009-08-10variable timer intervalsStefano Stabellini
This patch introduces dynamic timer intervals: we slow down the refresh rate when there in no much activity but we get back to a fast refresh rate when the activity resume. Please note that qemu_timer_expired is not an inline function any more because I needed to call it from vnc.c however I don't think this change should have any serious consequence. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> Message-Id:
2009-08-10single vnc server surfaceStefano Stabellini
This patch removes the server surface from VncState and adds a single server surface to VncDisplay for all the possible clients connected. Each client maintains a different dirty bitmap in VncState. The guest surface is moved to VncDisplay as well because we don't need to track guest updates in more than one place. This patch has been updated to handle CopyRect correctly and efficiently. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> Message-Id:
2009-08-10a single vnc timer to refresh the screenStefano Stabellini
This patch removes the timer per vnc client connected and adds a single timer to update all the possible clients. We call vga_hw_update only once in the timer handler. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> Message-Id:
2009-03-20vnc: throttle screen updates. (Gerd Hoffmann)aliguori
This patch makes the vnc server code skip screen refreshes in case there is data in the output buffer. This reduces the refresh rate to throttle the bandwidth needed in case the network link is saturated. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6862 c046a42c-6fe2-441c-8c8c-71466251a162
2009-03-20vnc: cleanup surface handling, fix screen corruption bug. (Gerd Hoffmann)aliguori
This patch killes the old_data hack in the qemu server and replaces it with a clean separation of the guest-visible display surface and the vnc server display surface. Both guest and server surface have their own dirty bitmap for tracking screen updates. Workflow is this: (1) The guest writes to the guest surface. With shared buffers being active the guest writes are directly visible to the vnc server code. Note that this may happen in parallel to the vnc server code running (today only in xenfb, once we have vcpu threads in qemu also for other display adapters). (2) vnc_update() callback tags the specified area in the guest dirty map. (3) vnc_update_client() will first walk through the guest dirty map. It will compare guest and server surface for all regions tagged dirty and in case the screen content really did change the server surface and dirty map are updated. Note: old code used old_data in a simliar way, so this does *not* introduce an extra memcpy. (4) Then vnc_update_cient() will send the updates to the vnc client using the server surface and dirty map. Note: old code used the guest-visible surface instead, causing screen corruption in case of guest screen updates running in parallel. The separate dirty bitmap also has the nice effect that forced screen updates can be done cleanly by simply tagging the area in both guest and server dirty map. The old, hackish way was memset(old_data, 42, size) to trick the code checking for screen changes. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6860 c046a42c-6fe2-441c-8c8c-71466251a162
2009-03-06Support ACLs for controlling VNC access ("Daniel P. Berrange")aliguori
This patch introduces a generic internal API for access control lists to be used by network servers in QEMU. It adds support for checking these ACL in the VNC server, in two places. The first ACL is for the SASL authentication mechanism, checking the SASL username. This ACL is called 'vnc.username'. The second is for the TLS authentication mechanism, when x509 client certificates are turned on, checking against the Distinguished Name of the client. This ACL is called 'vnc.x509dname' The internal API provides for an ACL with the following characteristics - A unique name, eg vnc.username, and vnc.x509dname. - A default policy, allow or deny - An ordered series of match rules, with allow or deny policy If none of the match rules apply, then the default policy is used. There is a monitor API to manipulate the ACLs, which I'll describe via examples (qemu) acl show vnc.username policy: allow (qemu) acl policy vnc.username denya acl: policy set to 'deny' (qemu) acl allow vnc.username fred acl: added rule at position 1 (qemu) acl allow vnc.username bob acl: added rule at position 2 (qemu) acl allow vnc.username joe 1 acl: added rule at position 1 (qemu) acl show vnc.username policy: deny 0: allow fred 1: allow joe 2: allow bob (qemu) acl show vnc.x509dname policy: allow (qemu) acl policy vnc.x509dname deny acl: policy set to 'deny' (qemu) acl allow vnc.x509dname C=GB,O=ACME,L=London,CN=* acl: added rule at position 1 (qemu) acl allow vnc.x509dname C=GB,O=ACME,L=Boston,CN=bob acl: added rule at position 2 (qemu) acl show vnc.x509dname policy: deny 0: allow C=GB,O=ACME,L=London,CN=* 1: allow C=GB,O=ACME,L=Boston,CN=bob By default the VNC server will not use any ACLs, allowing access to the server if the user successfully authenticates. To enable use of ACLs to restrict user access, the ',acl' flag should be given when starting QEMU. The initial ACL activated will be a 'deny all' policy and should be customized using monitor commands. eg enable SASL auth and ACLs qemu .... -vnc localhost:1,sasl,acl The next patch will provide a way to load a pre-defined ACL when starting up Makefile | 6 + b/acl.c | 185 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ b/acl.h | 74 ++++++++++++++++++++++ configure | 18 +++++ monitor.c | 95 ++++++++++++++++++++++++++++ qemu-doc.texi | 49 ++++++++++++++ vnc-auth-sasl.c | 16 +++- vnc-auth-sasl.h | 7 ++ vnc-tls.c | 19 +++++ vnc-tls.h | 3 vnc.c | 21 ++++++ vnc.h | 3 12 files changed, 491 insertions(+), 5 deletions(-) Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6726 c046a42c-6fe2-441c-8c8c-71466251a162
2009-03-06Add SASL authentication support ("Daniel P. Berrange")aliguori
This patch adds the new SASL authentication protocol to the VNC server. It is enabled by setting the 'sasl' flag when launching VNC. SASL can optionally provide encryption via its SSF layer, if a suitable mechanism is configured (eg, GSSAPI/Kerberos, or Digest-MD5). If an SSF layer is not available, then it should be combined with the x509 VNC authentication protocol which provides encryption. eg, if using GSSAPI qemu -vnc localhost:1,sasl eg if using TLS/x509 for encryption qemu -vnc localhost:1,sasl,tls,x509 By default the Cyrus SASL library will look for its configuration in the file /etc/sasl2/qemu.conf. For non-root users, this can be overridden by setting the SASL_CONF_PATH environment variable, eg to make it look in $HOME/.sasl2. NB unprivileged users may not have access to the full range of SASL mechanisms, since some of them require some administrative privileges to configure. The patch includes an example SASL configuration file which illustrates config for GSSAPI and Digest-MD5, though it should be noted that the latter is not really considered secure any more. Most of the SASL authentication code is located in a separate source file, vnc-auth-sasl.c. The main vnc.c file only contains minimal integration glue, specifically parsing of command line flags / setup, and calls to start the SASL auth process, to do encoding/decoding for data. There are several possible stacks for reading & writing of data, depending on the combo of VNC authentication methods in use - Clear. read/write straight to socket - TLS. read/write via GNUTLS helpers - SASL. encode/decode via SASL SSF layer, then read/write to socket - SASL+TLS. encode/decode via SASL SSF layer, then read/write via GNUTLS Hence, the vnc_client_read & vnc_client_write methods have been refactored a little. vnc_client_read: main entry point for reading, calls either - vnc_client_read_plain reading, with no intermediate decoding - vnc_client_read_sasl reading, with SASL SSF decoding These two methods, then call vnc_client_read_buf(). This decides whether to write to the socket directly or write via GNUTLS. The situation is the same for writing data. More extensive comments have been added in the code / patch. The vnc_client_read_sasl and vnc_client_write_sasl method implementations live in the separate vnc-auth-sasl.c file. The state required for the SASL auth mechanism is kept in a separate VncStateSASL struct, defined in vnc-auth-sasl.h and included in the main VncState. The configure script probes for SASL and automatically enables it if found, unless --disable-vnc-sasl was given to override it. Makefile | 7 Makefile.target | 5 b/qemu.sasl | 34 ++ b/vnc-auth-sasl.c | 626 ++++++++++++++++++++++++++++++++++++++++++++++++++++ b/vnc-auth-sasl.h | 67 +++++ configure | 34 ++ qemu-doc.texi | 97 ++++++++ vnc-auth-vencrypt.c | 12 vnc.c | 249 ++++++++++++++++++-- vnc.h | 31 ++ 10 files changed, 1129 insertions(+), 33 deletions(-) Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6724 c046a42c-6fe2-441c-8c8c-71466251a162
2009-03-06Move TLS auth into separate file ("Daniel P. Berrange")aliguori
This patch refactors the existing TLS code to make the main VNC code more managable. The code moves to two new files - vnc-tls.c: generic helpers for TLS handshake & credential setup - vnc-auth-vencrypt.c: the actual VNC TLS authentication mechanism. The reason for this split is that there are other TLS based auth mechanisms which we may like to use in the future. These can all share the same vnc-tls.c routines. In addition this will facilitate anyone who may want to port the vnc-tls.c file to allow for choice of GNUTLS & NSS for impl. The TLS state is moved out of the VncState struct, and into a separate VncStateTLS struct, defined in vnc-tls.h. This is then referenced from the main VncState. End size of the struct is the same, but it keeps things a little more managable. The vnc.h file gains a bunch more function prototypes, for functions in vnc.c that were previously static, but now need to be accessed from the separate auth code files. The only TLS related code still in the main vl.c is the command line argument handling / setup, and the low level I/O routines calling gnutls_send/recv. Makefile | 11 b/vnc-auth-vencrypt.c | 167 ++++++++++++++ b/vnc-auth-vencrypt.h | 33 ++ b/vnc-tls.c | 414 +++++++++++++++++++++++++++++++++++ b/vnc-tls.h | 70 ++++++ vnc.c | 581 +++----------------------------------------------- vnc.h | 76 ++++-- 7 files changed, 780 insertions(+), 572 deletions(-) Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6723 c046a42c-6fe2-441c-8c8c-71466251a162
2009-03-06Move VNC structs into header file ("Daniel P. Berrange")aliguori
This patch moves the definitions of VncState and VncDisplay structs out into a vnc.h header file. This is to allow the code for TLS and SASL auth mechanisms to be moved out of the main vnc.c file. vnc.c | 109 ------------------------------------------------ vnc.h | 149 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 148 insertions(+), 110 deletions(-) Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6722 c046a42c-6fe2-441c-8c8c-71466251a162
2009-02-16Support multiple VNC clients (Brian Kress)aliguori
Change structure associated with a display from VncState to a new structure VncDisplay. Remove client specific fields from VncDisplay. Remove display specific fields from VncState. Maintain a linked list of VncStates per VncDisplay structure, update as necessary. When updates/resizes/copies come in from the hardware, dispatch to all clients. Signed-off-by: Brian Kress <kressb@moose.net> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6621 c046a42c-6fe2-441c-8c8c-71466251a162
2009-02-02Split VNC defines to vnc.h (Alexander Graf)aliguori
The VNC protocol contains quite some constants, some of which are currently hardcoded in the vnc.c code. This is not exactly pretty. Let's move all those constants out to vnc.h, so they are clearly separated. While at it, I also included other defines that will be used later in this patch series. Signed-off-by: Alexander Graf <agraf@suse.de> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6493 c046a42c-6fe2-441c-8c8c-71466251a162