Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 24 2月, 2011 4 次提交
  3. 09 12月, 2010 1 次提交
  5. 27 7月, 2010 6 次提交
  7. 02 6月, 2010 8 次提交
  9. 25 5月, 2010 1 次提交
  11. 04 5月, 2010 1 次提交
  13. 10 4月, 2010 1 次提交
  15. 20 3月, 2010 1 次提交
  17. 18 3月, 2010 1 次提交
  19. 09 3月, 2010 1 次提交
    • G
      kbd keds: vnc · 7ffb82ca
      由 Gerd 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: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      7ffb82ca
  21. 11 2月, 2010 2 次提交
  23. 20 1月, 2010 1 次提交
    • L
      VNC: Cache client info at connection time · 4a80dba3
      由 Luiz 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: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      4a80dba3
  25. 02 10月, 2009 2 次提交
  27. 11 8月, 2009 3 次提交
  29. 20 3月, 2009 2 次提交
    • A
      vnc: throttle screen updates. (Gerd Hoffmann) · c522d0e2
      由 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: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>


git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6862 c046a42c-6fe2-441c-8c8c-71466251a162
      c522d0e2
    • A
      vnc: cleanup surface handling, fix screen corruption bug. (Gerd Hoffmann) · 6baebed7
      由 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: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>


git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6860 c046a42c-6fe2-441c-8c8c-71466251a162
      6baebed7
  31. 07 3月, 2009 4 次提交
    • A
      Support ACLs for controlling VNC access ("Daniel P. Berrange") · 76655d6d
      由 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: NDaniel P. Berrange <berrange@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>


git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6726 c046a42c-6fe2-441c-8c8c-71466251a162
      76655d6d
    • A
      Add SASL authentication support ("Daniel P. Berrange") · 2f9606b3
      由 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: NDaniel P. Berrange <berrange@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>


git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6724 c046a42c-6fe2-441c-8c8c-71466251a162
      2f9606b3
    • A
      Move TLS auth into separate file ("Daniel P. Berrange") · 5fb6c7a8
      由 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: NDaniel P. Berrange <berrange@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>


git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6723 c046a42c-6fe2-441c-8c8c-71466251a162
      5fb6c7a8
    • A
      Move VNC structs into header file ("Daniel P. Berrange") · 19a490bf
      由 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: NDaniel P. Berrange <berrange@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>


git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6722 c046a42c-6fe2-441c-8c8c-71466251a162
      19a490bf
  33. 16 2月, 2009 1 次提交