Skip to content
Snippets Groups Projects
Select Git revision
  • feature/libtcg-rebase default protected
1 result
Search by author
  • Any Author
  • Anton Anton anjo
1 author
  1. Dec 21, 2021
  3. Jul 14, 2021
    • Daniel P. Berrangé's avatar
      crypto: replace 'des-rfb' cipher with 'des' · 83bee4b5
      Daniel P. Berrangé authored 
      
Currently the crypto layer exposes support for a 'des-rfb'
algorithm which is just normal single-DES, with the bits
in each key byte reversed. This special key munging is
required by the RFB protocol password authentication
mechanism.

Since the crypto layer is generic shared code, it makes
more sense to do the key byte munging in the VNC server
code, and expose normal single-DES support.

Replacing cipher 'des-rfb' by 'des' looks like an incompatible
interface change, but it doesn't matter.  While the QMP schema
allows any QCryptoCipherAlgorithm for the 'cipher-alg' field
in QCryptoBlockCreateOptionsLUKS, the code restricts what can
be used at runtime. Thus the only effect is a change in error
message.

Original behaviour:

 $ qemu-img create -f luks --object secret,id=sec0,data=123 -o cipher-alg=des-rfb,key-secret=sec0 demo.luks 1G
 Formatting 'demo.luks', fmt=luks size=1073741824 key-secret=sec0 cipher-alg=des-rfb
 qemu-img: demo.luks: Algorithm 'des-rfb' not supported

New behaviour:

 $ qemu-img create -f luks --object secret,id=sec0,data=123 -o cipher-alg=des-rfb,key-secret=sec0 demo.luks 1G
 Formatting 'demo.luks', fmt=luks size=1073741824 key-secret=sec0 cipher-alg=des-fish
 qemu-img: demo.luks: Invalid parameter 'des-rfb'

Reviewed-by: default avatarMarkus Armbruster <armbru@redhat.com>
Reviewed-by: default avatarEric Blake <eblake@redhat.com>
Signed-off-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
      83bee4b5
  5. Jun 29, 2021
  7. Jun 15, 2021
  9. May 21, 2021
  11. Mar 23, 2021
  13. Mar 18, 2021
  15. Mar 15, 2021
    • Daniel P. Berrangé's avatar
      ui: honour the actual guest display dimensions without rounding · 69cc8db4
      Daniel P. Berrangé authored 
      
A long time ago the VNC server code had some memory corruption
fixes done in:

  commit bea60dd7
  Author: Peter Lieven <pl@kamp.de>
  Date:   Mon Jun 30 10:57:51 2014 +0200

    ui/vnc: fix potential memory corruption issues

One of the implications of the fix was that the VNC server would have a
thin black bad down the right hand side if the guest desktop width was
not a multiple of 16. In practice this was a non-issue since the VNC
server was always honouring a guest specified resolution and guests
essentially always pick from a small set of sane resolutions likely in
real world hardware.

We recently introduced support for the extended desktop resize extension
and as a result the VNC client has ability to specify an arbitrary
desktop size and the guest OS may well honour it exactly. As a result we
no longer have any guarantee that the width will be a multiple of 16,
and so when resizing the desktop we have a 93% chance of getting the
black bar on the right hand size.

The VNC server maintains three different desktop dimensions

 1. The guest surface
 2. The server surface
 3. The client desktop

The requirement for the width to be a multiple of 16 only applies to
item 2, the server surface, for the purpose of doing dirty bitmap
tracking.

Normally we will set the client desktop size to always match the server
surface size, but that's not a strict requirement. In order to cope with
clients that don't support the desktop size encoding, we already allow
for the client desktop to be a different size that the server surface.

Thus we can trivially eliminate the black bar, but setting the client
desktop size to be the un-rounded server surface size - the so called
"true width".

Signed-off-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: default avatarMarc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20210311182957.486939-5-berrange@redhat.com>
Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      69cc8db4
    • Daniel P. Berrangé's avatar
      ui: use client width/height in WMVi message · 3d3a528d
      Daniel P. Berrangé authored 
      
The WMVi message is supposed to provide the same width/height
information as the regular desktop resize and extended desktop
resize messages. There can be times where the client width and
height are different from the pixman surface dimensions.

Signed-off-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: default avatarMarc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20210311182957.486939-4-berrange@redhat.com>
Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      3d3a528d
    • Daniel P. Berrangé's avatar
      ui: add more trace points for VNC client/server messages · adc8fce8
      Daniel P. Berrangé authored 
      
This adds trace points for desktop size and audio related messages.

Signed-off-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: default avatarMarc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20210311182957.486939-2-berrange@redhat.com>
Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      adc8fce8
    • Daniel P. Berrangé's avatar
      ui: introduce "password-secret" option for VNC servers · 6c6840e9
      Daniel P. Berrangé authored 
      
Currently when using VNC the "password" flag turns on password based
authentication. The actual password has to be provided separately via
the monitor.

This introduces a "password-secret" option which lets the password be
provided up front.

  $QEMU --object secret,id=vncsec0,file=passwd.txt \
        --vnc localhost:0,password-secret=vncsec0

Signed-off-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
Message-Id: <20210311114343.439820-2-berrange@redhat.com>
Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      6c6840e9
  17. Mar 04, 2021
    • Akihiko Odaki's avatar
      ui/console: Pass placeholder surface to displays · c821a58e
      Akihiko Odaki authored 
      
ui/console used to accept NULL as graphic console surface, but its
semantics was inconsistent among displays:
- cocoa and gtk-egl perform NULL dereference.
- egl-headless, spice and spice-egl do nothing.
- gtk releases underlying resources.
- sdl2-2d and sdl2-gl destroys the window.
- vnc shows a message, "Display output is not active."

Fortunately, only virtio-gpu and virtio-gpu-3d assign NULL so
we can study them to figure out the desired behavior. They assign
NULL *except* for the primary display when the device is realized,
reset, or its scanout is disabled. This effectively destroys
windows for the (uninitialized) secondary displays.

To implement the consistent behavior of display device
realization/reset, this change embeds it to the operation
switching the surface. When NULL was given as a new surface when
switching, ui/console will instead passes a placeholder down
to each display listeners.

sdl destroys the window for a secondary console if its surface is a
placeholder. The other displays simply shows the placeholder.

Signed-off-by: default avatarAkihiko Odaki <akihiko.odaki@gmail.com>
Message-Id: <20210225101316.83940-2-akihiko.odaki@gmail.com>
Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      c821a58e
    • Akihiko Odaki's avatar
      ui/console: Add placeholder flag to message surface · b5a087b0
      Akihiko Odaki authored 
      
The surfaces created with former qemu_create_message_surface
did not display the content from the guest and always contained
simple messages describing the reason.

A display backend may want to hide the window showing such a
surface. This change renames the function to
qemu_create_placeholder_surface, and adds "placeholder" flag; the
display can check the flag to decide to do anything special like
hiding the window.

Signed-off-by: default avatarAkihiko Odaki <akihiko.odaki@gmail.com>
Message-Id: <20210225101316.83940-1-akihiko.odaki@gmail.com>
Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      b5a087b0
  19. Jan 27, 2021
  21. Jan 23, 2021
  23. Jan 15, 2021
  25. Dec 19, 2020
    • Eric Blake's avatar
      qapi: Use QAPI_LIST_PREPEND() where possible · 54aa3de7
      Eric Blake authored 
      
Anywhere we create a list of just one item or by prepending items
(typically because order doesn't matter), we can use
QAPI_LIST_PREPEND().  But places where we must keep the list in order
by appending remain open-coded until later patches.

Note that as a side effect, this also performs a cleanup of two minor
issues in qga/commands-posix.c: the old code was performing
 new = g_malloc0(sizeof(*ret));
which 1) is confusing because you have to verify whether 'new' and
'ret' are variables with the same type, and 2) would conflict with C++
compilation (not an actual problem for this file, but makes
copy-and-paste harder).

Signed-off-by: default avatarEric Blake <eblake@redhat.com>
Message-Id: <20201113011340.463563-5-eblake@redhat.com>
Reviewed-by: default avatarMarkus Armbruster <armbru@redhat.com>
Acked-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
[Straightforward conflicts due to commit a8aa94b5 "qga: update
schema for guest-get-disks 'dependents' field" and commit a10b453a
"target/mips: Move mips_cpu_add_definition() from helper.c to cpu.c"
resolved.  Commit message tweaked.]
Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      54aa3de7
  27. Dec 11, 2020
  29. Nov 04, 2020
    • Ding Hui's avatar
      vnc: fix resource leak when websocket channel error · 2ddafce7
      Ding Hui authored 
      
When we connect to vnc by websocket channel, and disconnect
(maybe by some network exception) before handshake,
qemu will left CLOSE_WAIT socket and never close it

After 04d2529d ("ui: convert VNC server to use QIOChannelSocket")
and dd154c4d ("io: fix handling of EOF / error conditions in websock GSource"),
the vnc call qio_channel_add_watch only care about G_IO_IN,
but mising G_IO_HUP and G_IO_ERR.
When the websocket channel get EOF or error, it cannot callback,
because the caller ignore the event, that leads to resource leak

We need handle G_IO_HUP and G_IO_ERR event, then cleanup the channel

Fixes: 04d2529d ("ui: convert VNC server to use QIOChannelSocket")
Fixes: dd154c4d ("io: fix handling of EOF / error conditions in websock GSource")
Cc: qemu-stable@nongnu.org
Signed-off-by: default avatarDing Hui <dinghui@sangfor.com.cn>
Message-id: 20201029032241.11040-1-dinghui@sangfor.com.cn
Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      2ddafce7
  31. Jul 10, 2020
  33. Jul 02, 2020
  35. May 26, 2020
  37. Jan 21, 2020
    • Cameron Esfahani's avatar
      vnc: prioritize ZRLE compression over ZLIB · 557ba0e5
      Cameron Esfahani authored 
      
In my investigation, ZRLE always compresses better than ZLIB so
prioritize ZRLE over ZLIB, even if the client hints that ZLIB is
preferred.

zlib buffer is always reset in zrle_compress_data(), so using offset to
calculate next_out and avail_out is useless.

Signed-off-by: default avatarCameron Esfahani <dirty@apple.com>
Message-Id: <b5d129895d08a90d0a2a6183b95875bacfa998b8.1579582674.git.dirty@apple.com>
Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      557ba0e5
    • Gerd Hoffmann's avatar
      Revert "vnc: allow fall back to RAW encoding" · 0780ec7b
      Gerd Hoffmann authored 
      
This reverts commit de3f7de7.

Remove VNC optimization to reencode framebuffer update as raw if it's
smaller than the default encoding.

QEMU's implementation was naive and didn't account for the ZLIB z_stream
mutating with each compression.  Because of the mutation, simply
resetting the output buffer's offset wasn't sufficient to "rewind" the
operation.  The mutated z_stream would generate future zlib blocks which
referred to symbols in past blocks which weren't sent.  This would lead
to artifacting.

Considering that ZRLE is never larger than raw and even though ZLIB can
occasionally be fractionally larger than raw, the overhead of
implementing this optimization correctly isn't worth it.

Signed-off-by: default avatarCameron Esfahani <dirty@apple.com>
Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      0780ec7b
  39. Dec 18, 2019
  41. Sep 17, 2019
    • Li Qiang's avatar
      vnc: fix memory leak when vnc disconnect · 6bf21f3d
      Li Qiang authored 
      
Currently when qemu receives a vnc connect, it creates a 'VncState' to
represent this connection. In 'vnc_worker_thread_loop' it creates a
local 'VncState'. The connection 'VcnState' and local 'VncState' exchange
data in 'vnc_async_encoding_start' and 'vnc_async_encoding_end'.
In 'zrle_compress_data' it calls 'deflateInit2' to allocate the libz library
opaque data. The 'VncState' used in 'zrle_compress_data' is the local
'VncState'. In 'vnc_zrle_clear' it calls 'deflateEnd' to free the libz
library opaque data. The 'VncState' used in 'vnc_zrle_clear' is the connection
'VncState'. In currently implementation there will be a memory leak when the
vnc disconnect. Following is the asan output backtrack:

Direct leak of 29760 byte(s) in 5 object(s) allocated from:
    0 0xffffa67ef3c3 in __interceptor_calloc (/lib64/libasan.so.4+0xd33c3)
    1 0xffffa65071cb in g_malloc0 (/lib64/libglib-2.0.so.0+0x571cb)
    2 0xffffa5e968f7 in deflateInit2_ (/lib64/libz.so.1+0x78f7)
    3 0xaaaacec58613 in zrle_compress_data ui/vnc-enc-zrle.c:87
    4 0xaaaacec58613 in zrle_send_framebuffer_update ui/vnc-enc-zrle.c:344
    5 0xaaaacec34e77 in vnc_send_framebuffer_update ui/vnc.c:919
    6 0xaaaacec5e023 in vnc_worker_thread_loop ui/vnc-jobs.c:271
    7 0xaaaacec5e5e7 in vnc_worker_thread ui/vnc-jobs.c:340
    8 0xaaaacee4d3c3 in qemu_thread_start util/qemu-thread-posix.c:502
    9 0xffffa544e8bb in start_thread (/lib64/libpthread.so.0+0x78bb)
    10 0xffffa53965cb in thread_start (/lib64/libc.so.6+0xd55cb)

This is because the opaque allocated in 'deflateInit2' is not freed in
'deflateEnd'. The reason is that the 'deflateEnd' calls 'deflateStateCheck'
and in the latter will check whether 's->strm != strm'(libz's data structure).
This check will be true so in 'deflateEnd' it just return 'Z_STREAM_ERROR' and
not free the data allocated in 'deflateInit2'.

The reason this happens is that the 'VncState' contains the whole 'VncZrle',
so when calling 'deflateInit2', the 's->strm' will be the local address.
So 's->strm != strm' will be true.

To fix this issue, we need to make 'zrle' of 'VncState' to be a pointer.
Then the connection 'VncState' and local 'VncState' exchange mechanism will
work as expection. The 'tight' of 'VncState' has the same issue, let's also turn
it to a pointer.

Reported-by: default avatarYing Fang <fangying1@huawei.com>
Signed-off-by: default avatarLi Qiang <liq3ea@163.com>
Message-id: 20190831153922.121308-1-liq3ea@163.com
Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      6bf21f3d
    • Gerd Hoffmann's avatar
      vnc: fix websocket field in events · e1b3d477
      Gerd Hoffmann authored 
      Just need to fill VncClientInfo.websocket in vnc_client_cache_addr().

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1748175


Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
Message-id: 20190904055250.22421-1-kraxel@redhat.com
      e1b3d477
  43. Sep 03, 2019
  45. Aug 21, 2019