Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

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

切换分支/标签
  1. 03 6月, 2016 1 次提交
  3. 23 2月, 2016 1 次提交
  5. 18 12月, 2015 3 次提交
  7. 20 10月, 2015 1 次提交
  9. 15 9月, 2015 2 次提交
    • D
      ui: convert VNC server to use QCryptoTLSSession · 3e305e4a
      由 Daniel 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: NDaniel P. Berrange <berrange@redhat.com>
      3e305e4a
    • D
      ui: fix return type for VNC I/O functions to be ssize_t · fdd1ab6a
      由 Daniel 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: NDaniel P. Berrange <berrange@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
      fdd1ab6a
  11. 08 7月, 2015 1 次提交
  13. 01 4月, 2015 1 次提交
    • D
      CVE-2015-1779: incrementally decode websocket frames · a2bebfd6
      由 Daniel 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: NDaniel 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: NGerd Hoffmann <kraxel@redhat.com>
      a2bebfd6
  15. 18 3月, 2015 3 次提交
    • D
      ui: remove separate gnutls_session for websockets server · 7b45a00d
      由 Daniel 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: NDaniel P. Berrange <berrange@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      7b45a00d
    • D
      ui: fix setup of VNC websockets auth scheme with TLS · f9148c8a
      由 Daniel 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: NDaniel P. Berrange <berrange@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      f9148c8a
    • D
      ui: report error if user requests VNC option that is unsupported · d169f04b
      由 Daniel 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: NDaniel P. Berrange <berrange@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      d169f04b
  17. 12 3月, 2015 1 次提交
  19. 22 1月, 2015 2 次提交
    • G
      vnc: track & limit connections · e5f34cdd
      由 Gerd 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: NGerd Hoffmann <kraxel@redhat.com>
      e5f34cdd
    • G
      vnc: remove vnc_display global · d616ccc5
      由 Gerd 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: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NGonglei <arei.gonglei@huawei.com>
      d616ccc5
  21. 25 7月, 2014 1 次提交
    • G
      vnc update fix · 63658280
      由 Gerd 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: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NPeter Lieven <pl@kamp.de>
      63658280
  23. 01 7月, 2014 1 次提交
    • P
      ui/vnc: fix potential memory corruption issues · bea60dd7
      由 Peter 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: NPeter Lieven <pl@kamp.de>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      bea60dd7
  25. 23 6月, 2014 1 次提交
  27. 10 3月, 2014 2 次提交
  29. 05 3月, 2014 1 次提交
  31. 04 5月, 2013 1 次提交
    • T
      TLS support for VNC Websockets · 0057a0d5
      由 Tim 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: NTim Hardeck <thardeck@suse.de>
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Message-id: 1366727581-5772-1-git-send-email-thardeck@suse.de
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      0057a0d5
  33. 29 4月, 2013 1 次提交
  35. 16 4月, 2013 1 次提交
    • G
      console: gui timer fixes · 0f7b2864
      由 Gerd 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: NGerd Hoffmann <kraxel@redhat.com>
      0f7b2864
  37. 18 3月, 2013 2 次提交
  39. 22 1月, 2013 3 次提交
  41. 19 12月, 2012 3 次提交
  43. 02 11月, 2012 1 次提交
  45. 01 11月, 2012 1 次提交
    • G
      pixman/vnc: use pixman images in vnc. · 9f64916d
      由 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: NGerd Hoffmann <kraxel@redhat.com>
      9f64916d
  47. 28 6月, 2012 1 次提交
  49. 15 3月, 2012 1 次提交
    • C
      vnc: don't mess up with iohandlers in the vnc thread · 175b2a6e
      由 Corentin 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: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      175b2a6e
  51. 10 2月, 2012 1 次提交
    • G
      vnc: implement shared flag handling. · 8cf36489
      由 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: NGerd Hoffmann <kraxel@redhat.com>
      8cf36489
  53. 24 7月, 2011 1 次提交
    • D
      Store VNC auth scheme per-client as well as per-server · 7e7e2ebc
      由 Daniel 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: NAnthony Liguori <aliguori@us.ibm.com>
      7e7e2ebc
  55. 11 3月, 2011 1 次提交
    • S
      vnc: Fix stack corruption and other bitmap related bugs · 23bfe28f
      由 Stefan Weil 提交于 
      Commit bc2429b9 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: NStefan Weil <weil@mail.berlios.de>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      23bfe28f