2006-05-01 12:38:19 +02:00
|
|
|
/*
|
|
|
|
* QEMU VNC display driver
|
2007-09-16 23:08:06 +02:00
|
|
|
*
|
2006-05-01 12:38:19 +02:00
|
|
|
* Copyright (C) 2006 Anthony Liguori <anthony@codemonkey.ws>
|
|
|
|
* Copyright (C) 2006 Fabrice Bellard
|
2009-03-06 21:27:13 +01:00
|
|
|
* Copyright (C) 2009 Red Hat, Inc
|
2007-09-16 23:08:06 +02:00
|
|
|
*
|
2006-05-01 12:38:19 +02:00
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
* of this software and associated documentation files (the "Software"), to deal
|
|
|
|
* in the Software without restriction, including without limitation the rights
|
|
|
|
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
|
|
* copies of the Software, and to permit persons to whom the Software is
|
|
|
|
* furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice shall be included in
|
|
|
|
* all copies or substantial portions of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
|
|
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
|
|
|
* THE SOFTWARE.
|
|
|
|
*/
|
|
|
|
|
2016-01-29 18:49:51 +01:00
|
|
|
#include "qemu/osdep.h"
|
2009-03-06 21:27:13 +01:00
|
|
|
#include "vnc.h"
|
2010-07-07 20:58:02 +02:00
|
|
|
#include "vnc-jobs.h"
|
2014-05-21 13:18:20 +02:00
|
|
|
#include "trace.h"
|
2019-08-12 07:23:37 +02:00
|
|
|
#include "hw/qdev-core.h"
|
2012-12-17 18:20:04 +01:00
|
|
|
#include "sysemu/sysemu.h"
|
2020-12-11 17:08:25 +01:00
|
|
|
#include "sysemu/runstate.h"
|
2015-03-17 18:29:20 +01:00
|
|
|
#include "qemu/error-report.h"
|
Include qemu/main-loop.h less
In my "build everything" tree, changing qemu/main-loop.h triggers a
recompile of some 5600 out of 6600 objects (not counting tests and
objects that don't depend on qemu/osdep.h). It includes block/aio.h,
which in turn includes qemu/event_notifier.h, qemu/notify.h,
qemu/processor.h, qemu/qsp.h, qemu/queue.h, qemu/thread-posix.h,
qemu/thread.h, qemu/timer.h, and a few more.
Include qemu/main-loop.h only where it's needed. Touching it now
recompiles only some 1700 objects. For block/aio.h and
qemu/event_notifier.h, these numbers drop from 5600 to 2800. For the
others, they shrink only slightly.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20190812052359.30071-21-armbru@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-08-12 07:23:50 +02:00
|
|
|
#include "qemu/main-loop.h"
|
2019-05-23 16:35:07 +02:00
|
|
|
#include "qemu/module.h"
|
2018-02-01 12:18:46 +01:00
|
|
|
#include "qemu/option.h"
|
2012-12-17 18:20:00 +01:00
|
|
|
#include "qemu/sockets.h"
|
|
|
|
#include "qemu/timer.h"
|
2016-02-18 19:40:24 +01:00
|
|
|
#include "authz/list.h"
|
2014-09-16 12:33:03 +02:00
|
|
|
#include "qemu/config-file.h"
|
2019-02-14 16:22:38 +01:00
|
|
|
#include "qapi/qapi-emit-events.h"
|
|
|
|
#include "qapi/qapi-events-ui.h"
|
2018-02-01 12:18:31 +01:00
|
|
|
#include "qapi/error.h"
|
2018-02-11 10:36:01 +01:00
|
|
|
#include "qapi/qapi-commands-ui.h"
|
2013-12-02 14:27:18 +01:00
|
|
|
#include "ui/input.h"
|
2015-07-01 19:10:36 +02:00
|
|
|
#include "crypto/hash.h"
|
2021-06-28 18:09:13 +02:00
|
|
|
#include "crypto/tlscreds.h"
|
ui: convert VNC server to use QCryptoTLSSession
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-08-06 15:39:32 +02:00
|
|
|
#include "crypto/tlscredsanon.h"
|
|
|
|
#include "crypto/tlscredsx509.h"
|
2019-03-14 23:37:43 +01:00
|
|
|
#include "crypto/random.h"
|
2021-03-11 12:43:41 +01:00
|
|
|
#include "crypto/secret_common.h"
|
ui: convert VNC server to use QCryptoTLSSession
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-08-06 15:39:32 +02:00
|
|
|
#include "qom/object_interfaces.h"
|
2016-03-20 18:16:19 +01:00
|
|
|
#include "qemu/cutils.h"
|
2021-01-20 15:42:35 +01:00
|
|
|
#include "qemu/help_option.h"
|
2017-02-03 13:06:47 +01:00
|
|
|
#include "io/dns-resolver.h"
|
2022-04-20 15:26:13 +02:00
|
|
|
#include "monitor/monitor.h"
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2013-03-14 11:56:16 +01:00
|
|
|
#define VNC_REFRESH_INTERVAL_BASE GUI_REFRESH_INTERVAL_DEFAULT
|
2009-08-03 11:56:01 +02:00
|
|
|
#define VNC_REFRESH_INTERVAL_INC 50
|
2013-03-14 11:56:16 +01:00
|
|
|
#define VNC_REFRESH_INTERVAL_MAX GUI_REFRESH_INTERVAL_IDLE
|
2011-02-04 09:05:55 +01:00
|
|
|
static const struct timeval VNC_REFRESH_STATS = { 0, 500000 };
|
|
|
|
static const struct timeval VNC_REFRESH_LOSSY = { 2, 0 };
|
2006-04-30 23:28:36 +02:00
|
|
|
|
|
|
|
#include "vnc_keysym.h"
|
2015-07-01 19:10:38 +02:00
|
|
|
#include "crypto/cipher.h"
|
2007-08-25 03:37:05 +02:00
|
|
|
|
2014-07-29 12:14:08 +02:00
|
|
|
static QTAILQ_HEAD(, VncDisplay) vnc_displays =
|
|
|
|
QTAILQ_HEAD_INITIALIZER(vnc_displays);
|
2007-02-05 21:20:30 +01:00
|
|
|
|
2010-05-21 11:54:34 +02:00
|
|
|
static int vnc_cursor_define(VncState *vs);
|
ui: fix VNC client throttling when audio capture is active
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check must be disabled if audio capture is
enabled, because when streaming audio the output buffer offset will rarely be
zero due to queued audio data, and so this would starve framebuffer updates.
As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then enable audio capture, and simply never
read data back from the server. This can easily make QEMU's VNC server send
buffer consume 100MB of RAM per second, until the OOM killer starts reaping
processes (hopefully the rogue QEMU process, but it might pick others...).
To address this we make the throttling more intelligent, so we can throttle
when audio capture is active too. To determine how to throttle incremental
updates or audio data, we calculate a size threshold. Normally the threshold is
the approximate number of bytes associated with a single complete framebuffer
update. ie width * height * bytes per pixel. We'll send incremental updates
until we hit this threshold, at which point we'll stop sending updates until
data has been written to the wire, causing the output buffer offset to fall
back below the threshold.
If audio capture is enabled, we increase the size of the threshold to also
allow for upto 1 seconds worth of audio data samples. ie nchannels * bytes
per sample * frequency. This allows the output buffer to have a mixture of
incremental framebuffer updates and audio data queued, but once the threshold
is exceeded, audio data will be dropped and incremental updates will be
throttled.
This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.
This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:
commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Oct 9 14:43:42 2017 +0100
io: monitor encoutput buffer size from websocket GSource
This new general memory usage flaw has been assigned CVE-2017-15124, and is
partially fixed by this patch.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20171218191228.31018-10-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-12-18 20:12:24 +01:00
|
|
|
static void vnc_update_throttle_offset(VncState *vs);
|
2010-05-21 11:54:34 +02:00
|
|
|
|
2011-11-24 18:10:49 +01:00
|
|
|
static void vnc_set_share_mode(VncState *vs, VncShareMode mode)
|
|
|
|
{
|
|
|
|
#ifdef _VNC_DEBUG
|
|
|
|
static const char *mn[] = {
|
|
|
|
[0] = "undefined",
|
|
|
|
[VNC_SHARE_MODE_CONNECTING] = "connecting",
|
|
|
|
[VNC_SHARE_MODE_SHARED] = "shared",
|
|
|
|
[VNC_SHARE_MODE_EXCLUSIVE] = "exclusive",
|
|
|
|
[VNC_SHARE_MODE_DISCONNECTED] = "disconnected",
|
|
|
|
};
|
2015-02-27 17:20:57 +01:00
|
|
|
fprintf(stderr, "%s/%p: %s -> %s\n", __func__,
|
|
|
|
vs->ioc, mn[vs->share_mode], mn[mode]);
|
2011-11-24 18:10:49 +01:00
|
|
|
#endif
|
|
|
|
|
2014-10-02 12:09:34 +02:00
|
|
|
switch (vs->share_mode) {
|
|
|
|
case VNC_SHARE_MODE_CONNECTING:
|
|
|
|
vs->vd->num_connecting--;
|
|
|
|
break;
|
|
|
|
case VNC_SHARE_MODE_SHARED:
|
|
|
|
vs->vd->num_shared--;
|
|
|
|
break;
|
|
|
|
case VNC_SHARE_MODE_EXCLUSIVE:
|
2011-11-24 18:10:49 +01:00
|
|
|
vs->vd->num_exclusive--;
|
2014-10-02 12:09:34 +02:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
2011-11-24 18:10:49 +01:00
|
|
|
}
|
2014-10-02 12:09:34 +02:00
|
|
|
|
2011-11-24 18:10:49 +01:00
|
|
|
vs->share_mode = mode;
|
2014-10-02 12:09:34 +02:00
|
|
|
|
|
|
|
switch (vs->share_mode) {
|
|
|
|
case VNC_SHARE_MODE_CONNECTING:
|
|
|
|
vs->vd->num_connecting++;
|
|
|
|
break;
|
|
|
|
case VNC_SHARE_MODE_SHARED:
|
|
|
|
vs->vd->num_shared++;
|
|
|
|
break;
|
|
|
|
case VNC_SHARE_MODE_EXCLUSIVE:
|
2011-11-24 18:10:49 +01:00
|
|
|
vs->vd->num_exclusive++;
|
2014-10-02 12:09:34 +02:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
2011-11-24 18:10:49 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-03-06 21:27:05 +01:00
|
|
|
|
2017-04-26 09:36:41 +02:00
|
|
|
static void vnc_init_basic_info(SocketAddress *addr,
|
2015-10-26 23:34:45 +01:00
|
|
|
VncBasicInfo *info,
|
|
|
|
Error **errp)
|
2009-12-10 20:16:10 +01:00
|
|
|
{
|
2015-02-27 17:20:57 +01:00
|
|
|
switch (addr->type) {
|
2017-04-26 09:36:41 +02:00
|
|
|
case SOCKET_ADDRESS_TYPE_INET:
|
|
|
|
info->host = g_strdup(addr->u.inet.host);
|
|
|
|
info->service = g_strdup(addr->u.inet.port);
|
|
|
|
if (addr->u.inet.ipv6) {
|
2015-02-27 17:20:57 +01:00
|
|
|
info->family = NETWORK_ADDRESS_FAMILY_IPV6;
|
|
|
|
} else {
|
|
|
|
info->family = NETWORK_ADDRESS_FAMILY_IPV4;
|
|
|
|
}
|
|
|
|
break;
|
2009-12-10 20:16:10 +01:00
|
|
|
|
2017-04-26 09:36:41 +02:00
|
|
|
case SOCKET_ADDRESS_TYPE_UNIX:
|
2015-02-27 17:20:57 +01:00
|
|
|
info->host = g_strdup("");
|
2017-04-26 09:36:41 +02:00
|
|
|
info->service = g_strdup(addr->u.q_unix.path);
|
2015-02-27 17:20:57 +01:00
|
|
|
info->family = NETWORK_ADDRESS_FAMILY_UNIX;
|
|
|
|
break;
|
|
|
|
|
2017-04-26 09:36:41 +02:00
|
|
|
case SOCKET_ADDRESS_TYPE_VSOCK:
|
|
|
|
case SOCKET_ADDRESS_TYPE_FD:
|
2017-03-30 19:43:11 +02:00
|
|
|
error_setg(errp, "Unsupported socket address type %s",
|
2017-08-24 10:46:08 +02:00
|
|
|
SocketAddressType_str(addr->type));
|
2015-02-27 17:20:57 +01:00
|
|
|
break;
|
2017-03-30 19:43:11 +02:00
|
|
|
default:
|
|
|
|
abort();
|
2009-12-10 20:16:10 +01:00
|
|
|
}
|
|
|
|
|
2015-02-27 17:20:57 +01:00
|
|
|
return;
|
2009-12-10 20:16:10 +01:00
|
|
|
}
|
|
|
|
|
2015-02-27 17:20:57 +01:00
|
|
|
static void vnc_init_basic_info_from_server_addr(QIOChannelSocket *ioc,
|
|
|
|
VncBasicInfo *info,
|
2015-10-26 23:34:45 +01:00
|
|
|
Error **errp)
|
2009-12-10 20:16:10 +01:00
|
|
|
{
|
2017-04-26 09:36:41 +02:00
|
|
|
SocketAddress *addr = NULL;
|
2009-12-10 20:16:10 +01:00
|
|
|
|
vnc: don't crash getting server info if lsock is NULL
When VNC is started with '-vnc none' there will be no
listener socket present. When we try to populate the
VncServerInfo we'll crash accessing a NULL 'lsock'
field.
#0 qio_channel_socket_get_local_address (ioc=0x0, errp=errp@entry=0x7ffd5b8aa0f0) at io/channel-socket.c:33
#1 0x00007f4b9a297d6f in vnc_init_basic_info_from_server_addr (errp=0x7ffd5b8aa0f0, info=0x7f4b9d425460, ioc=<optimized out>) at ui/vnc.c:146
#2 vnc_server_info_get (vd=0x7f4b9e858000) at ui/vnc.c:223
#3 0x00007f4b9a29d318 in vnc_qmp_event (vs=0x7f4b9ef82000, vs=0x7f4b9ef82000, event=QAPI_EVENT_VNC_CONNECTED) at ui/vnc.c:279
#4 vnc_connect (vd=vd@entry=0x7f4b9e858000, sioc=sioc@entry=0x7f4b9e8b3a20, skipauth=skipauth@entry=true, websocket=websocket @entry=false) at ui/vnc.c:2994
#5 0x00007f4b9a29e8c8 in vnc_display_add_client (id=<optimized out>, csock=<optimized out>, skipauth=<optimized out>) at ui/v nc.c:3825
#6 0x00007f4b9a18d8a1 in qmp_marshal_add_client (args=<optimized out>, ret=<optimized out>, errp=0x7ffd5b8aa230) at qmp-marsh al.c:123
#7 0x00007f4b9a0b53f5 in handle_qmp_command (parser=<optimized out>, tokens=<optimized out>) at /usr/src/debug/qemu-2.6.0/mon itor.c:3922
#8 0x00007f4b9a348580 in json_message_process_token (lexer=0x7f4b9c78dfe8, input=0x7f4b9c7350e0, type=JSON_RCURLY, x=111, y=5 9) at qobject/json-streamer.c:94
#9 0x00007f4b9a35cfeb in json_lexer_feed_char (lexer=lexer@entry=0x7f4b9c78dfe8, ch=125 '}', flush=flush@entry=false) at qobj ect/json-lexer.c:310
#10 0x00007f4b9a35d0ae in json_lexer_feed (lexer=0x7f4b9c78dfe8, buffer=<optimized out>, size=<optimized out>) at qobject/json -lexer.c:360
#11 0x00007f4b9a348679 in json_message_parser_feed (parser=<optimized out>, buffer=<optimized out>, size=<optimized out>) at q object/json-streamer.c:114
#12 0x00007f4b9a0b3a1b in monitor_qmp_read (opaque=<optimized out>, buf=<optimized out>, size=<optimized out>) at /usr/src/deb ug/qemu-2.6.0/monitor.c:3938
#13 0x00007f4b9a186751 in tcp_chr_read (chan=<optimized out>, cond=<optimized out>, opaque=0x7f4b9c7add40) at qemu-char.c:2895
#14 0x00007f4b92b5c79a in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#15 0x00007f4b9a2bb0c0 in glib_pollfds_poll () at main-loop.c:213
#16 os_host_main_loop_wait (timeout=<optimized out>) at main-loop.c:258
#17 main_loop_wait (nonblocking=<optimized out>) at main-loop.c:506
#18 0x00007f4b9a0835cf in main_loop () at vl.c:1934
#19 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4667
Do an upfront check for a NULL lsock and report an error to
the caller, which matches behaviour from before
commit 04d2529da27db512dcbd5e99d0e26d333f16efcc
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Fri Feb 27 16:20:57 2015 +0000
ui: convert VNC server to use QIOChannelSocket
where getsockname() would be given a FD value -1 and thus report
an error to the caller.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1470134726-15697-2-git-send-email-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2016-08-02 12:45:24 +02:00
|
|
|
if (!ioc) {
|
|
|
|
error_setg(errp, "No listener socket available");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-02-27 17:20:57 +01:00
|
|
|
addr = qio_channel_socket_get_local_address(ioc, errp);
|
|
|
|
if (!addr) {
|
2015-10-26 23:34:45 +01:00
|
|
|
return;
|
2009-12-10 20:16:10 +01:00
|
|
|
}
|
|
|
|
|
2015-02-27 17:20:57 +01:00
|
|
|
vnc_init_basic_info(addr, info, errp);
|
2017-04-26 09:36:41 +02:00
|
|
|
qapi_free_SocketAddress(addr);
|
2009-12-10 20:16:10 +01:00
|
|
|
}
|
|
|
|
|
2015-02-27 17:20:57 +01:00
|
|
|
static void vnc_init_basic_info_from_remote_addr(QIOChannelSocket *ioc,
|
|
|
|
VncBasicInfo *info,
|
2015-10-26 23:34:45 +01:00
|
|
|
Error **errp)
|
2009-12-10 20:16:10 +01:00
|
|
|
{
|
2017-04-26 09:36:41 +02:00
|
|
|
SocketAddress *addr = NULL;
|
2009-12-10 20:16:10 +01:00
|
|
|
|
2015-02-27 17:20:57 +01:00
|
|
|
addr = qio_channel_socket_get_remote_address(ioc, errp);
|
|
|
|
if (!addr) {
|
2015-10-26 23:34:45 +01:00
|
|
|
return;
|
2009-12-10 20:16:10 +01:00
|
|
|
}
|
|
|
|
|
2015-02-27 17:20:57 +01:00
|
|
|
vnc_init_basic_info(addr, info, errp);
|
2017-04-26 09:36:41 +02:00
|
|
|
qapi_free_SocketAddress(addr);
|
2009-12-10 20:16:10 +01:00
|
|
|
}
|
|
|
|
|
2009-03-06 21:27:05 +01:00
|
|
|
static const char *vnc_auth_name(VncDisplay *vd) {
|
|
|
|
switch (vd->auth) {
|
|
|
|
case VNC_AUTH_INVALID:
|
|
|
|
return "invalid";
|
|
|
|
case VNC_AUTH_NONE:
|
|
|
|
return "none";
|
|
|
|
case VNC_AUTH_VNC:
|
|
|
|
return "vnc";
|
|
|
|
case VNC_AUTH_RA2:
|
|
|
|
return "ra2";
|
|
|
|
case VNC_AUTH_RA2NE:
|
|
|
|
return "ra2ne";
|
|
|
|
case VNC_AUTH_TIGHT:
|
|
|
|
return "tight";
|
|
|
|
case VNC_AUTH_ULTRA:
|
|
|
|
return "ultra";
|
|
|
|
case VNC_AUTH_TLS:
|
|
|
|
return "tls";
|
|
|
|
case VNC_AUTH_VENCRYPT:
|
|
|
|
switch (vd->subauth) {
|
|
|
|
case VNC_AUTH_VENCRYPT_PLAIN:
|
|
|
|
return "vencrypt+plain";
|
|
|
|
case VNC_AUTH_VENCRYPT_TLSNONE:
|
|
|
|
return "vencrypt+tls+none";
|
|
|
|
case VNC_AUTH_VENCRYPT_TLSVNC:
|
|
|
|
return "vencrypt+tls+vnc";
|
|
|
|
case VNC_AUTH_VENCRYPT_TLSPLAIN:
|
|
|
|
return "vencrypt+tls+plain";
|
|
|
|
case VNC_AUTH_VENCRYPT_X509NONE:
|
|
|
|
return "vencrypt+x509+none";
|
|
|
|
case VNC_AUTH_VENCRYPT_X509VNC:
|
|
|
|
return "vencrypt+x509+vnc";
|
|
|
|
case VNC_AUTH_VENCRYPT_X509PLAIN:
|
|
|
|
return "vencrypt+x509+plain";
|
2009-03-06 21:27:40 +01:00
|
|
|
case VNC_AUTH_VENCRYPT_TLSSASL:
|
|
|
|
return "vencrypt+tls+sasl";
|
|
|
|
case VNC_AUTH_VENCRYPT_X509SASL:
|
|
|
|
return "vencrypt+x509+sasl";
|
2009-03-06 21:27:05 +01:00
|
|
|
default:
|
|
|
|
return "vencrypt";
|
|
|
|
}
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
case VNC_AUTH_SASL:
|
2009-03-06 21:27:40 +01:00
|
|
|
return "sasl";
|
2009-03-06 21:27:05 +01:00
|
|
|
}
|
|
|
|
return "unknown";
|
|
|
|
}
|
|
|
|
|
2014-07-29 12:14:08 +02:00
|
|
|
static VncServerInfo *vnc_server_info_get(VncDisplay *vd)
|
2010-01-14 17:50:53 +01:00
|
|
|
{
|
2014-06-18 08:43:49 +02:00
|
|
|
VncServerInfo *info;
|
2015-10-26 23:34:45 +01:00
|
|
|
Error *err = NULL;
|
2010-01-14 17:50:53 +01:00
|
|
|
|
2018-02-01 17:45:14 +01:00
|
|
|
if (!vd->listener || !vd->listener->nsioc) {
|
2017-02-03 13:06:44 +01:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
vnc: fix crash when vnc_server_info_get has an error
The vnc_server_info_get will allocate the VncServerInfo
struct and then call vnc_init_basic_info_from_server_addr
to populate the basic fields. If this returns an error
though, the qapi_free_VncServerInfo call will then crash
because the VncServerInfo struct instance was not properly
NULL-initialized and thus contains random stack garbage.
#0 0x00007f1987c8e6f5 in raise () at /lib64/libc.so.6
#1 0x00007f1987c902fa in abort () at /lib64/libc.so.6
#2 0x00007f1987ccf600 in __libc_message () at /lib64/libc.so.6
#3 0x00007f1987cd7d4a in _int_free () at /lib64/libc.so.6
#4 0x00007f1987cdb2ac in free () at /lib64/libc.so.6
#5 0x00007f198b654f6e in g_free () at /lib64/libglib-2.0.so.0
#6 0x0000559193cdcf54 in visit_type_str (v=v@entry=
0x5591972f14b0, name=name@entry=0x559193de1e29 "host", obj=obj@entry=0x5591961dbfa0, errp=errp@entry=0x7fffd7899d80)
at qapi/qapi-visit-core.c:255
#7 0x0000559193cca8f3 in visit_type_VncBasicInfo_members (v=v@entry=
0x5591972f14b0, obj=obj@entry=0x5591961dbfa0, errp=errp@entry=0x7fffd7899dc0) at qapi-visit.c:12307
#8 0x0000559193ccb523 in visit_type_VncServerInfo_members (v=v@entry=
0x5591972f14b0, obj=0x5591961dbfa0, errp=errp@entry=0x7fffd7899e00) at qapi-visit.c:12632
#9 0x0000559193ccb60b in visit_type_VncServerInfo (v=v@entry=
0x5591972f14b0, name=name@entry=0x0, obj=obj@entry=0x7fffd7899e48, errp=errp@entry=0x0) at qapi-visit.c:12658
#10 0x0000559193cb53d8 in qapi_free_VncServerInfo (obj=<optimized out>) at qapi-types.c:3970
#11 0x0000559193c1e6ba in vnc_server_info_get (vd=0x7f1951498010) at ui/vnc.c:233
#12 0x0000559193c24275 in vnc_connect (vs=0x559197b2f200, vs=0x559197b2f200, event=QAPI_EVENT_VNC_CONNECTED) at ui/vnc.c:284
#13 0x0000559193c24275 in vnc_connect (vd=vd@entry=0x7f1951498010, sioc=sioc@entry=0x559196bf9c00, skipauth=skipauth@entry=tru e, websocket=websocket@entry=false) at ui/vnc.c:3039
#14 0x0000559193c25806 in vnc_display_add_client (id=<optimized out>, csock=<optimized out>, skipauth=<optimized out>)
at ui/vnc.c:3877
#15 0x0000559193a90c28 in qmp_marshal_add_client (args=<optimized out>, ret=<optimized out>, errp=0x7fffd7899f90)
at qmp-marshal.c:105
#16 0x000055919399c2b7 in handle_qmp_command (parser=<optimized out>, tokens=<optimized out>)
at /home/berrange/src/virt/qemu/monitor.c:3971
#17 0x0000559193ce3307 in json_message_process_token (lexer=0x559194ab0838, input=0x559194a6d940, type=JSON_RCURLY, x=111, y=1 2) at qobject/json-streamer.c:105
#18 0x0000559193cfa90d in json_lexer_feed_char (lexer=lexer@entry=0x559194ab0838, ch=125 '}', flush=flush@entry=false)
at qobject/json-lexer.c:319
#19 0x0000559193cfaa1e in json_lexer_feed (lexer=0x559194ab0838, buffer=<optimized out>, size=<optimized out>)
at qobject/json-lexer.c:369
#20 0x0000559193ce33c9 in json_message_parser_feed (parser=<optimized out>, buffer=<optimized out>, size=<optimized out>)
at qobject/json-streamer.c:124
#21 0x000055919399a85b in monitor_qmp_read (opaque=<optimized out>, buf=<optimized out>, size=<optimized out>)
at /home/berrange/src/virt/qemu/monitor.c:3987
#22 0x0000559193a87d00 in tcp_chr_read (chan=<optimized out>, cond=<optimized out>, opaque=0x559194a7d900)
at qemu-char.c:2895
#23 0x00007f198b64f703 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#24 0x0000559193c484b3 in main_loop_wait () at main-loop.c:213
#25 0x0000559193c484b3 in main_loop_wait (timeout=<optimized out>) at main-loop.c:258
#26 0x0000559193c484b3 in main_loop_wait (nonblocking=<optimized out>) at main-loop.c:506
#27 0x0000559193964c55 in main () at vl.c:1908
#28 0x0000559193964c55 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4603
This was introduced in
commit 98481bfcd661daa3c160cc87a297b0e60a307788
Author: Eric Blake <eblake@redhat.com>
Date: Mon Oct 26 16:34:45 2015 -0600
vnc: Hoist allocation of VncBasicInfo to callers
which added error reporting for vnc_init_basic_info_from_server_addr
but didn't change the g_malloc calls to g_malloc0.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1470134726-15697-3-git-send-email-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2016-08-02 12:45:25 +02:00
|
|
|
info = g_malloc0(sizeof(*info));
|
2018-02-01 17:45:14 +01:00
|
|
|
vnc_init_basic_info_from_server_addr(vd->listener->sioc[0],
|
qapi: Unbox base members
Rather than storing a base class as a pointer to a box, just
store the fields of that base class in the same order, so that
a child struct can be directly cast to its parent. This gives
less malloc overhead, less pointer dereferencing, and even less
generated code. Compare to the earlier commit 1e6c1616a "qapi:
Generate a nicer struct for flat unions" (although that patch
had fewer places to change, as less of qemu was directly using
qapi structs for flat unions). It also allows us to turn on
automatic type-safe wrappers for upcasting to the base class
of a struct.
Changes to the generated code look like this in qapi-types.h:
| struct SpiceChannel {
|- SpiceBasicInfo *base;
|+ /* Members inherited from SpiceBasicInfo: */
|+ char *host;
|+ char *port;
|+ NetworkAddressFamily family;
|+ /* Own members: */
| int64_t connection_id;
as well as additional upcast functions like qapi_SpiceChannel_base().
Meanwhile, changes to qapi-visit.c look like:
| static void visit_type_SpiceChannel_fields(Visitor *v, SpiceChannel **obj, Error **errp)
| {
| Error *err = NULL;
|
|- visit_type_implicit_SpiceBasicInfo(v, &(*obj)->base, &err);
|+ visit_type_SpiceBasicInfo_fields(v, (SpiceBasicInfo **)obj, &err);
| if (err) {
(the cast is necessary, since our upcast wrappers only deal with a
single pointer, not pointer-to-pointer); plus the wholesale
elimination of some now-unused visit_type_implicit_FOO() functions.
Without boxing, the corner case of one empty struct having
another empty struct as its base type now requires inserting a
dummy member (previously, the 'Base *base' member sufficed).
And now that we no longer consume a 'base' member in the generated
C struct, we can delete the former negative struct-base-clash-base
test.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1445898903-12082-11-git-send-email-eblake@redhat.com>
[Commit message tweaked slightly]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-10-26 23:34:49 +01:00
|
|
|
qapi_VncServerInfo_base(info), &err);
|
2014-07-29 12:14:08 +02:00
|
|
|
info->auth = g_strdup(vnc_auth_name(vd));
|
2015-10-26 23:34:45 +01:00
|
|
|
if (err) {
|
|
|
|
qapi_free_VncServerInfo(info);
|
|
|
|
info = NULL;
|
|
|
|
error_free(err);
|
|
|
|
}
|
2014-06-18 08:43:49 +02:00
|
|
|
return info;
|
2010-01-14 17:50:53 +01:00
|
|
|
}
|
|
|
|
|
2010-01-14 17:50:56 +01:00
|
|
|
static void vnc_client_cache_auth(VncState *client)
|
2009-03-06 21:27:05 +01:00
|
|
|
{
|
2010-01-14 17:50:56 +01:00
|
|
|
if (!client->info) {
|
|
|
|
return;
|
2009-12-10 20:16:10 +01:00
|
|
|
}
|
Include auth credentials in 'info vnc' ("Daniel P. Berrange")
This patch extends the 'info vnc' monitor output to include information
about the VNC client authentication credentials.
For clients authenticated using SASL, this will output the username.
For clients authenticated using x509 certificates, this will output
the x509 distinguished name.
Auth can be stacked, so both username & x509 dname may be shown.
Server:
address: 0.0.0.0:5902
auth: vencrypt+x509+sasl
Client:
address: 10.33.6.67:38621
x509 dname: C=GB,O=ACME,L=London,ST=London,CN=localhost
username: admin
Client:
address: 10.33.6.63:38620
x509 dname: C=GB,O=ACME,L=London,ST=London,CN=localhost
username: admin
vnc-tls.c | 17 +++++++++++++++++
vnc-tls.h | 3 +++
vnc.c | 19 +++++++++++++++++--
3 files changed, 37 insertions(+), 2 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@6725 c046a42c-6fe2-441c-8c8c-71466251a162
2009-03-06 21:27:32 +01:00
|
|
|
|
ui: convert VNC server to use QCryptoTLSSession
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-08-06 15:39:32 +02:00
|
|
|
if (client->tls) {
|
|
|
|
client->info->x509_dname =
|
|
|
|
qcrypto_tls_session_get_peer_name(client->tls);
|
2009-12-10 20:16:10 +01:00
|
|
|
}
|
Include auth credentials in 'info vnc' ("Daniel P. Berrange")
This patch extends the 'info vnc' monitor output to include information
about the VNC client authentication credentials.
For clients authenticated using SASL, this will output the username.
For clients authenticated using x509 certificates, this will output
the x509 distinguished name.
Auth can be stacked, so both username & x509 dname may be shown.
Server:
address: 0.0.0.0:5902
auth: vencrypt+x509+sasl
Client:
address: 10.33.6.67:38621
x509 dname: C=GB,O=ACME,L=London,ST=London,CN=localhost
username: admin
Client:
address: 10.33.6.63:38620
x509 dname: C=GB,O=ACME,L=London,ST=London,CN=localhost
username: admin
vnc-tls.c | 17 +++++++++++++++++
vnc-tls.h | 3 +++
vnc.c | 19 +++++++++++++++++--
3 files changed, 37 insertions(+), 2 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@6725 c046a42c-6fe2-441c-8c8c-71466251a162
2009-03-06 21:27:32 +01:00
|
|
|
#ifdef CONFIG_VNC_SASL
|
|
|
|
if (client->sasl.conn &&
|
2009-12-10 20:16:10 +01:00
|
|
|
client->sasl.username) {
|
2014-06-18 08:43:49 +02:00
|
|
|
client->info->sasl_username = g_strdup(client->sasl.username);
|
2009-12-10 20:16:10 +01:00
|
|
|
}
|
Include auth credentials in 'info vnc' ("Daniel P. Berrange")
This patch extends the 'info vnc' monitor output to include information
about the VNC client authentication credentials.
For clients authenticated using SASL, this will output the username.
For clients authenticated using x509 certificates, this will output
the x509 distinguished name.
Auth can be stacked, so both username & x509 dname may be shown.
Server:
address: 0.0.0.0:5902
auth: vencrypt+x509+sasl
Client:
address: 10.33.6.67:38621
x509 dname: C=GB,O=ACME,L=London,ST=London,CN=localhost
username: admin
Client:
address: 10.33.6.63:38620
x509 dname: C=GB,O=ACME,L=London,ST=London,CN=localhost
username: admin
vnc-tls.c | 17 +++++++++++++++++
vnc-tls.h | 3 +++
vnc.c | 19 +++++++++++++++++--
3 files changed, 37 insertions(+), 2 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@6725 c046a42c-6fe2-441c-8c8c-71466251a162
2009-03-06 21:27:32 +01:00
|
|
|
#endif
|
2010-01-14 17:50:56 +01:00
|
|
|
}
|
2009-12-10 20:16:10 +01:00
|
|
|
|
2010-01-14 17:50:56 +01:00
|
|
|
static void vnc_client_cache_addr(VncState *client)
|
|
|
|
{
|
2015-10-26 23:34:45 +01:00
|
|
|
Error *err = NULL;
|
|
|
|
|
|
|
|
client->info = g_malloc0(sizeof(*client->info));
|
2015-02-27 17:20:57 +01:00
|
|
|
vnc_init_basic_info_from_remote_addr(client->sioc,
|
qapi: Unbox base members
Rather than storing a base class as a pointer to a box, just
store the fields of that base class in the same order, so that
a child struct can be directly cast to its parent. This gives
less malloc overhead, less pointer dereferencing, and even less
generated code. Compare to the earlier commit 1e6c1616a "qapi:
Generate a nicer struct for flat unions" (although that patch
had fewer places to change, as less of qemu was directly using
qapi structs for flat unions). It also allows us to turn on
automatic type-safe wrappers for upcasting to the base class
of a struct.
Changes to the generated code look like this in qapi-types.h:
| struct SpiceChannel {
|- SpiceBasicInfo *base;
|+ /* Members inherited from SpiceBasicInfo: */
|+ char *host;
|+ char *port;
|+ NetworkAddressFamily family;
|+ /* Own members: */
| int64_t connection_id;
as well as additional upcast functions like qapi_SpiceChannel_base().
Meanwhile, changes to qapi-visit.c look like:
| static void visit_type_SpiceChannel_fields(Visitor *v, SpiceChannel **obj, Error **errp)
| {
| Error *err = NULL;
|
|- visit_type_implicit_SpiceBasicInfo(v, &(*obj)->base, &err);
|+ visit_type_SpiceBasicInfo_fields(v, (SpiceBasicInfo **)obj, &err);
| if (err) {
(the cast is necessary, since our upcast wrappers only deal with a
single pointer, not pointer-to-pointer); plus the wholesale
elimination of some now-unused visit_type_implicit_FOO() functions.
Without boxing, the corner case of one empty struct having
another empty struct as its base type now requires inserting a
dummy member (previously, the 'Base *base' member sufficed).
And now that we no longer consume a 'base' member in the generated
C struct, we can delete the former negative struct-base-clash-base
test.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1445898903-12082-11-git-send-email-eblake@redhat.com>
[Commit message tweaked slightly]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-10-26 23:34:49 +01:00
|
|
|
qapi_VncClientInfo_base(client->info),
|
2015-10-26 23:34:45 +01:00
|
|
|
&err);
|
2019-09-04 07:52:50 +02:00
|
|
|
client->info->websocket = client->websocket;
|
2015-10-26 23:34:45 +01:00
|
|
|
if (err) {
|
|
|
|
qapi_free_VncClientInfo(client->info);
|
|
|
|
client->info = NULL;
|
|
|
|
error_free(err);
|
2010-01-14 17:50:56 +01:00
|
|
|
}
|
2009-03-06 21:27:05 +01:00
|
|
|
}
|
|
|
|
|
2014-06-18 08:43:49 +02:00
|
|
|
static void vnc_qmp_event(VncState *vs, QAPIEvent event)
|
QMP: Introduce VNC_CONNECTED event
It's emitted when a VNC client connects to QEMU, client's information
such as port and IP address are provided.
Note that this event is emitted right when the connection is
established. This means that it happens before authentication
procedure and session initialization.
Event example:
{ "event": "VNC_CONNECTED",
"timestamp": { "seconds": 1262976601, "microseconds": 975795 },
"data": {
"server": { "auth": "sasl", "family": "ipv4",
"service": "5901", "host": "0.0.0.0" },
"client": { "family": "ipv4", "service": "58425",
"host": "127.0.0.1" } } }
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-01-14 17:50:57 +01:00
|
|
|
{
|
2014-06-18 08:43:49 +02:00
|
|
|
VncServerInfo *si;
|
QMP: Introduce VNC_CONNECTED event
It's emitted when a VNC client connects to QEMU, client's information
such as port and IP address are provided.
Note that this event is emitted right when the connection is
established. This means that it happens before authentication
procedure and session initialization.
Event example:
{ "event": "VNC_CONNECTED",
"timestamp": { "seconds": 1262976601, "microseconds": 975795 },
"data": {
"server": { "auth": "sasl", "family": "ipv4",
"service": "5901", "host": "0.0.0.0" },
"client": { "family": "ipv4", "service": "58425",
"host": "127.0.0.1" } } }
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-01-14 17:50:57 +01:00
|
|
|
|
|
|
|
if (!vs->info) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-07-29 12:14:08 +02:00
|
|
|
si = vnc_server_info_get(vs->vd);
|
2014-06-18 08:43:49 +02:00
|
|
|
if (!si) {
|
QMP: Introduce VNC_CONNECTED event
It's emitted when a VNC client connects to QEMU, client's information
such as port and IP address are provided.
Note that this event is emitted right when the connection is
established. This means that it happens before authentication
procedure and session initialization.
Event example:
{ "event": "VNC_CONNECTED",
"timestamp": { "seconds": 1262976601, "microseconds": 975795 },
"data": {
"server": { "auth": "sasl", "family": "ipv4",
"service": "5901", "host": "0.0.0.0" },
"client": { "family": "ipv4", "service": "58425",
"host": "127.0.0.1" } } }
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-01-14 17:50:57 +01:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-06-18 08:43:49 +02:00
|
|
|
switch (event) {
|
|
|
|
case QAPI_EVENT_VNC_CONNECTED:
|
2018-08-15 15:37:37 +02:00
|
|
|
qapi_event_send_vnc_connected(si, qapi_VncClientInfo_base(vs->info));
|
2014-06-18 08:43:49 +02:00
|
|
|
break;
|
|
|
|
case QAPI_EVENT_VNC_INITIALIZED:
|
2018-08-15 15:37:37 +02:00
|
|
|
qapi_event_send_vnc_initialized(si, vs->info);
|
2014-06-18 08:43:49 +02:00
|
|
|
break;
|
|
|
|
case QAPI_EVENT_VNC_DISCONNECTED:
|
2018-08-15 15:37:37 +02:00
|
|
|
qapi_event_send_vnc_disconnected(si, vs->info);
|
2014-06-18 08:43:49 +02:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
QMP: Introduce VNC_CONNECTED event
It's emitted when a VNC client connects to QEMU, client's information
such as port and IP address are provided.
Note that this event is emitted right when the connection is
established. This means that it happens before authentication
procedure and session initialization.
Event example:
{ "event": "VNC_CONNECTED",
"timestamp": { "seconds": 1262976601, "microseconds": 975795 },
"data": {
"server": { "auth": "sasl", "family": "ipv4",
"service": "5901", "host": "0.0.0.0" },
"client": { "family": "ipv4", "service": "58425",
"host": "127.0.0.1" } } }
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-01-14 17:50:57 +01:00
|
|
|
|
2014-06-18 08:43:49 +02:00
|
|
|
qapi_free_VncServerInfo(si);
|
QMP: Introduce VNC_CONNECTED event
It's emitted when a VNC client connects to QEMU, client's information
such as port and IP address are provided.
Note that this event is emitted right when the connection is
established. This means that it happens before authentication
procedure and session initialization.
Event example:
{ "event": "VNC_CONNECTED",
"timestamp": { "seconds": 1262976601, "microseconds": 975795 },
"data": {
"server": { "auth": "sasl", "family": "ipv4",
"service": "5901", "host": "0.0.0.0" },
"client": { "family": "ipv4", "service": "58425",
"host": "127.0.0.1" } } }
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-01-14 17:50:57 +01:00
|
|
|
}
|
|
|
|
|
2011-10-17 20:41:22 +02:00
|
|
|
static VncClientInfo *qmp_query_vnc_client(const VncState *client)
|
2007-02-05 21:20:30 +01:00
|
|
|
{
|
2011-10-17 20:41:22 +02:00
|
|
|
VncClientInfo *info;
|
2015-02-27 17:20:57 +01:00
|
|
|
Error *err = NULL;
|
2011-10-17 20:41:22 +02:00
|
|
|
|
2015-02-27 17:20:57 +01:00
|
|
|
info = g_malloc0(sizeof(*info));
|
2011-10-17 20:41:22 +02:00
|
|
|
|
2015-02-27 17:20:57 +01:00
|
|
|
vnc_init_basic_info_from_remote_addr(client->sioc,
|
|
|
|
qapi_VncClientInfo_base(info),
|
|
|
|
&err);
|
|
|
|
if (err) {
|
|
|
|
error_free(err);
|
|
|
|
qapi_free_VncClientInfo(info);
|
2011-10-17 20:41:22 +02:00
|
|
|
return NULL;
|
|
|
|
}
|
2009-12-10 20:16:10 +01:00
|
|
|
|
qapi: Unbox base members
Rather than storing a base class as a pointer to a box, just
store the fields of that base class in the same order, so that
a child struct can be directly cast to its parent. This gives
less malloc overhead, less pointer dereferencing, and even less
generated code. Compare to the earlier commit 1e6c1616a "qapi:
Generate a nicer struct for flat unions" (although that patch
had fewer places to change, as less of qemu was directly using
qapi structs for flat unions). It also allows us to turn on
automatic type-safe wrappers for upcasting to the base class
of a struct.
Changes to the generated code look like this in qapi-types.h:
| struct SpiceChannel {
|- SpiceBasicInfo *base;
|+ /* Members inherited from SpiceBasicInfo: */
|+ char *host;
|+ char *port;
|+ NetworkAddressFamily family;
|+ /* Own members: */
| int64_t connection_id;
as well as additional upcast functions like qapi_SpiceChannel_base().
Meanwhile, changes to qapi-visit.c look like:
| static void visit_type_SpiceChannel_fields(Visitor *v, SpiceChannel **obj, Error **errp)
| {
| Error *err = NULL;
|
|- visit_type_implicit_SpiceBasicInfo(v, &(*obj)->base, &err);
|+ visit_type_SpiceBasicInfo_fields(v, (SpiceBasicInfo **)obj, &err);
| if (err) {
(the cast is necessary, since our upcast wrappers only deal with a
single pointer, not pointer-to-pointer); plus the wholesale
elimination of some now-unused visit_type_implicit_FOO() functions.
Without boxing, the corner case of one empty struct having
another empty struct as its base type now requires inserting a
dummy member (previously, the 'Base *base' member sufficed).
And now that we no longer consume a 'base' member in the generated
C struct, we can delete the former negative struct-base-clash-base
test.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1445898903-12082-11-git-send-email-eblake@redhat.com>
[Commit message tweaked slightly]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-10-26 23:34:49 +01:00
|
|
|
info->websocket = client->websocket;
|
2009-12-10 20:16:10 +01:00
|
|
|
|
ui: convert VNC server to use QCryptoTLSSession
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-08-06 15:39:32 +02:00
|
|
|
if (client->tls) {
|
|
|
|
info->x509_dname = qcrypto_tls_session_get_peer_name(client->tls);
|
2011-10-17 20:41:22 +02:00
|
|
|
}
|
2009-12-10 20:16:10 +01:00
|
|
|
#ifdef CONFIG_VNC_SASL
|
2011-10-17 20:41:22 +02:00
|
|
|
if (client->sasl.conn && client->sasl.username) {
|
|
|
|
info->sasl_username = g_strdup(client->sasl.username);
|
2009-12-10 20:16:10 +01:00
|
|
|
}
|
2011-10-17 20:41:22 +02:00
|
|
|
#endif
|
2009-03-06 21:27:05 +01:00
|
|
|
|
2011-10-17 20:41:22 +02:00
|
|
|
return info;
|
2009-12-10 20:16:10 +01:00
|
|
|
}
|
2009-03-06 21:27:05 +01:00
|
|
|
|
2014-07-29 12:14:08 +02:00
|
|
|
static VncDisplay *vnc_display_find(const char *id)
|
|
|
|
{
|
|
|
|
VncDisplay *vd;
|
|
|
|
|
|
|
|
if (id == NULL) {
|
|
|
|
return QTAILQ_FIRST(&vnc_displays);
|
|
|
|
}
|
|
|
|
QTAILQ_FOREACH(vd, &vnc_displays, next) {
|
|
|
|
if (strcmp(id, vd->id) == 0) {
|
|
|
|
return vd;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2014-12-09 15:27:39 +01:00
|
|
|
static VncClientInfoList *qmp_query_client_list(VncDisplay *vd)
|
|
|
|
{
|
2020-11-13 02:13:37 +01:00
|
|
|
VncClientInfoList *prev = NULL;
|
2014-12-09 15:27:39 +01:00
|
|
|
VncState *client;
|
|
|
|
|
|
|
|
QTAILQ_FOREACH(client, &vd->clients, next) {
|
2020-11-13 02:13:37 +01:00
|
|
|
QAPI_LIST_PREPEND(prev, qmp_query_vnc_client(client));
|
2014-12-09 15:27:39 +01:00
|
|
|
}
|
|
|
|
return prev;
|
|
|
|
}
|
|
|
|
|
2011-10-17 20:41:22 +02:00
|
|
|
VncInfo *qmp_query_vnc(Error **errp)
|
2009-12-10 20:16:10 +01:00
|
|
|
{
|
2011-10-17 20:41:22 +02:00
|
|
|
VncInfo *info = g_malloc0(sizeof(*info));
|
2014-07-29 12:14:08 +02:00
|
|
|
VncDisplay *vd = vnc_display_find(NULL);
|
2017-04-26 09:36:41 +02:00
|
|
|
SocketAddress *addr = NULL;
|
2011-10-17 20:41:22 +02:00
|
|
|
|
2018-02-01 17:45:14 +01:00
|
|
|
if (vd == NULL || !vd->listener || !vd->listener->nsioc) {
|
2011-10-17 20:41:22 +02:00
|
|
|
info->enabled = false;
|
2009-12-10 20:16:10 +01:00
|
|
|
} else {
|
2011-10-17 20:41:22 +02:00
|
|
|
info->enabled = true;
|
|
|
|
|
|
|
|
/* for compatibility with the original command */
|
|
|
|
info->has_clients = true;
|
2014-12-09 15:27:39 +01:00
|
|
|
info->clients = qmp_query_client_list(vd);
|
2009-12-10 20:16:10 +01:00
|
|
|
|
2018-02-01 17:45:14 +01:00
|
|
|
addr = qio_channel_socket_get_local_address(vd->listener->sioc[0],
|
|
|
|
errp);
|
2015-02-27 17:20:57 +01:00
|
|
|
if (!addr) {
|
2011-10-17 20:41:22 +02:00
|
|
|
goto out_error;
|
|
|
|
}
|
2009-12-10 20:16:10 +01:00
|
|
|
|
2015-02-27 17:20:57 +01:00
|
|
|
switch (addr->type) {
|
2017-04-26 09:36:41 +02:00
|
|
|
case SOCKET_ADDRESS_TYPE_INET:
|
|
|
|
info->host = g_strdup(addr->u.inet.host);
|
|
|
|
info->service = g_strdup(addr->u.inet.port);
|
|
|
|
if (addr->u.inet.ipv6) {
|
2015-02-27 17:20:57 +01:00
|
|
|
info->family = NETWORK_ADDRESS_FAMILY_IPV6;
|
|
|
|
} else {
|
|
|
|
info->family = NETWORK_ADDRESS_FAMILY_IPV4;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
2017-04-26 09:36:41 +02:00
|
|
|
case SOCKET_ADDRESS_TYPE_UNIX:
|
2015-02-27 17:20:57 +01:00
|
|
|
info->host = g_strdup("");
|
2017-04-26 09:36:41 +02:00
|
|
|
info->service = g_strdup(addr->u.q_unix.path);
|
2015-02-27 17:20:57 +01:00
|
|
|
info->family = NETWORK_ADDRESS_FAMILY_UNIX;
|
|
|
|
break;
|
|
|
|
|
2017-04-26 09:36:41 +02:00
|
|
|
case SOCKET_ADDRESS_TYPE_VSOCK:
|
|
|
|
case SOCKET_ADDRESS_TYPE_FD:
|
2017-03-30 19:43:11 +02:00
|
|
|
error_setg(errp, "Unsupported socket address type %s",
|
2017-08-24 10:46:08 +02:00
|
|
|
SocketAddressType_str(addr->type));
|
2011-10-17 20:41:22 +02:00
|
|
|
goto out_error;
|
2017-03-30 19:43:11 +02:00
|
|
|
default:
|
|
|
|
abort();
|
2009-03-06 21:27:05 +01:00
|
|
|
}
|
2011-10-17 20:41:22 +02:00
|
|
|
|
|
|
|
info->has_family = true;
|
|
|
|
|
2014-07-29 12:14:08 +02:00
|
|
|
info->auth = g_strdup(vnc_auth_name(vd));
|
2007-02-05 21:20:30 +01:00
|
|
|
}
|
2011-10-17 20:41:22 +02:00
|
|
|
|
2017-04-26 09:36:41 +02:00
|
|
|
qapi_free_SocketAddress(addr);
|
2011-10-17 20:41:22 +02:00
|
|
|
return info;
|
|
|
|
|
|
|
|
out_error:
|
2017-04-26 09:36:41 +02:00
|
|
|
qapi_free_SocketAddress(addr);
|
2011-10-17 20:41:22 +02:00
|
|
|
qapi_free_VncInfo(info);
|
|
|
|
return NULL;
|
2007-02-05 21:20:30 +01:00
|
|
|
}
|
|
|
|
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
|
|
|
|
static void qmp_query_auth(int auth, int subauth,
|
|
|
|
VncPrimaryAuth *qmp_auth,
|
|
|
|
VncVencryptSubAuth *qmp_vencrypt,
|
|
|
|
bool *qmp_has_vencrypt);
|
|
|
|
|
|
|
|
static VncServerInfo2List *qmp_query_server_entry(QIOChannelSocket *ioc,
|
|
|
|
bool websocket,
|
|
|
|
int auth,
|
|
|
|
int subauth,
|
|
|
|
VncServerInfo2List *prev)
|
2014-12-17 15:49:44 +01:00
|
|
|
{
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
VncServerInfo2 *info;
|
2015-02-27 17:20:57 +01:00
|
|
|
Error *err = NULL;
|
2017-04-26 09:36:41 +02:00
|
|
|
SocketAddress *addr;
|
2015-02-27 17:20:57 +01:00
|
|
|
|
2020-06-30 11:03:28 +02:00
|
|
|
addr = qio_channel_socket_get_local_address(ioc, NULL);
|
2015-02-27 17:20:57 +01:00
|
|
|
if (!addr) {
|
2014-12-17 15:49:44 +01:00
|
|
|
return prev;
|
|
|
|
}
|
|
|
|
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
info = g_new0(VncServerInfo2, 1);
|
|
|
|
vnc_init_basic_info(addr, qapi_VncServerInfo2_base(info), &err);
|
2017-04-26 09:36:41 +02:00
|
|
|
qapi_free_SocketAddress(addr);
|
2015-02-27 17:20:57 +01:00
|
|
|
if (err) {
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
qapi_free_VncServerInfo2(info);
|
2015-02-27 17:20:57 +01:00
|
|
|
error_free(err);
|
|
|
|
return prev;
|
|
|
|
}
|
2014-12-10 09:49:39 +01:00
|
|
|
info->websocket = websocket;
|
2014-12-17 15:49:44 +01:00
|
|
|
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
qmp_query_auth(auth, subauth, &info->auth,
|
|
|
|
&info->vencrypt, &info->has_vencrypt);
|
|
|
|
|
2020-11-13 02:13:37 +01:00
|
|
|
QAPI_LIST_PREPEND(prev, info);
|
|
|
|
return prev;
|
2014-12-17 15:49:44 +01:00
|
|
|
}
|
|
|
|
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
static void qmp_query_auth(int auth, int subauth,
|
|
|
|
VncPrimaryAuth *qmp_auth,
|
|
|
|
VncVencryptSubAuth *qmp_vencrypt,
|
|
|
|
bool *qmp_has_vencrypt)
|
2014-12-17 15:49:44 +01:00
|
|
|
{
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
switch (auth) {
|
2014-12-17 15:49:44 +01:00
|
|
|
case VNC_AUTH_VNC:
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
*qmp_auth = VNC_PRIMARY_AUTH_VNC;
|
2014-12-17 15:49:44 +01:00
|
|
|
break;
|
|
|
|
case VNC_AUTH_RA2:
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
*qmp_auth = VNC_PRIMARY_AUTH_RA2;
|
2014-12-17 15:49:44 +01:00
|
|
|
break;
|
|
|
|
case VNC_AUTH_RA2NE:
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
*qmp_auth = VNC_PRIMARY_AUTH_RA2NE;
|
2014-12-17 15:49:44 +01:00
|
|
|
break;
|
|
|
|
case VNC_AUTH_TIGHT:
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
*qmp_auth = VNC_PRIMARY_AUTH_TIGHT;
|
2014-12-17 15:49:44 +01:00
|
|
|
break;
|
|
|
|
case VNC_AUTH_ULTRA:
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
*qmp_auth = VNC_PRIMARY_AUTH_ULTRA;
|
2014-12-17 15:49:44 +01:00
|
|
|
break;
|
|
|
|
case VNC_AUTH_TLS:
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
*qmp_auth = VNC_PRIMARY_AUTH_TLS;
|
2014-12-17 15:49:44 +01:00
|
|
|
break;
|
|
|
|
case VNC_AUTH_VENCRYPT:
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
*qmp_auth = VNC_PRIMARY_AUTH_VENCRYPT;
|
|
|
|
*qmp_has_vencrypt = true;
|
|
|
|
switch (subauth) {
|
2014-12-17 15:49:44 +01:00
|
|
|
case VNC_AUTH_VENCRYPT_PLAIN:
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
*qmp_vencrypt = VNC_VENCRYPT_SUB_AUTH_PLAIN;
|
2014-12-17 15:49:44 +01:00
|
|
|
break;
|
|
|
|
case VNC_AUTH_VENCRYPT_TLSNONE:
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
*qmp_vencrypt = VNC_VENCRYPT_SUB_AUTH_TLS_NONE;
|
2014-12-17 15:49:44 +01:00
|
|
|
break;
|
|
|
|
case VNC_AUTH_VENCRYPT_TLSVNC:
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
*qmp_vencrypt = VNC_VENCRYPT_SUB_AUTH_TLS_VNC;
|
2014-12-17 15:49:44 +01:00
|
|
|
break;
|
|
|
|
case VNC_AUTH_VENCRYPT_TLSPLAIN:
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
*qmp_vencrypt = VNC_VENCRYPT_SUB_AUTH_TLS_PLAIN;
|
2014-12-17 15:49:44 +01:00
|
|
|
break;
|
|
|
|
case VNC_AUTH_VENCRYPT_X509NONE:
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
*qmp_vencrypt = VNC_VENCRYPT_SUB_AUTH_X509_NONE;
|
2014-12-17 15:49:44 +01:00
|
|
|
break;
|
|
|
|
case VNC_AUTH_VENCRYPT_X509VNC:
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
*qmp_vencrypt = VNC_VENCRYPT_SUB_AUTH_X509_VNC;
|
2014-12-17 15:49:44 +01:00
|
|
|
break;
|
|
|
|
case VNC_AUTH_VENCRYPT_X509PLAIN:
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
*qmp_vencrypt = VNC_VENCRYPT_SUB_AUTH_X509_PLAIN;
|
2014-12-17 15:49:44 +01:00
|
|
|
break;
|
|
|
|
case VNC_AUTH_VENCRYPT_TLSSASL:
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
*qmp_vencrypt = VNC_VENCRYPT_SUB_AUTH_TLS_SASL;
|
2014-12-17 15:49:44 +01:00
|
|
|
break;
|
|
|
|
case VNC_AUTH_VENCRYPT_X509SASL:
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
*qmp_vencrypt = VNC_VENCRYPT_SUB_AUTH_X509_SASL;
|
2014-12-17 15:49:44 +01:00
|
|
|
break;
|
|
|
|
default:
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
*qmp_has_vencrypt = false;
|
2014-12-17 15:49:44 +01:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case VNC_AUTH_SASL:
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
*qmp_auth = VNC_PRIMARY_AUTH_SASL;
|
2014-12-17 15:49:44 +01:00
|
|
|
break;
|
|
|
|
case VNC_AUTH_NONE:
|
|
|
|
default:
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
*qmp_auth = VNC_PRIMARY_AUTH_NONE;
|
2014-12-17 15:49:44 +01:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
VncInfo2List *qmp_query_vnc_servers(Error **errp)
|
|
|
|
{
|
2020-11-13 02:13:37 +01:00
|
|
|
VncInfo2List *prev = NULL;
|
2014-12-17 15:49:44 +01:00
|
|
|
VncInfo2 *info;
|
|
|
|
VncDisplay *vd;
|
|
|
|
DeviceState *dev;
|
2017-02-03 13:06:44 +01:00
|
|
|
size_t i;
|
2014-12-17 15:49:44 +01:00
|
|
|
|
|
|
|
QTAILQ_FOREACH(vd, &vnc_displays, next) {
|
|
|
|
info = g_new0(VncInfo2, 1);
|
|
|
|
info->id = g_strdup(vd->id);
|
|
|
|
info->clients = qmp_query_client_list(vd);
|
ui: fix reporting of VNC auth in query-vnc-servers
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.
(QEMU) query-vnc-servers
{
"return": [
{
"clients": [],
"id": "default",
"auth": "vencrypt",
"vencrypt": "x509-vnc",
"server": [
{
"host": "127.0.0.1"
"service": "5901",
"websocket": false,
"family": "ipv4",
"auth": "vencrypt",
"vencrypt": "x509-vnc"
},
{
"host": "127.0.0.1",
"service": "5902",
"websocket": true,
"family": "ipv4",
"auth": "vnc"
}
]
}
]
}
This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 13:06:43 +01:00
|
|
|
qmp_query_auth(vd->auth, vd->subauth, &info->auth,
|
|
|
|
&info->vencrypt, &info->has_vencrypt);
|
2014-12-17 15:49:44 +01:00
|
|
|
if (vd->dcl.con) {
|
|
|
|
dev = DEVICE(object_property_get_link(OBJECT(vd->dcl.con),
|
2020-07-07 18:05:51 +02:00
|
|
|
"device", &error_abort));
|
2014-12-17 15:49:44 +01:00
|
|
|
info->display = g_strdup(dev->id);
|
|
|
|
}
|
2018-02-01 17:45:14 +01:00
|
|
|
for (i = 0; vd->listener != NULL && i < vd->listener->nsioc; i++) {
|
2015-02-27 17:20:57 +01:00
|
|
|
info->server = qmp_query_server_entry(
|
2018-02-01 17:45:14 +01:00
|
|
|
vd->listener->sioc[i], false, vd->auth, vd->subauth,
|
|
|
|
info->server);
|
2014-12-17 15:49:44 +01:00
|
|
|
}
|
2018-02-01 17:45:14 +01:00
|
|
|
for (i = 0; vd->wslistener != NULL && i < vd->wslistener->nsioc; i++) {
|
2015-02-27 17:20:57 +01:00
|
|
|
info->server = qmp_query_server_entry(
|
2018-02-01 17:45:14 +01:00
|
|
|
vd->wslistener->sioc[i], true, vd->ws_auth,
|
2017-02-03 13:06:44 +01:00
|
|
|
vd->ws_subauth, info->server);
|
2014-12-17 15:49:44 +01:00
|
|
|
}
|
|
|
|
|
2020-11-13 02:13:37 +01:00
|
|
|
QAPI_LIST_PREPEND(prev, info);
|
2014-12-17 15:49:44 +01:00
|
|
|
}
|
|
|
|
return prev;
|
|
|
|
}
|
|
|
|
|
2021-03-16 08:58:44 +01:00
|
|
|
bool vnc_display_reload_certs(const char *id, Error **errp)
|
|
|
|
{
|
|
|
|
VncDisplay *vd = vnc_display_find(id);
|
|
|
|
QCryptoTLSCredsClass *creds = NULL;
|
|
|
|
|
|
|
|
if (!vd) {
|
|
|
|
error_setg(errp, "Can not find vnc display");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!vd->tlscreds) {
|
2021-05-08 11:25:58 +02:00
|
|
|
error_setg(errp, "vnc tls is not enabled");
|
2021-03-16 08:58:44 +01:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
creds = QCRYPTO_TLS_CREDS_GET_CLASS(OBJECT(vd->tlscreds));
|
|
|
|
if (creds->reload == NULL) {
|
|
|
|
error_setg(errp, "%s doesn't support to reload TLS credential",
|
|
|
|
object_get_typename(OBJECT(vd->tlscreds)));
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
if (!creds->reload(vd->tlscreds, errp)) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2006-04-30 23:28:36 +02:00
|
|
|
/* TODO
|
|
|
|
1) Get the queue working for IO.
|
|
|
|
2) there is some weirdness when using the -S option (the screen is grey
|
|
|
|
and not totally invalidated
|
|
|
|
3) resolutions > 1024
|
|
|
|
*/
|
|
|
|
|
2017-12-18 20:12:16 +01:00
|
|
|
static int vnc_update_client(VncState *vs, int has_dirty);
|
2009-06-16 14:19:48 +02:00
|
|
|
static void vnc_disconnect_start(VncState *vs);
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2009-02-16 15:59:30 +01:00
|
|
|
static void vnc_colordepth(VncState *vs);
|
2009-08-03 11:54:32 +02:00
|
|
|
static void framebuffer_update_request(VncState *vs, int incremental,
|
|
|
|
int x_position, int y_position,
|
|
|
|
int w, int h);
|
2013-03-14 11:56:16 +01:00
|
|
|
static void vnc_refresh(DisplayChangeListener *dcl);
|
2009-08-03 11:54:32 +02:00
|
|
|
static int vnc_refresh_server_surface(VncDisplay *vd);
|
2008-09-15 18:03:41 +02:00
|
|
|
|
2015-10-30 12:10:06 +01:00
|
|
|
static int vnc_width(VncDisplay *vd)
|
|
|
|
{
|
|
|
|
return MIN(VNC_MAX_WIDTH, ROUND_UP(surface_width(vd->ds),
|
|
|
|
VNC_DIRTY_PIXELS_PER_BIT));
|
|
|
|
}
|
|
|
|
|
2021-03-11 19:29:57 +01:00
|
|
|
static int vnc_true_width(VncDisplay *vd)
|
|
|
|
{
|
|
|
|
return MIN(VNC_MAX_WIDTH, surface_width(vd->ds));
|
|
|
|
}
|
|
|
|
|
2015-10-30 12:10:06 +01:00
|
|
|
static int vnc_height(VncDisplay *vd)
|
|
|
|
{
|
|
|
|
return MIN(VNC_MAX_HEIGHT, surface_height(vd->ds));
|
|
|
|
}
|
|
|
|
|
2014-06-30 10:57:51 +02:00
|
|
|
static void vnc_set_area_dirty(DECLARE_BITMAP(dirty[VNC_MAX_HEIGHT],
|
|
|
|
VNC_MAX_WIDTH / VNC_DIRTY_PIXELS_PER_BIT),
|
2015-10-30 12:10:08 +01:00
|
|
|
VncDisplay *vd,
|
|
|
|
int x, int y, int w, int h)
|
|
|
|
{
|
|
|
|
int width = vnc_width(vd);
|
|
|
|
int height = vnc_height(vd);
|
|
|
|
|
2014-01-08 10:08:37 +01:00
|
|
|
/* this is needed this to ensure we updated all affected
|
|
|
|
* blocks if x % VNC_DIRTY_PIXELS_PER_BIT != 0 */
|
2014-01-08 10:08:33 +01:00
|
|
|
w += (x % VNC_DIRTY_PIXELS_PER_BIT);
|
|
|
|
x -= (x % VNC_DIRTY_PIXELS_PER_BIT);
|
2007-12-11 23:31:32 +01:00
|
|
|
|
2012-10-10 13:29:43 +02:00
|
|
|
x = MIN(x, width);
|
|
|
|
y = MIN(y, height);
|
|
|
|
w = MIN(x + w, width) - x;
|
2014-01-08 10:08:37 +01:00
|
|
|
h = MIN(y + h, height);
|
2008-05-20 02:07:58 +02:00
|
|
|
|
2014-01-08 10:08:33 +01:00
|
|
|
for (; y < h; y++) {
|
2014-06-30 10:57:51 +02:00
|
|
|
bitmap_set(dirty[y], x / VNC_DIRTY_PIXELS_PER_BIT,
|
2014-01-08 10:08:37 +01:00
|
|
|
DIV_ROUND_UP(w, VNC_DIRTY_PIXELS_PER_BIT));
|
2014-01-08 10:08:33 +01:00
|
|
|
}
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
|
|
|
|
2014-06-30 10:57:51 +02:00
|
|
|
static void vnc_dpy_update(DisplayChangeListener *dcl,
|
|
|
|
int x, int y, int w, int h)
|
|
|
|
{
|
|
|
|
VncDisplay *vd = container_of(dcl, VncDisplay, dcl);
|
|
|
|
struct VncSurface *s = &vd->guest;
|
|
|
|
|
2015-10-30 12:10:08 +01:00
|
|
|
vnc_set_area_dirty(s->dirty, vd, x, y, w, h);
|
2014-06-30 10:57:51 +02:00
|
|
|
}
|
|
|
|
|
2010-05-03 14:31:34 +02:00
|
|
|
void vnc_framebuffer_update(VncState *vs, int x, int y, int w, int h,
|
|
|
|
int32_t encoding)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
|
|
|
vnc_write_u16(vs, x);
|
|
|
|
vnc_write_u16(vs, y);
|
|
|
|
vnc_write_u16(vs, w);
|
|
|
|
vnc_write_u16(vs, h);
|
|
|
|
|
|
|
|
vnc_write_s32(vs, encoding);
|
|
|
|
}
|
|
|
|
|
2021-01-12 14:41:20 +01:00
|
|
|
static void vnc_desktop_resize_ext(VncState *vs, int reject_reason)
|
|
|
|
{
|
2021-03-11 19:29:54 +01:00
|
|
|
trace_vnc_msg_server_ext_desktop_resize(
|
|
|
|
vs, vs->ioc, vs->client_width, vs->client_height, reject_reason);
|
|
|
|
|
2021-01-12 14:41:20 +01:00
|
|
|
vnc_lock_output(vs);
|
|
|
|
vnc_write_u8(vs, VNC_MSG_SERVER_FRAMEBUFFER_UPDATE);
|
|
|
|
vnc_write_u8(vs, 0);
|
|
|
|
vnc_write_u16(vs, 1); /* number of rects */
|
|
|
|
vnc_framebuffer_update(vs,
|
|
|
|
reject_reason ? 1 : 0,
|
|
|
|
reject_reason,
|
|
|
|
vs->client_width, vs->client_height,
|
|
|
|
VNC_ENCODING_DESKTOP_RESIZE_EXT);
|
|
|
|
vnc_write_u8(vs, 1); /* number of screens */
|
|
|
|
vnc_write_u8(vs, 0); /* padding */
|
|
|
|
vnc_write_u8(vs, 0); /* padding */
|
|
|
|
vnc_write_u8(vs, 0); /* padding */
|
|
|
|
vnc_write_u32(vs, 0); /* screen id */
|
|
|
|
vnc_write_u16(vs, 0); /* screen x-pos */
|
|
|
|
vnc_write_u16(vs, 0); /* screen y-pos */
|
|
|
|
vnc_write_u16(vs, vs->client_width);
|
|
|
|
vnc_write_u16(vs, vs->client_height);
|
|
|
|
vnc_write_u32(vs, 0); /* screen flags */
|
|
|
|
vnc_unlock_output(vs);
|
|
|
|
vnc_flush(vs);
|
|
|
|
}
|
2013-01-21 11:04:43 +01:00
|
|
|
|
2010-05-25 18:25:16 +02:00
|
|
|
static void vnc_desktop_resize(VncState *vs)
|
|
|
|
{
|
2021-01-12 14:41:20 +01:00
|
|
|
if (vs->ioc == NULL || (!vnc_has_feature(vs, VNC_FEATURE_RESIZE) &&
|
|
|
|
!vnc_has_feature(vs, VNC_FEATURE_RESIZE_EXT))) {
|
2010-05-25 18:25:16 +02:00
|
|
|
return;
|
|
|
|
}
|
2021-03-11 19:29:57 +01:00
|
|
|
if (vs->client_width == vs->vd->true_width &&
|
2021-01-25 11:40:40 +01:00
|
|
|
vs->client_height == pixman_image_get_height(vs->vd->server)) {
|
|
|
|
return;
|
|
|
|
}
|
ui: avoid sign extension using client width/height
Pixman returns a signed int for the image width/height, but the VNC
protocol only permits a unsigned int16. Effective framebuffer size
is determined by the guest, limited by the video RAM size, so the
dimensions are unlikely to exceed the range of an unsigned int16,
but this is not currently validated.
With the current use of 'int' for client width/height, the calculation
of offsets in vnc_update_throttle_offset() suffers from integer size
promotion and sign extension, causing coverity warnings
*** CID 1385147: Integer handling issues (SIGN_EXTENSION)
/ui/vnc.c: 979 in vnc_update_throttle_offset()
973 * than that the client would already suffering awful audio
974 * glitches, so dropping samples is no worse really).
975 */
976 static void vnc_update_throttle_offset(VncState *vs)
977 {
978 size_t offset =
>>> CID 1385147: Integer handling issues (SIGN_EXTENSION)
>>> Suspicious implicit sign extension:
"vs->client_pf.bytes_per_pixel" with type "unsigned char" (8 bits,
unsigned) is promoted in "vs->client_width * vs->client_height *
vs->client_pf.bytes_per_pixel" to type "int" (32 bits, signed), then
sign-extended to type "unsigned long" (64 bits, unsigned). If
"vs->client_width * vs->client_height * vs->client_pf.bytes_per_pixel"
is greater than 0x7FFFFFFF, the upper bits of the result will all be 1.
979 vs->client_width * vs->client_height * vs->client_pf.bytes_per_pixel;
Change client_width / client_height to be a size_t to avoid sign
extension and integer promotion. Then validate that dimensions are in
range wrt the RFB protocol u16 limits.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20180118155254.17053-1-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-18 16:52:54 +01:00
|
|
|
|
2021-03-11 19:29:57 +01:00
|
|
|
assert(vs->vd->true_width < 65536 &&
|
|
|
|
vs->vd->true_width >= 0);
|
ui: avoid sign extension using client width/height
Pixman returns a signed int for the image width/height, but the VNC
protocol only permits a unsigned int16. Effective framebuffer size
is determined by the guest, limited by the video RAM size, so the
dimensions are unlikely to exceed the range of an unsigned int16,
but this is not currently validated.
With the current use of 'int' for client width/height, the calculation
of offsets in vnc_update_throttle_offset() suffers from integer size
promotion and sign extension, causing coverity warnings
*** CID 1385147: Integer handling issues (SIGN_EXTENSION)
/ui/vnc.c: 979 in vnc_update_throttle_offset()
973 * than that the client would already suffering awful audio
974 * glitches, so dropping samples is no worse really).
975 */
976 static void vnc_update_throttle_offset(VncState *vs)
977 {
978 size_t offset =
>>> CID 1385147: Integer handling issues (SIGN_EXTENSION)
>>> Suspicious implicit sign extension:
"vs->client_pf.bytes_per_pixel" with type "unsigned char" (8 bits,
unsigned) is promoted in "vs->client_width * vs->client_height *
vs->client_pf.bytes_per_pixel" to type "int" (32 bits, signed), then
sign-extended to type "unsigned long" (64 bits, unsigned). If
"vs->client_width * vs->client_height * vs->client_pf.bytes_per_pixel"
is greater than 0x7FFFFFFF, the upper bits of the result will all be 1.
979 vs->client_width * vs->client_height * vs->client_pf.bytes_per_pixel;
Change client_width / client_height to be a size_t to avoid sign
extension and integer promotion. Then validate that dimensions are in
range wrt the RFB protocol u16 limits.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20180118155254.17053-1-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-18 16:52:54 +01:00
|
|
|
assert(pixman_image_get_height(vs->vd->server) < 65536 &&
|
|
|
|
pixman_image_get_height(vs->vd->server) >= 0);
|
2021-03-11 19:29:57 +01:00
|
|
|
vs->client_width = vs->vd->true_width;
|
2014-06-30 10:57:51 +02:00
|
|
|
vs->client_height = pixman_image_get_height(vs->vd->server);
|
2021-01-12 14:41:20 +01:00
|
|
|
|
|
|
|
if (vnc_has_feature(vs, VNC_FEATURE_RESIZE_EXT)) {
|
|
|
|
vnc_desktop_resize_ext(vs, 0);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2021-03-11 19:29:54 +01:00
|
|
|
trace_vnc_msg_server_desktop_resize(
|
|
|
|
vs, vs->ioc, vs->client_width, vs->client_height);
|
|
|
|
|
2010-07-07 20:58:02 +02:00
|
|
|
vnc_lock_output(vs);
|
2010-05-25 18:25:16 +02:00
|
|
|
vnc_write_u8(vs, VNC_MSG_SERVER_FRAMEBUFFER_UPDATE);
|
|
|
|
vnc_write_u8(vs, 0);
|
|
|
|
vnc_write_u16(vs, 1); /* number of rects */
|
2010-05-25 18:25:18 +02:00
|
|
|
vnc_framebuffer_update(vs, 0, 0, vs->client_width, vs->client_height,
|
2010-05-25 18:25:16 +02:00
|
|
|
VNC_ENCODING_DESKTOPRESIZE);
|
2010-07-07 20:58:02 +02:00
|
|
|
vnc_unlock_output(vs);
|
2010-05-25 18:25:16 +02:00
|
|
|
vnc_flush(vs);
|
|
|
|
}
|
|
|
|
|
2010-07-07 20:58:02 +02:00
|
|
|
static void vnc_abort_display_jobs(VncDisplay *vd)
|
|
|
|
{
|
|
|
|
VncState *vs;
|
|
|
|
|
|
|
|
QTAILQ_FOREACH(vs, &vd->clients, next) {
|
|
|
|
vnc_lock_output(vs);
|
|
|
|
vs->abort = true;
|
|
|
|
vnc_unlock_output(vs);
|
|
|
|
}
|
|
|
|
QTAILQ_FOREACH(vs, &vd->clients, next) {
|
|
|
|
vnc_jobs_join(vs);
|
|
|
|
}
|
|
|
|
QTAILQ_FOREACH(vs, &vd->clients, next) {
|
|
|
|
vnc_lock_output(vs);
|
2019-03-05 14:09:30 +01:00
|
|
|
if (vs->update == VNC_STATE_UPDATE_NONE &&
|
|
|
|
vs->job_update != VNC_STATE_UPDATE_NONE) {
|
|
|
|
/* job aborted before completion */
|
|
|
|
vs->update = vs->job_update;
|
|
|
|
vs->job_update = VNC_STATE_UPDATE_NONE;
|
|
|
|
}
|
2010-07-07 20:58:02 +02:00
|
|
|
vs->abort = false;
|
|
|
|
vnc_unlock_output(vs);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-10-10 13:29:43 +02:00
|
|
|
int vnc_server_fb_stride(VncDisplay *vd)
|
|
|
|
{
|
|
|
|
return pixman_image_get_stride(vd->server);
|
|
|
|
}
|
|
|
|
|
|
|
|
void *vnc_server_fb_ptr(VncDisplay *vd, int x, int y)
|
|
|
|
{
|
|
|
|
uint8_t *ptr;
|
|
|
|
|
|
|
|
ptr = (uint8_t *)pixman_image_get_data(vd->server);
|
|
|
|
ptr += y * vnc_server_fb_stride(vd);
|
|
|
|
ptr += x * VNC_SERVER_FB_BYTES;
|
|
|
|
return ptr;
|
|
|
|
}
|
|
|
|
|
2015-10-30 12:10:07 +01:00
|
|
|
static void vnc_update_server_surface(VncDisplay *vd)
|
|
|
|
{
|
2016-08-16 18:30:32 +02:00
|
|
|
int width, height;
|
|
|
|
|
2015-10-30 12:10:07 +01:00
|
|
|
qemu_pixman_image_unref(vd->server);
|
|
|
|
vd->server = NULL;
|
|
|
|
|
2015-10-30 12:10:09 +01:00
|
|
|
if (QTAILQ_EMPTY(&vd->clients)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-08-16 18:30:32 +02:00
|
|
|
width = vnc_width(vd);
|
|
|
|
height = vnc_height(vd);
|
2021-03-11 19:29:57 +01:00
|
|
|
vd->true_width = vnc_true_width(vd);
|
2015-10-30 12:10:07 +01:00
|
|
|
vd->server = pixman_image_create_bits(VNC_SERVER_FB_FORMAT,
|
2016-08-16 18:30:32 +02:00
|
|
|
width, height,
|
2015-10-30 12:10:07 +01:00
|
|
|
NULL, 0);
|
2016-08-16 18:30:32 +02:00
|
|
|
|
|
|
|
memset(vd->guest.dirty, 0x00, sizeof(vd->guest.dirty));
|
|
|
|
vnc_set_area_dirty(vd->guest.dirty, vd, 0, 0,
|
|
|
|
width, height);
|
2015-10-30 12:10:07 +01:00
|
|
|
}
|
|
|
|
|
2019-01-16 11:10:49 +01:00
|
|
|
static bool vnc_check_pageflip(DisplaySurface *s1,
|
|
|
|
DisplaySurface *s2)
|
|
|
|
{
|
|
|
|
return (s1 != NULL &&
|
|
|
|
s2 != NULL &&
|
|
|
|
surface_width(s1) == surface_width(s2) &&
|
|
|
|
surface_height(s1) == surface_height(s2) &&
|
|
|
|
surface_format(s1) == surface_format(s2));
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2013-02-28 15:03:04 +01:00
|
|
|
static void vnc_dpy_switch(DisplayChangeListener *dcl,
|
|
|
|
DisplaySurface *surface)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
2013-02-28 11:34:31 +01:00
|
|
|
VncDisplay *vd = container_of(dcl, VncDisplay, dcl);
|
2019-01-16 11:10:49 +01:00
|
|
|
bool pageflip = vnc_check_pageflip(vd->ds, surface);
|
2010-02-05 12:04:05 +01:00
|
|
|
VncState *vs;
|
2009-08-03 11:54:32 +02:00
|
|
|
|
2010-07-07 20:58:02 +02:00
|
|
|
vnc_abort_display_jobs(vd);
|
2015-10-30 12:10:07 +01:00
|
|
|
vd->ds = surface;
|
2010-07-07 20:58:02 +02:00
|
|
|
|
2009-03-20 16:59:14 +01:00
|
|
|
/* guest surface */
|
2012-10-10 13:29:43 +02:00
|
|
|
qemu_pixman_image_unref(vd->guest.fb);
|
2013-02-28 17:16:48 +01:00
|
|
|
vd->guest.fb = pixman_image_ref(surface->image);
|
2023-08-30 11:38:21 +02:00
|
|
|
vd->guest.format = surface_format(surface);
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2021-03-11 19:29:57 +01:00
|
|
|
|
2019-01-16 11:10:49 +01:00
|
|
|
if (pageflip) {
|
2021-03-11 19:29:57 +01:00
|
|
|
trace_vnc_server_dpy_pageflip(vd,
|
|
|
|
surface_width(surface),
|
|
|
|
surface_height(surface),
|
|
|
|
surface_format(surface));
|
2019-01-16 11:10:49 +01:00
|
|
|
vnc_set_area_dirty(vd->guest.dirty, vd, 0, 0,
|
|
|
|
surface_width(surface),
|
|
|
|
surface_height(surface));
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2021-03-11 19:29:57 +01:00
|
|
|
trace_vnc_server_dpy_recreate(vd,
|
|
|
|
surface_width(surface),
|
|
|
|
surface_height(surface),
|
|
|
|
surface_format(surface));
|
2019-01-16 11:10:49 +01:00
|
|
|
/* server surface */
|
|
|
|
vnc_update_server_surface(vd);
|
|
|
|
|
2010-02-05 12:04:05 +01:00
|
|
|
QTAILQ_FOREACH(vs, &vd->clients, next) {
|
2009-08-03 11:54:32 +02:00
|
|
|
vnc_colordepth(vs);
|
2010-05-25 18:25:20 +02:00
|
|
|
vnc_desktop_resize(vs);
|
2021-01-12 14:41:18 +01:00
|
|
|
vnc_cursor_define(vs);
|
2014-06-30 10:57:51 +02:00
|
|
|
memset(vs->dirty, 0x00, sizeof(vs->dirty));
|
2015-10-30 12:10:08 +01:00
|
|
|
vnc_set_area_dirty(vs->dirty, vd, 0, 0,
|
2016-08-16 18:30:32 +02:00
|
|
|
vnc_width(vd),
|
|
|
|
vnc_height(vd));
|
ui: fix VNC client throttling when audio capture is active
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check must be disabled if audio capture is
enabled, because when streaming audio the output buffer offset will rarely be
zero due to queued audio data, and so this would starve framebuffer updates.
As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then enable audio capture, and simply never
read data back from the server. This can easily make QEMU's VNC server send
buffer consume 100MB of RAM per second, until the OOM killer starts reaping
processes (hopefully the rogue QEMU process, but it might pick others...).
To address this we make the throttling more intelligent, so we can throttle
when audio capture is active too. To determine how to throttle incremental
updates or audio data, we calculate a size threshold. Normally the threshold is
the approximate number of bytes associated with a single complete framebuffer
update. ie width * height * bytes per pixel. We'll send incremental updates
until we hit this threshold, at which point we'll stop sending updates until
data has been written to the wire, causing the output buffer offset to fall
back below the threshold.
If audio capture is enabled, we increase the size of the threshold to also
allow for upto 1 seconds worth of audio data samples. ie nchannels * bytes
per sample * frequency. This allows the output buffer to have a mixture of
incremental framebuffer updates and audio data queued, but once the threshold
is exceeded, audio data will be dropped and incremental updates will be
throttled.
This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.
This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:
commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Oct 9 14:43:42 2017 +0100
io: monitor encoutput buffer size from websocket GSource
This new general memory usage flaw has been assigned CVE-2017-15124, and is
partially fixed by this patch.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20171218191228.31018-10-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-12-18 20:12:24 +01:00
|
|
|
vnc_update_throttle_offset(vs);
|
2009-02-16 15:59:30 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-05-14 20:11:49 +02:00
|
|
|
/* fastest code */
|
2012-10-10 13:29:43 +02:00
|
|
|
static void vnc_write_pixels_copy(VncState *vs,
|
2010-05-21 11:54:34 +02:00
|
|
|
void *pixels, int size)
|
2006-05-14 20:11:49 +02:00
|
|
|
{
|
|
|
|
vnc_write(vs, pixels, size);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* slowest but generic code. */
|
2010-05-03 14:31:34 +02:00
|
|
|
void vnc_convert_pixel(VncState *vs, uint8_t *buf, uint32_t v)
|
2006-05-14 20:11:49 +02:00
|
|
|
{
|
2008-09-15 18:03:41 +02:00
|
|
|
uint8_t r, g, b;
|
2009-08-03 11:54:32 +02:00
|
|
|
|
2012-10-10 13:29:43 +02:00
|
|
|
#if VNC_SERVER_FB_FORMAT == PIXMAN_FORMAT(32, PIXMAN_TYPE_ARGB, 0, 8, 8, 8)
|
|
|
|
r = (((v & 0x00ff0000) >> 16) << vs->client_pf.rbits) >> 8;
|
|
|
|
g = (((v & 0x0000ff00) >> 8) << vs->client_pf.gbits) >> 8;
|
|
|
|
b = (((v & 0x000000ff) >> 0) << vs->client_pf.bbits) >> 8;
|
|
|
|
#else
|
|
|
|
# error need some bits here if you change VNC_SERVER_FB_FORMAT
|
|
|
|
#endif
|
|
|
|
v = (r << vs->client_pf.rshift) |
|
|
|
|
(g << vs->client_pf.gshift) |
|
|
|
|
(b << vs->client_pf.bshift);
|
|
|
|
switch (vs->client_pf.bytes_per_pixel) {
|
2006-05-14 20:11:49 +02:00
|
|
|
case 1:
|
|
|
|
buf[0] = v;
|
|
|
|
break;
|
|
|
|
case 2:
|
2012-10-10 13:29:43 +02:00
|
|
|
if (vs->client_be) {
|
2006-05-14 20:11:49 +02:00
|
|
|
buf[0] = v >> 8;
|
|
|
|
buf[1] = v;
|
|
|
|
} else {
|
|
|
|
buf[1] = v >> 8;
|
|
|
|
buf[0] = v;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
case 4:
|
2012-10-10 13:29:43 +02:00
|
|
|
if (vs->client_be) {
|
2006-05-14 20:11:49 +02:00
|
|
|
buf[0] = v >> 24;
|
|
|
|
buf[1] = v >> 16;
|
|
|
|
buf[2] = v >> 8;
|
|
|
|
buf[3] = v;
|
|
|
|
} else {
|
|
|
|
buf[3] = v >> 24;
|
|
|
|
buf[2] = v >> 16;
|
|
|
|
buf[1] = v >> 8;
|
|
|
|
buf[0] = v;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-10-10 13:29:43 +02:00
|
|
|
static void vnc_write_pixels_generic(VncState *vs,
|
2010-05-21 11:54:34 +02:00
|
|
|
void *pixels1, int size)
|
2006-05-14 20:11:49 +02:00
|
|
|
{
|
|
|
|
uint8_t buf[4];
|
|
|
|
|
2012-10-10 13:29:43 +02:00
|
|
|
if (VNC_SERVER_FB_BYTES == 4) {
|
2008-09-15 18:03:41 +02:00
|
|
|
uint32_t *pixels = pixels1;
|
|
|
|
int n, i;
|
|
|
|
n = size >> 2;
|
2012-10-10 13:29:43 +02:00
|
|
|
for (i = 0; i < n; i++) {
|
2008-09-15 18:03:41 +02:00
|
|
|
vnc_convert_pixel(vs, buf, pixels[i]);
|
2012-10-10 13:29:43 +02:00
|
|
|
vnc_write(vs, buf, vs->client_pf.bytes_per_pixel);
|
2008-09-15 18:03:41 +02:00
|
|
|
}
|
2006-05-14 20:11:49 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-05-19 09:24:09 +02:00
|
|
|
int vnc_raw_send_framebuffer_update(VncState *vs, int x, int y, int w, int h)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
|
|
|
int i;
|
2007-12-16 04:02:09 +01:00
|
|
|
uint8_t *row;
|
2009-08-03 11:54:32 +02:00
|
|
|
VncDisplay *vd = vs->vd;
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2012-10-10 13:29:43 +02:00
|
|
|
row = vnc_server_fb_ptr(vd, x, y);
|
2006-04-30 23:28:36 +02:00
|
|
|
for (i = 0; i < h; i++) {
|
2012-10-10 13:29:43 +02:00
|
|
|
vs->write_pixels(vs, row, w * VNC_SERVER_FB_BYTES);
|
|
|
|
row += vnc_server_fb_stride(vd);
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
2010-05-19 09:24:09 +02:00
|
|
|
return 1;
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
|
|
|
|
2010-07-07 20:58:02 +02:00
|
|
|
int vnc_send_framebuffer_update(VncState *vs, int x, int y, int w, int h)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
2010-05-19 09:24:09 +02:00
|
|
|
int n = 0;
|
|
|
|
|
2009-02-02 16:58:43 +01:00
|
|
|
switch(vs->vnc_encoding) {
|
2009-03-06 21:27:40 +01:00
|
|
|
case VNC_ENCODING_ZLIB:
|
2010-05-19 09:24:09 +02:00
|
|
|
n = vnc_zlib_send_framebuffer_update(vs, x, y, w, h);
|
2009-03-06 21:27:40 +01:00
|
|
|
break;
|
|
|
|
case VNC_ENCODING_HEXTILE:
|
|
|
|
vnc_framebuffer_update(vs, x, y, w, h, VNC_ENCODING_HEXTILE);
|
2010-05-19 09:24:09 +02:00
|
|
|
n = vnc_hextile_send_framebuffer_update(vs, x, y, w, h);
|
2009-03-06 21:27:40 +01:00
|
|
|
break;
|
2010-05-19 09:24:10 +02:00
|
|
|
case VNC_ENCODING_TIGHT:
|
|
|
|
n = vnc_tight_send_framebuffer_update(vs, x, y, w, h);
|
|
|
|
break;
|
2010-07-07 20:57:56 +02:00
|
|
|
case VNC_ENCODING_TIGHT_PNG:
|
|
|
|
n = vnc_tight_png_send_framebuffer_update(vs, x, y, w, h);
|
|
|
|
break;
|
2011-02-04 09:06:01 +01:00
|
|
|
case VNC_ENCODING_ZRLE:
|
|
|
|
n = vnc_zrle_send_framebuffer_update(vs, x, y, w, h);
|
|
|
|
break;
|
|
|
|
case VNC_ENCODING_ZYWRLE:
|
|
|
|
n = vnc_zywrle_send_framebuffer_update(vs, x, y, w, h);
|
|
|
|
break;
|
2009-03-06 21:27:40 +01:00
|
|
|
default:
|
2020-01-21 07:02:10 +01:00
|
|
|
vnc_framebuffer_update(vs, x, y, w, h, VNC_ENCODING_RAW);
|
|
|
|
n = vnc_raw_send_framebuffer_update(vs, x, y, w, h);
|
2009-03-06 21:27:40 +01:00
|
|
|
break;
|
2009-02-02 16:58:43 +01:00
|
|
|
}
|
2010-05-19 09:24:09 +02:00
|
|
|
return n;
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
|
|
|
|
2012-11-13 14:51:41 +01:00
|
|
|
static void vnc_mouse_set(DisplayChangeListener *dcl,
|
|
|
|
int x, int y, int visible)
|
2010-05-21 11:54:34 +02:00
|
|
|
{
|
|
|
|
/* can we ask the client(s) to move the pointer ??? */
|
|
|
|
}
|
|
|
|
|
|
|
|
static int vnc_cursor_define(VncState *vs)
|
|
|
|
{
|
2023-01-17 12:24:40 +01:00
|
|
|
QEMUCursor *c = qemu_console_get_cursor(vs->vd->dcl.con);
|
2010-05-21 11:54:34 +02:00
|
|
|
int isize;
|
|
|
|
|
2023-01-17 12:24:40 +01:00
|
|
|
if (!c) {
|
2021-01-12 14:41:18 +01:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2020-12-08 12:57:34 +01:00
|
|
|
if (vnc_has_feature(vs, VNC_FEATURE_ALPHA_CURSOR)) {
|
|
|
|
vnc_lock_output(vs);
|
|
|
|
vnc_write_u8(vs, VNC_MSG_SERVER_FRAMEBUFFER_UPDATE);
|
|
|
|
vnc_write_u8(vs, 0); /* padding */
|
|
|
|
vnc_write_u16(vs, 1); /* # of rects */
|
|
|
|
vnc_framebuffer_update(vs, c->hot_x, c->hot_y, c->width, c->height,
|
|
|
|
VNC_ENCODING_ALPHA_CURSOR);
|
|
|
|
vnc_write_s32(vs, VNC_ENCODING_RAW);
|
|
|
|
vnc_write(vs, c->data, c->width * c->height * 4);
|
|
|
|
vnc_unlock_output(vs);
|
|
|
|
return 0;
|
|
|
|
}
|
2010-05-21 11:54:34 +02:00
|
|
|
if (vnc_has_feature(vs, VNC_FEATURE_RICH_CURSOR)) {
|
2010-07-07 20:58:03 +02:00
|
|
|
vnc_lock_output(vs);
|
2010-05-21 11:54:34 +02:00
|
|
|
vnc_write_u8(vs, VNC_MSG_SERVER_FRAMEBUFFER_UPDATE);
|
|
|
|
vnc_write_u8(vs, 0); /* padding */
|
|
|
|
vnc_write_u16(vs, 1); /* # of rects */
|
|
|
|
vnc_framebuffer_update(vs, c->hot_x, c->hot_y, c->width, c->height,
|
|
|
|
VNC_ENCODING_RICH_CURSOR);
|
2012-10-10 13:29:43 +02:00
|
|
|
isize = c->width * c->height * vs->client_pf.bytes_per_pixel;
|
|
|
|
vnc_write_pixels_generic(vs, c->data, isize);
|
2010-05-21 11:54:34 +02:00
|
|
|
vnc_write(vs, vs->vd->cursor_mask, vs->vd->cursor_msize);
|
2010-07-07 20:58:03 +02:00
|
|
|
vnc_unlock_output(vs);
|
2010-05-21 11:54:34 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2012-11-13 14:51:41 +01:00
|
|
|
static void vnc_dpy_cursor_define(DisplayChangeListener *dcl,
|
|
|
|
QEMUCursor *c)
|
2010-05-21 11:54:34 +02:00
|
|
|
{
|
2014-07-29 12:14:08 +02:00
|
|
|
VncDisplay *vd = container_of(dcl, VncDisplay, dcl);
|
2010-05-21 11:54:34 +02:00
|
|
|
VncState *vs;
|
|
|
|
|
2011-08-21 05:09:37 +02:00
|
|
|
g_free(vd->cursor_mask);
|
2010-05-21 11:54:34 +02:00
|
|
|
vd->cursor_msize = cursor_get_mono_bpl(c) * c->height;
|
2011-08-21 05:09:37 +02:00
|
|
|
vd->cursor_mask = g_malloc0(vd->cursor_msize);
|
2010-05-21 11:54:34 +02:00
|
|
|
cursor_get_mono_mask(c, 0, vd->cursor_mask);
|
|
|
|
|
|
|
|
QTAILQ_FOREACH(vs, &vd->clients, next) {
|
|
|
|
vnc_cursor_define(vs);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-04-08 20:04:12 +02:00
|
|
|
static int find_and_clear_dirty_height(VncState *vs,
|
2011-02-04 09:06:06 +01:00
|
|
|
int y, int last_x, int x, int height)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
|
|
|
int h;
|
|
|
|
|
2011-02-04 09:06:06 +01:00
|
|
|
for (h = 1; h < (height - y); h++) {
|
2011-02-04 09:06:05 +01:00
|
|
|
if (!test_bit(last_x, vs->dirty[y + h])) {
|
2009-03-06 21:27:40 +01:00
|
|
|
break;
|
2011-02-04 09:06:05 +01:00
|
|
|
}
|
2014-01-08 10:08:36 +01:00
|
|
|
bitmap_clear(vs->dirty[y + h], last_x, x - last_x);
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return h;
|
|
|
|
}
|
|
|
|
|
ui: fix VNC client throttling when audio capture is active
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check must be disabled if audio capture is
enabled, because when streaming audio the output buffer offset will rarely be
zero due to queued audio data, and so this would starve framebuffer updates.
As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then enable audio capture, and simply never
read data back from the server. This can easily make QEMU's VNC server send
buffer consume 100MB of RAM per second, until the OOM killer starts reaping
processes (hopefully the rogue QEMU process, but it might pick others...).
To address this we make the throttling more intelligent, so we can throttle
when audio capture is active too. To determine how to throttle incremental
updates or audio data, we calculate a size threshold. Normally the threshold is
the approximate number of bytes associated with a single complete framebuffer
update. ie width * height * bytes per pixel. We'll send incremental updates
until we hit this threshold, at which point we'll stop sending updates until
data has been written to the wire, causing the output buffer offset to fall
back below the threshold.
If audio capture is enabled, we increase the size of the threshold to also
allow for upto 1 seconds worth of audio data samples. ie nchannels * bytes
per sample * frequency. This allows the output buffer to have a mixture of
incremental framebuffer updates and audio data queued, but once the threshold
is exceeded, audio data will be dropped and incremental updates will be
throttled.
This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.
This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:
commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Oct 9 14:43:42 2017 +0100
io: monitor encoutput buffer size from websocket GSource
This new general memory usage flaw has been assigned CVE-2017-15124, and is
partially fixed by this patch.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20171218191228.31018-10-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-12-18 20:12:24 +01:00
|
|
|
/*
|
|
|
|
* Figure out how much pending data we should allow in the output
|
|
|
|
* buffer before we throttle incremental display updates, and/or
|
|
|
|
* drop audio samples.
|
|
|
|
*
|
|
|
|
* We allow for equiv of 1 full display's worth of FB updates,
|
|
|
|
* and 1 second of audio samples. If audio backlog was larger
|
|
|
|
* than that the client would already suffering awful audio
|
|
|
|
* glitches, so dropping samples is no worse really).
|
|
|
|
*/
|
|
|
|
static void vnc_update_throttle_offset(VncState *vs)
|
|
|
|
{
|
|
|
|
size_t offset =
|
|
|
|
vs->client_width * vs->client_height * vs->client_pf.bytes_per_pixel;
|
|
|
|
|
|
|
|
if (vs->audio_cap) {
|
|
|
|
int bps;
|
|
|
|
switch (vs->as.fmt) {
|
|
|
|
default:
|
2019-03-08 23:34:13 +01:00
|
|
|
case AUDIO_FORMAT_U8:
|
|
|
|
case AUDIO_FORMAT_S8:
|
ui: fix VNC client throttling when audio capture is active
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check must be disabled if audio capture is
enabled, because when streaming audio the output buffer offset will rarely be
zero due to queued audio data, and so this would starve framebuffer updates.
As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then enable audio capture, and simply never
read data back from the server. This can easily make QEMU's VNC server send
buffer consume 100MB of RAM per second, until the OOM killer starts reaping
processes (hopefully the rogue QEMU process, but it might pick others...).
To address this we make the throttling more intelligent, so we can throttle
when audio capture is active too. To determine how to throttle incremental
updates or audio data, we calculate a size threshold. Normally the threshold is
the approximate number of bytes associated with a single complete framebuffer
update. ie width * height * bytes per pixel. We'll send incremental updates
until we hit this threshold, at which point we'll stop sending updates until
data has been written to the wire, causing the output buffer offset to fall
back below the threshold.
If audio capture is enabled, we increase the size of the threshold to also
allow for upto 1 seconds worth of audio data samples. ie nchannels * bytes
per sample * frequency. This allows the output buffer to have a mixture of
incremental framebuffer updates and audio data queued, but once the threshold
is exceeded, audio data will be dropped and incremental updates will be
throttled.
This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.
This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:
commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Oct 9 14:43:42 2017 +0100
io: monitor encoutput buffer size from websocket GSource
This new general memory usage flaw has been assigned CVE-2017-15124, and is
partially fixed by this patch.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20171218191228.31018-10-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-12-18 20:12:24 +01:00
|
|
|
bps = 1;
|
|
|
|
break;
|
2019-03-08 23:34:13 +01:00
|
|
|
case AUDIO_FORMAT_U16:
|
|
|
|
case AUDIO_FORMAT_S16:
|
ui: fix VNC client throttling when audio capture is active
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check must be disabled if audio capture is
enabled, because when streaming audio the output buffer offset will rarely be
zero due to queued audio data, and so this would starve framebuffer updates.
As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then enable audio capture, and simply never
read data back from the server. This can easily make QEMU's VNC server send
buffer consume 100MB of RAM per second, until the OOM killer starts reaping
processes (hopefully the rogue QEMU process, but it might pick others...).
To address this we make the throttling more intelligent, so we can throttle
when audio capture is active too. To determine how to throttle incremental
updates or audio data, we calculate a size threshold. Normally the threshold is
the approximate number of bytes associated with a single complete framebuffer
update. ie width * height * bytes per pixel. We'll send incremental updates
until we hit this threshold, at which point we'll stop sending updates until
data has been written to the wire, causing the output buffer offset to fall
back below the threshold.
If audio capture is enabled, we increase the size of the threshold to also
allow for upto 1 seconds worth of audio data samples. ie nchannels * bytes
per sample * frequency. This allows the output buffer to have a mixture of
incremental framebuffer updates and audio data queued, but once the threshold
is exceeded, audio data will be dropped and incremental updates will be
throttled.
This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.
This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:
commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Oct 9 14:43:42 2017 +0100
io: monitor encoutput buffer size from websocket GSource
This new general memory usage flaw has been assigned CVE-2017-15124, and is
partially fixed by this patch.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20171218191228.31018-10-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-12-18 20:12:24 +01:00
|
|
|
bps = 2;
|
|
|
|
break;
|
2019-03-08 23:34:13 +01:00
|
|
|
case AUDIO_FORMAT_U32:
|
|
|
|
case AUDIO_FORMAT_S32:
|
ui: fix VNC client throttling when audio capture is active
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check must be disabled if audio capture is
enabled, because when streaming audio the output buffer offset will rarely be
zero due to queued audio data, and so this would starve framebuffer updates.
As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then enable audio capture, and simply never
read data back from the server. This can easily make QEMU's VNC server send
buffer consume 100MB of RAM per second, until the OOM killer starts reaping
processes (hopefully the rogue QEMU process, but it might pick others...).
To address this we make the throttling more intelligent, so we can throttle
when audio capture is active too. To determine how to throttle incremental
updates or audio data, we calculate a size threshold. Normally the threshold is
the approximate number of bytes associated with a single complete framebuffer
update. ie width * height * bytes per pixel. We'll send incremental updates
until we hit this threshold, at which point we'll stop sending updates until
data has been written to the wire, causing the output buffer offset to fall
back below the threshold.
If audio capture is enabled, we increase the size of the threshold to also
allow for upto 1 seconds worth of audio data samples. ie nchannels * bytes
per sample * frequency. This allows the output buffer to have a mixture of
incremental framebuffer updates and audio data queued, but once the threshold
is exceeded, audio data will be dropped and incremental updates will be
throttled.
This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.
This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:
commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Oct 9 14:43:42 2017 +0100
io: monitor encoutput buffer size from websocket GSource
This new general memory usage flaw has been assigned CVE-2017-15124, and is
partially fixed by this patch.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20171218191228.31018-10-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-12-18 20:12:24 +01:00
|
|
|
bps = 4;
|
|
|
|
break;
|
|
|
|
}
|
2018-02-05 12:49:37 +01:00
|
|
|
offset += vs->as.freq * bps * vs->as.nchannels;
|
ui: fix VNC client throttling when audio capture is active
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check must be disabled if audio capture is
enabled, because when streaming audio the output buffer offset will rarely be
zero due to queued audio data, and so this would starve framebuffer updates.
As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then enable audio capture, and simply never
read data back from the server. This can easily make QEMU's VNC server send
buffer consume 100MB of RAM per second, until the OOM killer starts reaping
processes (hopefully the rogue QEMU process, but it might pick others...).
To address this we make the throttling more intelligent, so we can throttle
when audio capture is active too. To determine how to throttle incremental
updates or audio data, we calculate a size threshold. Normally the threshold is
the approximate number of bytes associated with a single complete framebuffer
update. ie width * height * bytes per pixel. We'll send incremental updates
until we hit this threshold, at which point we'll stop sending updates until
data has been written to the wire, causing the output buffer offset to fall
back below the threshold.
If audio capture is enabled, we increase the size of the threshold to also
allow for upto 1 seconds worth of audio data samples. ie nchannels * bytes
per sample * frequency. This allows the output buffer to have a mixture of
incremental framebuffer updates and audio data queued, but once the threshold
is exceeded, audio data will be dropped and incremental updates will be
throttled.
This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.
This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:
commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Oct 9 14:43:42 2017 +0100
io: monitor encoutput buffer size from websocket GSource
This new general memory usage flaw has been assigned CVE-2017-15124, and is
partially fixed by this patch.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20171218191228.31018-10-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-12-18 20:12:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Put a floor of 1MB on offset, so that if we have a large pending
|
|
|
|
* buffer and the display is resized to a small size & back again
|
|
|
|
* we don't suddenly apply a tiny send limit
|
|
|
|
*/
|
|
|
|
offset = MAX(offset, 1024 * 1024);
|
|
|
|
|
2017-12-18 20:12:27 +01:00
|
|
|
if (vs->throttle_output_offset != offset) {
|
|
|
|
trace_vnc_client_throttle_threshold(
|
|
|
|
vs, vs->ioc, vs->throttle_output_offset, offset, vs->client_width,
|
|
|
|
vs->client_height, vs->client_pf.bytes_per_pixel, vs->audio_cap);
|
|
|
|
}
|
|
|
|
|
ui: fix VNC client throttling when audio capture is active
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check must be disabled if audio capture is
enabled, because when streaming audio the output buffer offset will rarely be
zero due to queued audio data, and so this would starve framebuffer updates.
As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then enable audio capture, and simply never
read data back from the server. This can easily make QEMU's VNC server send
buffer consume 100MB of RAM per second, until the OOM killer starts reaping
processes (hopefully the rogue QEMU process, but it might pick others...).
To address this we make the throttling more intelligent, so we can throttle
when audio capture is active too. To determine how to throttle incremental
updates or audio data, we calculate a size threshold. Normally the threshold is
the approximate number of bytes associated with a single complete framebuffer
update. ie width * height * bytes per pixel. We'll send incremental updates
until we hit this threshold, at which point we'll stop sending updates until
data has been written to the wire, causing the output buffer offset to fall
back below the threshold.
If audio capture is enabled, we increase the size of the threshold to also
allow for upto 1 seconds worth of audio data samples. ie nchannels * bytes
per sample * frequency. This allows the output buffer to have a mixture of
incremental framebuffer updates and audio data queued, but once the threshold
is exceeded, audio data will be dropped and incremental updates will be
throttled.
This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.
This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:
commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Oct 9 14:43:42 2017 +0100
io: monitor encoutput buffer size from websocket GSource
This new general memory usage flaw has been assigned CVE-2017-15124, and is
partially fixed by this patch.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20171218191228.31018-10-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-12-18 20:12:24 +01:00
|
|
|
vs->throttle_output_offset = offset;
|
|
|
|
}
|
|
|
|
|
2017-12-18 20:12:23 +01:00
|
|
|
static bool vnc_should_update(VncState *vs)
|
|
|
|
{
|
|
|
|
switch (vs->update) {
|
|
|
|
case VNC_STATE_UPDATE_NONE:
|
|
|
|
break;
|
|
|
|
case VNC_STATE_UPDATE_INCREMENTAL:
|
ui: fix VNC client throttling when audio capture is active
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check must be disabled if audio capture is
enabled, because when streaming audio the output buffer offset will rarely be
zero due to queued audio data, and so this would starve framebuffer updates.
As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then enable audio capture, and simply never
read data back from the server. This can easily make QEMU's VNC server send
buffer consume 100MB of RAM per second, until the OOM killer starts reaping
processes (hopefully the rogue QEMU process, but it might pick others...).
To address this we make the throttling more intelligent, so we can throttle
when audio capture is active too. To determine how to throttle incremental
updates or audio data, we calculate a size threshold. Normally the threshold is
the approximate number of bytes associated with a single complete framebuffer
update. ie width * height * bytes per pixel. We'll send incremental updates
until we hit this threshold, at which point we'll stop sending updates until
data has been written to the wire, causing the output buffer offset to fall
back below the threshold.
If audio capture is enabled, we increase the size of the threshold to also
allow for upto 1 seconds worth of audio data samples. ie nchannels * bytes
per sample * frequency. This allows the output buffer to have a mixture of
incremental framebuffer updates and audio data queued, but once the threshold
is exceeded, audio data will be dropped and incremental updates will be
throttled.
This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.
This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:
commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Oct 9 14:43:42 2017 +0100
io: monitor encoutput buffer size from websocket GSource
This new general memory usage flaw has been assigned CVE-2017-15124, and is
partially fixed by this patch.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20171218191228.31018-10-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-12-18 20:12:24 +01:00
|
|
|
/* Only allow incremental updates if the pending send queue
|
ui: fix VNC client throttling when forced update is requested
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check is disabled if the client has requested
a forced update, because we want to send these as soon as possible.
As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then repeatedly send full framebuffer update
requests, but never read data back from the server. This can easily make QEMU's
VNC server send buffer consume 100MB of RAM per second, until the OOM killer
starts reaping processes (hopefully the rogue QEMU process, but it might pick
others...).
To address this we make the throttling more intelligent, so we can throttle
full updates. When we get a forced update request, we keep track of exactly how
much data we put on the output buffer. We will not process a subsequent forced
update request until this data has been fully sent on the wire. We always allow
one forced update request to be in flight, regardless of what data is queued
for incremental updates or audio data. The slight complication is that we do
not initially know how much data an update will send, as this is done in the
background by the VNC job thread. So we must track the fact that the job thread
has an update pending, and not process any further updates until this job is
has been completed & put data on the output buffer.
This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.
This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:
commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Oct 9 14:43:42 2017 +0100
io: monitor encoutput buffer size from websocket GSource
This new general memory usage flaw has been assigned CVE-2017-15124, and is
partially fixed by this patch.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20171218191228.31018-11-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-12-18 20:12:25 +01:00
|
|
|
* is less than the permitted threshold, and the job worker
|
|
|
|
* is completely idle.
|
2017-12-18 20:12:23 +01:00
|
|
|
*/
|
ui: fix VNC client throttling when forced update is requested
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check is disabled if the client has requested
a forced update, because we want to send these as soon as possible.
As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then repeatedly send full framebuffer update
requests, but never read data back from the server. This can easily make QEMU's
VNC server send buffer consume 100MB of RAM per second, until the OOM killer
starts reaping processes (hopefully the rogue QEMU process, but it might pick
others...).
To address this we make the throttling more intelligent, so we can throttle
full updates. When we get a forced update request, we keep track of exactly how
much data we put on the output buffer. We will not process a subsequent forced
update request until this data has been fully sent on the wire. We always allow
one forced update request to be in flight, regardless of what data is queued
for incremental updates or audio data. The slight complication is that we do
not initially know how much data an update will send, as this is done in the
background by the VNC job thread. So we must track the fact that the job thread
has an update pending, and not process any further updates until this job is
has been completed & put data on the output buffer.
This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.
This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:
commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Oct 9 14:43:42 2017 +0100
io: monitor encoutput buffer size from websocket GSource
This new general memory usage flaw has been assigned CVE-2017-15124, and is
partially fixed by this patch.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20171218191228.31018-11-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-12-18 20:12:25 +01:00
|
|
|
if (vs->output.offset < vs->throttle_output_offset &&
|
|
|
|
vs->job_update == VNC_STATE_UPDATE_NONE) {
|
2017-12-18 20:12:23 +01:00
|
|
|
return true;
|
|
|
|
}
|
2017-12-18 20:12:27 +01:00
|
|
|
trace_vnc_client_throttle_incremental(
|
|
|
|
vs, vs->ioc, vs->job_update, vs->output.offset);
|
2017-12-18 20:12:23 +01:00
|
|
|
break;
|
|
|
|
case VNC_STATE_UPDATE_FORCE:
|
ui: fix VNC client throttling when forced update is requested
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check is disabled if the client has requested
a forced update, because we want to send these as soon as possible.
As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then repeatedly send full framebuffer update
requests, but never read data back from the server. This can easily make QEMU's
VNC server send buffer consume 100MB of RAM per second, until the OOM killer
starts reaping processes (hopefully the rogue QEMU process, but it might pick
others...).
To address this we make the throttling more intelligent, so we can throttle
full updates. When we get a forced update request, we keep track of exactly how
much data we put on the output buffer. We will not process a subsequent forced
update request until this data has been fully sent on the wire. We always allow
one forced update request to be in flight, regardless of what data is queued
for incremental updates or audio data. The slight complication is that we do
not initially know how much data an update will send, as this is done in the
background by the VNC job thread. So we must track the fact that the job thread
has an update pending, and not process any further updates until this job is
has been completed & put data on the output buffer.
This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.
This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:
commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Oct 9 14:43:42 2017 +0100
io: monitor encoutput buffer size from websocket GSource
This new general memory usage flaw has been assigned CVE-2017-15124, and is
partially fixed by this patch.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20171218191228.31018-11-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-12-18 20:12:25 +01:00
|
|
|
/* Only allow forced updates if the pending send queue
|
|
|
|
* does not contain a previous forced update, and the
|
|
|
|
* job worker is completely idle.
|
|
|
|
*
|
|
|
|
* Note this means we'll queue a forced update, even if
|
|
|
|
* the output buffer size is otherwise over the throttle
|
|
|
|
* output limit.
|
|
|
|
*/
|
|
|
|
if (vs->force_update_offset == 0 &&
|
|
|
|
vs->job_update == VNC_STATE_UPDATE_NONE) {
|
|
|
|
return true;
|
|
|
|
}
|
2017-12-18 20:12:27 +01:00
|
|
|
trace_vnc_client_throttle_forced(
|
|
|
|
vs, vs->ioc, vs->job_update, vs->force_update_offset);
|
ui: fix VNC client throttling when forced update is requested
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check is disabled if the client has requested
a forced update, because we want to send these as soon as possible.
As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then repeatedly send full framebuffer update
requests, but never read data back from the server. This can easily make QEMU's
VNC server send buffer consume 100MB of RAM per second, until the OOM killer
starts reaping processes (hopefully the rogue QEMU process, but it might pick
others...).
To address this we make the throttling more intelligent, so we can throttle
full updates. When we get a forced update request, we keep track of exactly how
much data we put on the output buffer. We will not process a subsequent forced
update request until this data has been fully sent on the wire. We always allow
one forced update request to be in flight, regardless of what data is queued
for incremental updates or audio data. The slight complication is that we do
not initially know how much data an update will send, as this is done in the
background by the VNC job thread. So we must track the fact that the job thread
has an update pending, and not process any further updates until this job is
has been completed & put data on the output buffer.
This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.
This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:
commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Oct 9 14:43:42 2017 +0100
io: monitor encoutput buffer size from websocket GSource
This new general memory usage flaw has been assigned CVE-2017-15124, and is
partially fixed by this patch.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20171218191228.31018-11-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-12-18 20:12:25 +01:00
|
|
|
break;
|
2017-12-18 20:12:23 +01:00
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2017-12-18 20:12:16 +01:00
|
|
|
static int vnc_update_client(VncState *vs, int has_dirty)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
2017-12-18 20:12:18 +01:00
|
|
|
VncDisplay *vd = vs->vd;
|
|
|
|
VncJob *job;
|
|
|
|
int y;
|
|
|
|
int height, width;
|
|
|
|
int n = 0;
|
|
|
|
|
2016-07-13 12:21:20 +02:00
|
|
|
if (vs->disconnecting) {
|
|
|
|
vnc_disconnect_finish(vs);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-07-23 11:52:02 +02:00
|
|
|
vs->has_dirty += has_dirty;
|
2017-12-18 20:12:23 +01:00
|
|
|
if (!vnc_should_update(vs)) {
|
2017-12-18 20:12:18 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-12-18 20:12:21 +01:00
|
|
|
if (!vs->has_dirty && vs->update != VNC_STATE_UPDATE_FORCE) {
|
2017-12-18 20:12:18 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Send screen updates to the vnc client using the server
|
|
|
|
* surface and server dirty map. guest surface updates
|
|
|
|
* happening in parallel don't disturb us, the next pass will
|
|
|
|
* send them to the client.
|
|
|
|
*/
|
|
|
|
job = vnc_job_new(vs);
|
|
|
|
|
|
|
|
height = pixman_image_get_height(vd->server);
|
|
|
|
width = pixman_image_get_width(vd->server);
|
|
|
|
|
|
|
|
y = 0;
|
|
|
|
for (;;) {
|
|
|
|
int x, h;
|
|
|
|
unsigned long x2;
|
|
|
|
unsigned long offset = find_next_bit((unsigned long *) &vs->dirty,
|
|
|
|
height * VNC_DIRTY_BPL(vs),
|
|
|
|
y * VNC_DIRTY_BPL(vs));
|
|
|
|
if (offset == height * VNC_DIRTY_BPL(vs)) {
|
|
|
|
/* no more dirty bits */
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
y = offset / VNC_DIRTY_BPL(vs);
|
|
|
|
x = offset % VNC_DIRTY_BPL(vs);
|
|
|
|
x2 = find_next_zero_bit((unsigned long *) &vs->dirty[y],
|
|
|
|
VNC_DIRTY_BPL(vs), x);
|
|
|
|
bitmap_clear(vs->dirty[y], x, x2 - x);
|
|
|
|
h = find_and_clear_dirty_height(vs, y, x, x2, height);
|
|
|
|
x2 = MIN(x2, width / VNC_DIRTY_PIXELS_PER_BIT);
|
|
|
|
if (x2 > x) {
|
|
|
|
n += vnc_job_add_rect(job, x * VNC_DIRTY_PIXELS_PER_BIT, y,
|
|
|
|
(x2 - x) * VNC_DIRTY_PIXELS_PER_BIT, h);
|
|
|
|
}
|
|
|
|
if (!x && x2 == width / VNC_DIRTY_PIXELS_PER_BIT) {
|
|
|
|
y += h;
|
|
|
|
if (y == height) {
|
2014-01-08 10:08:35 +01:00
|
|
|
break;
|
2009-03-06 21:27:40 +01:00
|
|
|
}
|
|
|
|
}
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
|
|
|
|
ui: fix VNC client throttling when forced update is requested
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check is disabled if the client has requested
a forced update, because we want to send these as soon as possible.
As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then repeatedly send full framebuffer update
requests, but never read data back from the server. This can easily make QEMU's
VNC server send buffer consume 100MB of RAM per second, until the OOM killer
starts reaping processes (hopefully the rogue QEMU process, but it might pick
others...).
To address this we make the throttling more intelligent, so we can throttle
full updates. When we get a forced update request, we keep track of exactly how
much data we put on the output buffer. We will not process a subsequent forced
update request until this data has been fully sent on the wire. We always allow
one forced update request to be in flight, regardless of what data is queued
for incremental updates or audio data. The slight complication is that we do
not initially know how much data an update will send, as this is done in the
background by the VNC job thread. So we must track the fact that the job thread
has an update pending, and not process any further updates until this job is
has been completed & put data on the output buffer.
This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.
This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:
commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Oct 9 14:43:42 2017 +0100
io: monitor encoutput buffer size from websocket GSource
This new general memory usage flaw has been assigned CVE-2017-15124, and is
partially fixed by this patch.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20171218191228.31018-11-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-12-18 20:12:25 +01:00
|
|
|
vs->job_update = vs->update;
|
2017-12-18 20:12:22 +01:00
|
|
|
vs->update = VNC_STATE_UPDATE_NONE;
|
ui: fix VNC client throttling when forced update is requested
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check is disabled if the client has requested
a forced update, because we want to send these as soon as possible.
As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then repeatedly send full framebuffer update
requests, but never read data back from the server. This can easily make QEMU's
VNC server send buffer consume 100MB of RAM per second, until the OOM killer
starts reaping processes (hopefully the rogue QEMU process, but it might pick
others...).
To address this we make the throttling more intelligent, so we can throttle
full updates. When we get a forced update request, we keep track of exactly how
much data we put on the output buffer. We will not process a subsequent forced
update request until this data has been fully sent on the wire. We always allow
one forced update request to be in flight, regardless of what data is queued
for incremental updates or audio data. The slight complication is that we do
not initially know how much data an update will send, as this is done in the
background by the VNC job thread. So we must track the fact that the job thread
has an update pending, and not process any further updates until this job is
has been completed & put data on the output buffer.
This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.
This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:
commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Oct 9 14:43:42 2017 +0100
io: monitor encoutput buffer size from websocket GSource
This new general memory usage flaw has been assigned CVE-2017-15124, and is
partially fixed by this patch.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20171218191228.31018-11-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-12-18 20:12:25 +01:00
|
|
|
vnc_job_push(job);
|
2017-12-18 20:12:18 +01:00
|
|
|
vs->has_dirty = 0;
|
|
|
|
return n;
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
|
|
|
|
2008-12-01 21:57:48 +01:00
|
|
|
/* audio */
|
|
|
|
static void audio_capture_notify(void *opaque, audcnotification_e cmd)
|
|
|
|
{
|
|
|
|
VncState *vs = opaque;
|
|
|
|
|
2018-05-07 12:22:54 +02:00
|
|
|
assert(vs->magic == VNC_MAGIC);
|
2008-12-01 21:57:48 +01:00
|
|
|
switch (cmd) {
|
|
|
|
case AUD_CNOTIFY_DISABLE:
|
2021-03-11 19:29:54 +01:00
|
|
|
trace_vnc_msg_server_audio_end(vs, vs->ioc);
|
2010-07-07 20:58:02 +02:00
|
|
|
vnc_lock_output(vs);
|
2010-03-31 19:20:43 +02:00
|
|
|
vnc_write_u8(vs, VNC_MSG_SERVER_QEMU);
|
|
|
|
vnc_write_u8(vs, VNC_MSG_SERVER_QEMU_AUDIO);
|
|
|
|
vnc_write_u16(vs, VNC_MSG_SERVER_QEMU_AUDIO_END);
|
2010-07-07 20:58:02 +02:00
|
|
|
vnc_unlock_output(vs);
|
2008-12-01 21:57:48 +01:00
|
|
|
vnc_flush(vs);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case AUD_CNOTIFY_ENABLE:
|
2021-03-11 19:29:54 +01:00
|
|
|
trace_vnc_msg_server_audio_begin(vs, vs->ioc);
|
2010-07-07 20:58:02 +02:00
|
|
|
vnc_lock_output(vs);
|
2010-03-31 19:20:43 +02:00
|
|
|
vnc_write_u8(vs, VNC_MSG_SERVER_QEMU);
|
|
|
|
vnc_write_u8(vs, VNC_MSG_SERVER_QEMU_AUDIO);
|
|
|
|
vnc_write_u16(vs, VNC_MSG_SERVER_QEMU_AUDIO_BEGIN);
|
2010-07-07 20:58:02 +02:00
|
|
|
vnc_unlock_output(vs);
|
2008-12-01 21:57:48 +01:00
|
|
|
vnc_flush(vs);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void audio_capture_destroy(void *opaque)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2020-05-05 15:25:58 +02:00
|
|
|
static void audio_capture(void *opaque, const void *buf, int size)
|
2008-12-01 21:57:48 +01:00
|
|
|
{
|
|
|
|
VncState *vs = opaque;
|
|
|
|
|
2018-05-07 12:22:54 +02:00
|
|
|
assert(vs->magic == VNC_MAGIC);
|
2021-03-11 19:29:54 +01:00
|
|
|
trace_vnc_msg_server_audio_data(vs, vs->ioc, buf, size);
|
2010-07-07 20:58:02 +02:00
|
|
|
vnc_lock_output(vs);
|
ui: fix VNC client throttling when audio capture is active
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check must be disabled if audio capture is
enabled, because when streaming audio the output buffer offset will rarely be
zero due to queued audio data, and so this would starve framebuffer updates.
As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then enable audio capture, and simply never
read data back from the server. This can easily make QEMU's VNC server send
buffer consume 100MB of RAM per second, until the OOM killer starts reaping
processes (hopefully the rogue QEMU process, but it might pick others...).
To address this we make the throttling more intelligent, so we can throttle
when audio capture is active too. To determine how to throttle incremental
updates or audio data, we calculate a size threshold. Normally the threshold is
the approximate number of bytes associated with a single complete framebuffer
update. ie width * height * bytes per pixel. We'll send incremental updates
until we hit this threshold, at which point we'll stop sending updates until
data has been written to the wire, causing the output buffer offset to fall
back below the threshold.
If audio capture is enabled, we increase the size of the threshold to also
allow for upto 1 seconds worth of audio data samples. ie nchannels * bytes
per sample * frequency. This allows the output buffer to have a mixture of
incremental framebuffer updates and audio data queued, but once the threshold
is exceeded, audio data will be dropped and incremental updates will be
throttled.
This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.
This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:
commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Oct 9 14:43:42 2017 +0100
io: monitor encoutput buffer size from websocket GSource
This new general memory usage flaw has been assigned CVE-2017-15124, and is
partially fixed by this patch.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20171218191228.31018-10-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-12-18 20:12:24 +01:00
|
|
|
if (vs->output.offset < vs->throttle_output_offset) {
|
|
|
|
vnc_write_u8(vs, VNC_MSG_SERVER_QEMU);
|
|
|
|
vnc_write_u8(vs, VNC_MSG_SERVER_QEMU_AUDIO);
|
|
|
|
vnc_write_u16(vs, VNC_MSG_SERVER_QEMU_AUDIO_DATA);
|
|
|
|
vnc_write_u32(vs, size);
|
|
|
|
vnc_write(vs, buf, size);
|
2017-12-18 20:12:27 +01:00
|
|
|
} else {
|
|
|
|
trace_vnc_client_throttle_audio(vs, vs->ioc, vs->output.offset);
|
ui: fix VNC client throttling when audio capture is active
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check must be disabled if audio capture is
enabled, because when streaming audio the output buffer offset will rarely be
zero due to queued audio data, and so this would starve framebuffer updates.
As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then enable audio capture, and simply never
read data back from the server. This can easily make QEMU's VNC server send
buffer consume 100MB of RAM per second, until the OOM killer starts reaping
processes (hopefully the rogue QEMU process, but it might pick others...).
To address this we make the throttling more intelligent, so we can throttle
when audio capture is active too. To determine how to throttle incremental
updates or audio data, we calculate a size threshold. Normally the threshold is
the approximate number of bytes associated with a single complete framebuffer
update. ie width * height * bytes per pixel. We'll send incremental updates
until we hit this threshold, at which point we'll stop sending updates until
data has been written to the wire, causing the output buffer offset to fall
back below the threshold.
If audio capture is enabled, we increase the size of the threshold to also
allow for upto 1 seconds worth of audio data samples. ie nchannels * bytes
per sample * frequency. This allows the output buffer to have a mixture of
incremental framebuffer updates and audio data queued, but once the threshold
is exceeded, audio data will be dropped and incremental updates will be
throttled.
This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.
This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:
commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Oct 9 14:43:42 2017 +0100
io: monitor encoutput buffer size from websocket GSource
This new general memory usage flaw has been assigned CVE-2017-15124, and is
partially fixed by this patch.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20171218191228.31018-10-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-12-18 20:12:24 +01:00
|
|
|
}
|
2010-07-07 20:58:02 +02:00
|
|
|
vnc_unlock_output(vs);
|
2008-12-01 21:57:48 +01:00
|
|
|
vnc_flush(vs);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void audio_add(VncState *vs)
|
|
|
|
{
|
|
|
|
struct audio_capture_ops ops;
|
|
|
|
|
|
|
|
if (vs->audio_cap) {
|
2014-03-22 00:42:21 +01:00
|
|
|
error_report("audio already running");
|
2008-12-01 21:57:48 +01:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
ops.notify = audio_capture_notify;
|
|
|
|
ops.destroy = audio_capture_destroy;
|
|
|
|
ops.capture = audio_capture;
|
|
|
|
|
2019-08-19 01:06:48 +02:00
|
|
|
vs->audio_cap = AUD_add_capture(vs->vd->audio_state, &vs->as, &ops, vs);
|
2008-12-01 21:57:48 +01:00
|
|
|
if (!vs->audio_cap) {
|
2014-03-22 00:42:21 +01:00
|
|
|
error_report("Failed to add audio capture");
|
2008-12-01 21:57:48 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void audio_del(VncState *vs)
|
|
|
|
{
|
|
|
|
if (vs->audio_cap) {
|
|
|
|
AUD_del_capture(vs->audio_cap, vs);
|
|
|
|
vs->audio_cap = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-06-16 14:19:48 +02:00
|
|
|
static void vnc_disconnect_start(VncState *vs)
|
|
|
|
{
|
2015-02-27 17:20:57 +01:00
|
|
|
if (vs->disconnecting) {
|
2009-06-16 14:19:48 +02:00
|
|
|
return;
|
2015-02-27 17:20:57 +01:00
|
|
|
}
|
2017-09-21 14:15:27 +02:00
|
|
|
trace_vnc_client_disconnect_start(vs, vs->ioc);
|
2011-11-24 18:10:49 +01:00
|
|
|
vnc_set_share_mode(vs, VNC_SHARE_MODE_DISCONNECTED);
|
2015-02-27 17:20:57 +01:00
|
|
|
if (vs->ioc_tag) {
|
|
|
|
g_source_remove(vs->ioc_tag);
|
2017-09-12 17:21:47 +02:00
|
|
|
vs->ioc_tag = 0;
|
2015-02-27 17:20:57 +01:00
|
|
|
}
|
|
|
|
qio_channel_close(vs->ioc, NULL);
|
|
|
|
vs->disconnecting = TRUE;
|
2009-06-16 14:19:48 +02:00
|
|
|
}
|
|
|
|
|
2013-01-21 11:04:44 +01:00
|
|
|
void vnc_disconnect_finish(VncState *vs)
|
2009-06-16 14:19:48 +02:00
|
|
|
{
|
2011-02-04 09:05:56 +01:00
|
|
|
int i;
|
|
|
|
|
2017-09-21 14:15:27 +02:00
|
|
|
trace_vnc_client_disconnect_finish(vs, vs->ioc);
|
|
|
|
|
2010-07-07 20:58:02 +02:00
|
|
|
vnc_jobs_join(vs); /* Wait encoding jobs */
|
|
|
|
|
|
|
|
vnc_lock_output(vs);
|
2014-06-18 08:43:49 +02:00
|
|
|
vnc_qmp_event(vs, QAPI_EVENT_VNC_DISCONNECTED);
|
QMP: Introduce VNC_DISCONNECTED event
It's emitted when a VNC client disconnects from QEMU, client's
information such as port and IP address are provided.
Event example:
{ "event": "VNC_DISCONNECTED",
"timestamp": { "seconds": 1262976601, "microseconds": 975795 },
"data": {
"server": { "auth": "sasl", "family": "ipv4",
"service": "5901", "host": "0.0.0.0" },
"client": { "family": "ipv4", "service": "58425",
"host": "127.0.0.1", "sasl_username": "foo" } } }
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-01-14 17:50:58 +01:00
|
|
|
|
2010-05-19 09:24:07 +02:00
|
|
|
buffer_free(&vs->input);
|
|
|
|
buffer_free(&vs->output);
|
2010-01-14 17:50:56 +01:00
|
|
|
|
2014-06-18 08:43:49 +02:00
|
|
|
qapi_free_VncClientInfo(vs->info);
|
2010-01-14 17:50:56 +01:00
|
|
|
|
2010-05-19 09:24:08 +02:00
|
|
|
vnc_zlib_clear(vs);
|
2010-05-19 09:24:10 +02:00
|
|
|
vnc_tight_clear(vs);
|
2011-02-04 09:06:01 +01:00
|
|
|
vnc_zrle_clear(vs);
|
2010-05-19 09:24:08 +02:00
|
|
|
|
2009-06-16 14:19:48 +02:00
|
|
|
#ifdef CONFIG_VNC_SASL
|
|
|
|
vnc_sasl_client_cleanup(vs);
|
|
|
|
#endif /* CONFIG_VNC_SASL */
|
|
|
|
audio_del(vs);
|
2019-01-22 10:28:12 +01:00
|
|
|
qkbd_state_lift_all_keys(vs->vd->kbd);
|
2009-06-16 14:19:48 +02:00
|
|
|
|
2016-09-29 17:45:39 +02:00
|
|
|
if (vs->mouse_mode_notifier.notify != NULL) {
|
2013-01-21 11:04:45 +01:00
|
|
|
qemu_remove_mouse_mode_change_notifier(&vs->mouse_mode_notifier);
|
2016-09-29 17:45:39 +02:00
|
|
|
}
|
|
|
|
QTAILQ_REMOVE(&vs->vd->clients, vs, next);
|
|
|
|
if (QTAILQ_EMPTY(&vs->vd->clients)) {
|
|
|
|
/* last client gone */
|
|
|
|
vnc_update_server_surface(vs->vd);
|
2013-01-21 11:04:45 +01:00
|
|
|
}
|
ui/vnc.c: Fixed a deadlock bug.
The GDB statck is as follows:
(gdb) bt
0 __lll_lock_wait (futex=futex@entry=0x56211df20360, private=0) at lowlevellock.c:52
1 0x00007f263caf20a3 in __GI___pthread_mutex_lock (mutex=0x56211df20360) at ../nptl/pthread_mutex_lock.c:80
2 0x000056211a757364 in qemu_mutex_lock_impl (mutex=0x56211df20360, file=0x56211a804857 "../ui/vnc-jobs.h", line=60)
at ../util/qemu-thread-posix.c:80
3 0x000056211a0ef8c7 in vnc_lock_output (vs=0x56211df14200) at ../ui/vnc-jobs.h:60
4 0x000056211a0efcb7 in vnc_clipboard_send (vs=0x56211df14200, count=1, dwords=0x7ffdf1701338) at ../ui/vnc-clipboard.c:138
5 0x000056211a0f0129 in vnc_clipboard_notify (notifier=0x56211df244c8, data=0x56211dd1bbf0) at ../ui/vnc-clipboard.c:209
6 0x000056211a75dde8 in notifier_list_notify (list=0x56211afa17d0 <clipboard_notifiers>, data=0x56211dd1bbf0) at ../util/notify.c:39
7 0x000056211a0bf0e6 in qemu_clipboard_update (info=0x56211dd1bbf0) at ../ui/clipboard.c:50
8 0x000056211a0bf05d in qemu_clipboard_peer_release (peer=0x56211df244c0, selection=QEMU_CLIPBOARD_SELECTION_CLIPBOARD)
at ../ui/clipboard.c:41
9 0x000056211a0bef9b in qemu_clipboard_peer_unregister (peer=0x56211df244c0) at ../ui/clipboard.c:19
10 0x000056211a0d45f3 in vnc_disconnect_finish (vs=0x56211df14200) at ../ui/vnc.c:1358
11 0x000056211a0d4c9d in vnc_client_read (vs=0x56211df14200) at ../ui/vnc.c:1611
12 0x000056211a0d4df8 in vnc_client_io (ioc=0x56211ce70690, condition=G_IO_IN, opaque=0x56211df14200) at ../ui/vnc.c:1649
13 0x000056211a5b976c in qio_channel_fd_source_dispatch
(source=0x56211ce50a00, callback=0x56211a0d4d71 <vnc_client_io>, user_data=0x56211df14200) at ../io/channel-watch.c:84
14 0x00007f263ccede8e in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
15 0x000056211a77d4a1 in glib_pollfds_poll () at ../util/main-loop.c:232
16 0x000056211a77d51f in os_host_main_loop_wait (timeout=958545) at ../util/main-loop.c:255
17 0x000056211a77d630 in main_loop_wait (nonblocking=0) at ../util/main-loop.c:531
18 0x000056211a45bc8e in qemu_main_loop () at ../softmmu/runstate.c:726
19 0x000056211a0b45fa in main (argc=69, argv=0x7ffdf1701778, envp=0x7ffdf17019a8) at ../softmmu/main.c:50
From the call trace, we can see it is a deadlock bug.
vnc_disconnect_finish will acquire the output_mutex.
But, the output_mutex will be acquired again in vnc_clipboard_send.
Repeated locking will cause deadlock. So, I move
qemu_clipboard_peer_unregister() behind vnc_unlock_output();
Fixes: 0bf41cab93e ("ui/vnc: clipboard support")
Signed-off-by: Lei Rao <lei.rao@intel.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20220105020808.597325-1-lei.rao@intel.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2022-01-05 03:08:08 +01:00
|
|
|
vnc_unlock_output(vs);
|
|
|
|
|
2021-07-19 17:42:15 +02:00
|
|
|
if (vs->cbpeer.notifier.notify) {
|
2021-05-19 07:39:38 +02:00
|
|
|
qemu_clipboard_peer_unregister(&vs->cbpeer);
|
|
|
|
}
|
2010-02-05 12:04:05 +01:00
|
|
|
|
2010-07-07 20:58:02 +02:00
|
|
|
qemu_mutex_destroy(&vs->output_mutex);
|
2013-01-21 11:04:45 +01:00
|
|
|
if (vs->bh != NULL) {
|
|
|
|
qemu_bh_delete(vs->bh);
|
|
|
|
}
|
2012-03-14 07:58:47 +01:00
|
|
|
buffer_free(&vs->jobs_buffer);
|
|
|
|
|
2011-02-04 09:05:56 +01:00
|
|
|
for (i = 0; i < VNC_STAT_ROWS; ++i) {
|
2011-08-21 05:09:37 +02:00
|
|
|
g_free(vs->lossy_rect[i]);
|
2011-02-04 09:05:56 +01:00
|
|
|
}
|
2011-08-21 05:09:37 +02:00
|
|
|
g_free(vs->lossy_rect);
|
2015-02-27 17:20:57 +01:00
|
|
|
|
|
|
|
object_unref(OBJECT(vs->ioc));
|
|
|
|
vs->ioc = NULL;
|
|
|
|
object_unref(OBJECT(vs->sioc));
|
|
|
|
vs->sioc = NULL;
|
2018-05-07 12:22:54 +02:00
|
|
|
vs->magic = 0;
|
2019-08-31 17:39:22 +02:00
|
|
|
g_free(vs->zrle);
|
|
|
|
g_free(vs->tight);
|
2011-08-21 05:09:37 +02:00
|
|
|
g_free(vs);
|
2009-06-16 14:19:48 +02:00
|
|
|
}
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
|
2019-12-05 18:46:19 +01:00
|
|
|
size_t vnc_client_io_error(VncState *vs, ssize_t ret, Error *err)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
2015-02-27 17:20:57 +01:00
|
|
|
if (ret <= 0) {
|
|
|
|
if (ret == 0) {
|
2017-09-21 14:15:27 +02:00
|
|
|
trace_vnc_client_eof(vs, vs->ioc);
|
vnc: do not disconnect on EAGAIN
When qemu vnc server is trying to send large update to clients,
there might be a situation when system responds with something
like EAGAIN, indicating that there's no system memory to send
that much data (depending on the network speed, client and server
and what is happening). In this case, something like this happens
on qemu side (from strace):
sendmsg(16, {msg_name(0)=NULL,
msg_iov(1)=[{"\244\"..., 729186}],
msg_controllen=0, msg_flags=0}, 0) = 103950
sendmsg(16, {msg_name(0)=NULL,
msg_iov(1)=[{"lz\346"..., 1559618}],
msg_controllen=0, msg_flags=0}, 0) = -1 EAGAIN
sendmsg(-1, {msg_name(0)=NULL,
msg_iov(1)=[{"lz\346"..., 1559618}],
msg_controllen=0, msg_flags=0}, 0) = -1 EBADF
qemu closes the socket before the retry, and obviously it gets EBADF
when trying to send to -1.
This is because there WAS a special handling for EAGAIN, but now it doesn't
work anymore, after commit 04d2529da27db512dcbd5e99d0e26d333f16efcc, because
now in all error-like cases we initiate vnc disconnect.
This change were introduced in qemu 2.6, and caused numerous grief for many
people, resulting in their vnc clients reporting sporadic random disconnects
from vnc server.
Fix that by doing the disconnect only when necessary, i.e. omitting this
very case of EAGAIN.
Hopefully the existing condition (comparing with QIO_CHANNEL_ERR_BLOCK)
is sufficient, as the original code (before the above commit) were
checking for other errno values too.
Apparently there's another (semi?)bug exist somewhere here, since the
code tries to write to fd# -1, it probably should check if the connection
is open before. But this isn't important.
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1486115549-9398-1-git-send-email-mjt@msgid.tls.msk.ru
Fixes: 04d2529da27db512dcbd5e99d0e26d333f16efcc
Cc: Daniel P. Berrange <berrange@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 10:52:29 +01:00
|
|
|
vnc_disconnect_start(vs);
|
2015-02-27 17:20:57 +01:00
|
|
|
} else if (ret != QIO_CHANNEL_ERR_BLOCK) {
|
2017-09-21 14:15:27 +02:00
|
|
|
trace_vnc_client_io_error(vs, vs->ioc,
|
2019-12-05 18:46:19 +01:00
|
|
|
err ? error_get_pretty(err) : "Unknown");
|
vnc: do not disconnect on EAGAIN
When qemu vnc server is trying to send large update to clients,
there might be a situation when system responds with something
like EAGAIN, indicating that there's no system memory to send
that much data (depending on the network speed, client and server
and what is happening). In this case, something like this happens
on qemu side (from strace):
sendmsg(16, {msg_name(0)=NULL,
msg_iov(1)=[{"\244\"..., 729186}],
msg_controllen=0, msg_flags=0}, 0) = 103950
sendmsg(16, {msg_name(0)=NULL,
msg_iov(1)=[{"lz\346"..., 1559618}],
msg_controllen=0, msg_flags=0}, 0) = -1 EAGAIN
sendmsg(-1, {msg_name(0)=NULL,
msg_iov(1)=[{"lz\346"..., 1559618}],
msg_controllen=0, msg_flags=0}, 0) = -1 EBADF
qemu closes the socket before the retry, and obviously it gets EBADF
when trying to send to -1.
This is because there WAS a special handling for EAGAIN, but now it doesn't
work anymore, after commit 04d2529da27db512dcbd5e99d0e26d333f16efcc, because
now in all error-like cases we initiate vnc disconnect.
This change were introduced in qemu 2.6, and caused numerous grief for many
people, resulting in their vnc clients reporting sporadic random disconnects
from vnc server.
Fix that by doing the disconnect only when necessary, i.e. omitting this
very case of EAGAIN.
Hopefully the existing condition (comparing with QIO_CHANNEL_ERR_BLOCK)
is sufficient, as the original code (before the above commit) were
checking for other errno values too.
Apparently there's another (semi?)bug exist somewhere here, since the
code tries to write to fd# -1, it probably should check if the connection
is open before. But this isn't important.
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1486115549-9398-1-git-send-email-mjt@msgid.tls.msk.ru
Fixes: 04d2529da27db512dcbd5e99d0e26d333f16efcc
Cc: Daniel P. Berrange <berrange@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-02-03 10:52:29 +01:00
|
|
|
vnc_disconnect_start(vs);
|
2008-04-25 01:40:55 +02:00
|
|
|
}
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2019-12-05 18:46:19 +01:00
|
|
|
error_free(err);
|
2009-03-06 21:27:40 +01:00
|
|
|
return 0;
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2009-03-06 21:27:23 +01:00
|
|
|
|
|
|
|
void vnc_client_error(VncState *vs)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
2009-06-16 14:19:48 +02:00
|
|
|
VNC_DEBUG("Closing down client sock: protocol error\n");
|
|
|
|
vnc_disconnect_start(vs);
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
|
|
|
|
ui: convert VNC server to use QCryptoTLSSession
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-08-06 15:39:32 +02:00
|
|
|
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
/*
|
|
|
|
* Called to write a chunk of data to the client socket. The data may
|
|
|
|
* be the raw data, or may have already been encoded by SASL.
|
|
|
|
* The data will be written either straight onto the socket, or
|
|
|
|
* written via the GNUTLS wrappers, if TLS/SSL encryption is enabled
|
|
|
|
*
|
|
|
|
* NB, it is theoretically possible to have 2 layers of encryption,
|
|
|
|
* both SASL, and this TLS layer. It is highly unlikely in practice
|
|
|
|
* though, since SASL encryption will typically be a no-op if TLS
|
|
|
|
* is active
|
|
|
|
*
|
|
|
|
* Returns the number of bytes written, which may be less than
|
|
|
|
* the requested 'datalen' if the socket would block. Returns
|
2017-12-18 20:12:28 +01:00
|
|
|
* 0 on I/O error, and disconnects the client socket.
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
*/
|
2017-12-18 20:12:28 +01:00
|
|
|
size_t vnc_client_write_buf(VncState *vs, const uint8_t *data, size_t datalen)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
2015-02-27 17:20:57 +01:00
|
|
|
Error *err = NULL;
|
2015-08-06 16:35:55 +02:00
|
|
|
ssize_t ret;
|
2019-12-05 18:46:19 +01:00
|
|
|
ret = qio_channel_write(vs->ioc, (const char *)data, datalen, &err);
|
2009-03-20 16:59:18 +01:00
|
|
|
VNC_DEBUG("Wrote wire %p %zd -> %ld\n", data, datalen, ret);
|
2019-12-05 18:46:19 +01:00
|
|
|
return vnc_client_io_error(vs, ret, err);
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Called to write buffered data to the client socket, when not
|
|
|
|
* using any SASL SSF encryption layers. Will write as much data
|
|
|
|
* as possible without blocking. If all buffered data is written,
|
|
|
|
* will switch the FD poll() handler back to read monitoring.
|
|
|
|
*
|
|
|
|
* Returns the number of bytes written, which may be less than
|
2017-12-18 20:12:28 +01:00
|
|
|
* the buffered output data if the socket would block. Returns
|
|
|
|
* 0 on I/O error, and disconnects the client socket.
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
*/
|
2017-12-18 20:12:28 +01:00
|
|
|
static size_t vnc_client_write_plain(VncState *vs)
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
{
|
2017-12-18 20:12:27 +01:00
|
|
|
size_t offset;
|
2017-12-18 20:12:28 +01:00
|
|
|
size_t ret;
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
|
|
|
|
#ifdef CONFIG_VNC_SASL
|
2009-03-20 16:59:18 +01:00
|
|
|
VNC_DEBUG("Write Plain: Pending output %p size %zd offset %zd. Wait SSF %d\n",
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
vs->output.buffer, vs->output.capacity, vs->output.offset,
|
|
|
|
vs->sasl.waitWriteSSF);
|
|
|
|
|
|
|
|
if (vs->sasl.conn &&
|
|
|
|
vs->sasl.runSSF &&
|
|
|
|
vs->sasl.waitWriteSSF) {
|
|
|
|
ret = vnc_client_write_buf(vs, vs->output.buffer, vs->sasl.waitWriteSSF);
|
|
|
|
if (ret)
|
|
|
|
vs->sasl.waitWriteSSF -= ret;
|
|
|
|
} else
|
|
|
|
#endif /* CONFIG_VNC_SASL */
|
|
|
|
ret = vnc_client_write_buf(vs, vs->output.buffer, vs->output.offset);
|
2006-04-30 23:28:36 +02:00
|
|
|
if (!ret)
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
return 0;
|
2006-04-30 23:28:36 +02:00
|
|
|
|
ui: fix VNC client throttling when forced update is requested
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check is disabled if the client has requested
a forced update, because we want to send these as soon as possible.
As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then repeatedly send full framebuffer update
requests, but never read data back from the server. This can easily make QEMU's
VNC server send buffer consume 100MB of RAM per second, until the OOM killer
starts reaping processes (hopefully the rogue QEMU process, but it might pick
others...).
To address this we make the throttling more intelligent, so we can throttle
full updates. When we get a forced update request, we keep track of exactly how
much data we put on the output buffer. We will not process a subsequent forced
update request until this data has been fully sent on the wire. We always allow
one forced update request to be in flight, regardless of what data is queued
for incremental updates or audio data. The slight complication is that we do
not initially know how much data an update will send, as this is done in the
background by the VNC job thread. So we must track the fact that the job thread
has an update pending, and not process any further updates until this job is
has been completed & put data on the output buffer.
This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.
This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:
commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Oct 9 14:43:42 2017 +0100
io: monitor encoutput buffer size from websocket GSource
This new general memory usage flaw has been assigned CVE-2017-15124, and is
partially fixed by this patch.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20171218191228.31018-11-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-12-18 20:12:25 +01:00
|
|
|
if (ret >= vs->force_update_offset) {
|
2017-12-18 20:12:27 +01:00
|
|
|
if (vs->force_update_offset != 0) {
|
|
|
|
trace_vnc_client_unthrottle_forced(vs, vs->ioc);
|
|
|
|
}
|
ui: fix VNC client throttling when forced update is requested
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check is disabled if the client has requested
a forced update, because we want to send these as soon as possible.
As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then repeatedly send full framebuffer update
requests, but never read data back from the server. This can easily make QEMU's
VNC server send buffer consume 100MB of RAM per second, until the OOM killer
starts reaping processes (hopefully the rogue QEMU process, but it might pick
others...).
To address this we make the throttling more intelligent, so we can throttle
full updates. When we get a forced update request, we keep track of exactly how
much data we put on the output buffer. We will not process a subsequent forced
update request until this data has been fully sent on the wire. We always allow
one forced update request to be in flight, regardless of what data is queued
for incremental updates or audio data. The slight complication is that we do
not initially know how much data an update will send, as this is done in the
background by the VNC job thread. So we must track the fact that the job thread
has an update pending, and not process any further updates until this job is
has been completed & put data on the output buffer.
This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.
This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:
commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Oct 9 14:43:42 2017 +0100
io: monitor encoutput buffer size from websocket GSource
This new general memory usage flaw has been assigned CVE-2017-15124, and is
partially fixed by this patch.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20171218191228.31018-11-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-12-18 20:12:25 +01:00
|
|
|
vs->force_update_offset = 0;
|
|
|
|
} else {
|
|
|
|
vs->force_update_offset -= ret;
|
|
|
|
}
|
2017-12-18 20:12:27 +01:00
|
|
|
offset = vs->output.offset;
|
2013-01-21 11:04:43 +01:00
|
|
|
buffer_advance(&vs->output, ret);
|
2017-12-18 20:12:27 +01:00
|
|
|
if (offset >= vs->throttle_output_offset &&
|
|
|
|
vs->output.offset < vs->throttle_output_offset) {
|
|
|
|
trace_vnc_client_unthrottle_incremental(vs, vs->ioc, vs->output.offset);
|
|
|
|
}
|
2006-04-30 23:28:36 +02:00
|
|
|
|
|
|
|
if (vs->output.offset == 0) {
|
2015-02-27 17:20:57 +01:00
|
|
|
if (vs->ioc_tag) {
|
|
|
|
g_source_remove(vs->ioc_tag);
|
|
|
|
}
|
|
|
|
vs->ioc_tag = qio_channel_add_watch(
|
2020-10-29 04:22:41 +01:00
|
|
|
vs->ioc, G_IO_IN | G_IO_HUP | G_IO_ERR,
|
|
|
|
vnc_client_io, vs, NULL);
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* First function called whenever there is data to be written to
|
|
|
|
* the client socket. Will delegate actual work according to whether
|
|
|
|
* SASL SSF layers are enabled (thus requiring encryption calls)
|
|
|
|
*/
|
2015-02-27 17:20:57 +01:00
|
|
|
static void vnc_client_write_locked(VncState *vs)
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
{
|
|
|
|
#ifdef CONFIG_VNC_SASL
|
|
|
|
if (vs->sasl.conn &&
|
|
|
|
vs->sasl.runSSF &&
|
2010-04-25 20:35:52 +02:00
|
|
|
!vs->sasl.waitWriteSSF) {
|
|
|
|
vnc_client_write_sasl(vs);
|
|
|
|
} else
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
#endif /* CONFIG_VNC_SASL */
|
2013-01-21 11:04:44 +01:00
|
|
|
{
|
2015-03-11 16:53:49 +01:00
|
|
|
vnc_client_write_plain(vs);
|
2013-01-21 11:04:44 +01:00
|
|
|
}
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
|
|
|
|
2015-02-27 17:20:57 +01:00
|
|
|
static void vnc_client_write(VncState *vs)
|
2010-07-07 20:58:02 +02:00
|
|
|
{
|
2018-05-07 12:22:54 +02:00
|
|
|
assert(vs->magic == VNC_MAGIC);
|
2010-07-07 20:58:02 +02:00
|
|
|
vnc_lock_output(vs);
|
2015-03-11 16:53:49 +01:00
|
|
|
if (vs->output.offset) {
|
2015-02-27 17:20:57 +01:00
|
|
|
vnc_client_write_locked(vs);
|
|
|
|
} else if (vs->ioc != NULL) {
|
|
|
|
if (vs->ioc_tag) {
|
|
|
|
g_source_remove(vs->ioc_tag);
|
|
|
|
}
|
|
|
|
vs->ioc_tag = qio_channel_add_watch(
|
2020-10-29 04:22:41 +01:00
|
|
|
vs->ioc, G_IO_IN | G_IO_HUP | G_IO_ERR,
|
|
|
|
vnc_client_io, vs, NULL);
|
2010-07-07 20:58:02 +02:00
|
|
|
}
|
|
|
|
vnc_unlock_output(vs);
|
|
|
|
}
|
|
|
|
|
2009-03-06 21:27:23 +01:00
|
|
|
void vnc_read_when(VncState *vs, VncReadEvent *func, size_t expecting)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
|
|
|
vs->read_handler = func;
|
|
|
|
vs->read_handler_expect = expecting;
|
|
|
|
}
|
|
|
|
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Called to read a chunk of data from the client socket. The data may
|
|
|
|
* be the raw data, or may need to be further decoded by SASL.
|
|
|
|
* The data will be read either straight from to the socket, or
|
|
|
|
* read via the GNUTLS wrappers, if TLS/SSL encryption is enabled
|
|
|
|
*
|
|
|
|
* NB, it is theoretically possible to have 2 layers of encryption,
|
|
|
|
* both SASL, and this TLS layer. It is highly unlikely in practice
|
|
|
|
* though, since SASL encryption will typically be a no-op if TLS
|
|
|
|
* is active
|
|
|
|
*
|
|
|
|
* Returns the number of bytes read, which may be less than
|
|
|
|
* the requested 'datalen' if the socket would block. Returns
|
2017-12-18 20:12:28 +01:00
|
|
|
* 0 on I/O error or EOF, and disconnects the client socket.
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
*/
|
2017-12-18 20:12:28 +01:00
|
|
|
size_t vnc_client_read_buf(VncState *vs, uint8_t *data, size_t datalen)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
2015-08-06 16:35:55 +02:00
|
|
|
ssize_t ret;
|
2015-02-27 17:20:57 +01:00
|
|
|
Error *err = NULL;
|
2019-12-05 18:46:19 +01:00
|
|
|
ret = qio_channel_read(vs->ioc, (char *)data, datalen, &err);
|
2009-03-20 16:59:18 +01:00
|
|
|
VNC_DEBUG("Read wire %p %zd -> %ld\n", data, datalen, ret);
|
2019-12-05 18:46:19 +01:00
|
|
|
return vnc_client_io_error(vs, ret, err);
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
}
|
2006-04-30 23:28:36 +02:00
|
|
|
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Called to read data from the client socket to the input buffer,
|
|
|
|
* when not using any SASL SSF encryption layers. Will read as much
|
|
|
|
* data as possible without blocking.
|
|
|
|
*
|
2017-12-18 20:12:28 +01:00
|
|
|
* Returns the number of bytes read, which may be less than
|
|
|
|
* the requested 'datalen' if the socket would block. Returns
|
|
|
|
* 0 on I/O error or EOF, and disconnects the client socket.
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
*/
|
2017-12-18 20:12:28 +01:00
|
|
|
static size_t vnc_client_read_plain(VncState *vs)
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
{
|
2017-12-18 20:12:28 +01:00
|
|
|
size_t ret;
|
2009-03-20 16:59:18 +01:00
|
|
|
VNC_DEBUG("Read plain %p size %zd offset %zd\n",
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
vs->input.buffer, vs->input.capacity, vs->input.offset);
|
|
|
|
buffer_reserve(&vs->input, 4096);
|
|
|
|
ret = vnc_client_read_buf(vs, buffer_end(&vs->input), 4096);
|
|
|
|
if (!ret)
|
|
|
|
return 0;
|
2006-04-30 23:28:36 +02:00
|
|
|
vs->input.offset += ret;
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-03-14 07:58:47 +01:00
|
|
|
static void vnc_jobs_bh(void *opaque)
|
|
|
|
{
|
|
|
|
VncState *vs = opaque;
|
|
|
|
|
2018-05-07 12:22:54 +02:00
|
|
|
assert(vs->magic == VNC_MAGIC);
|
2012-03-14 07:58:47 +01:00
|
|
|
vnc_jobs_consume_buffer(vs);
|
|
|
|
}
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* First function called whenever there is more data to be read from
|
|
|
|
* the client socket. Will delegate actual work according to whether
|
|
|
|
* SASL SSF layers are enabled (thus requiring decryption calls)
|
2016-06-27 17:48:49 +02:00
|
|
|
* Returns 0 on success, -1 if client disconnected
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
*/
|
2016-06-27 17:48:49 +02:00
|
|
|
static int vnc_client_read(VncState *vs)
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
{
|
2023-09-21 14:13:08 +02:00
|
|
|
size_t sz;
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
|
|
|
|
#ifdef CONFIG_VNC_SASL
|
|
|
|
if (vs->sasl.conn && vs->sasl.runSSF)
|
2023-09-21 14:13:08 +02:00
|
|
|
sz = vnc_client_read_sasl(vs);
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
else
|
|
|
|
#endif /* CONFIG_VNC_SASL */
|
2023-09-21 14:13:08 +02:00
|
|
|
sz = vnc_client_read_plain(vs);
|
|
|
|
if (!sz) {
|
2015-02-27 17:20:57 +01:00
|
|
|
if (vs->disconnecting) {
|
2009-06-16 14:19:48 +02:00
|
|
|
vnc_disconnect_finish(vs);
|
2016-06-27 17:48:49 +02:00
|
|
|
return -1;
|
2015-02-27 17:20:57 +01:00
|
|
|
}
|
2016-06-27 17:48:49 +02:00
|
|
|
return 0;
|
2009-06-16 14:19:48 +02:00
|
|
|
}
|
2006-04-30 23:28:36 +02:00
|
|
|
|
|
|
|
while (vs->read_handler && vs->input.offset >= vs->read_handler_expect) {
|
2009-03-06 21:27:40 +01:00
|
|
|
size_t len = vs->read_handler_expect;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = vs->read_handler(vs, vs->input.buffer, len);
|
2015-02-27 17:20:57 +01:00
|
|
|
if (vs->disconnecting) {
|
2009-06-16 14:19:48 +02:00
|
|
|
vnc_disconnect_finish(vs);
|
2016-06-27 17:48:49 +02:00
|
|
|
return -1;
|
2009-06-16 14:19:48 +02:00
|
|
|
}
|
2009-03-06 21:27:40 +01:00
|
|
|
|
|
|
|
if (!ret) {
|
2013-01-21 11:04:43 +01:00
|
|
|
buffer_advance(&vs->input, len);
|
2009-03-06 21:27:40 +01:00
|
|
|
} else {
|
|
|
|
vs->read_handler_expect = ret;
|
|
|
|
}
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
2016-06-27 17:48:49 +02:00
|
|
|
return 0;
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
|
|
|
|
2015-02-27 17:20:57 +01:00
|
|
|
gboolean vnc_client_io(QIOChannel *ioc G_GNUC_UNUSED,
|
|
|
|
GIOCondition condition, void *opaque)
|
|
|
|
{
|
|
|
|
VncState *vs = opaque;
|
2018-05-07 12:22:54 +02:00
|
|
|
|
|
|
|
assert(vs->magic == VNC_MAGIC);
|
2020-10-29 04:22:41 +01:00
|
|
|
|
|
|
|
if (condition & (G_IO_HUP | G_IO_ERR)) {
|
|
|
|
vnc_disconnect_start(vs);
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2015-02-27 17:20:57 +01:00
|
|
|
if (condition & G_IO_IN) {
|
2016-06-27 17:48:49 +02:00
|
|
|
if (vnc_client_read(vs) < 0) {
|
2018-04-20 10:48:19 +02:00
|
|
|
/* vs is free()ed here */
|
|
|
|
return TRUE;
|
2016-06-27 17:48:49 +02:00
|
|
|
}
|
2015-02-27 17:20:57 +01:00
|
|
|
}
|
|
|
|
if (condition & G_IO_OUT) {
|
|
|
|
vnc_client_write(vs);
|
|
|
|
}
|
2018-04-20 10:48:19 +02:00
|
|
|
|
vnc: fix segfault in closed connection handling
On one of our client's node, due to trying to read from closed ioc,
a segmentation fault occured. Corresponding backtrace:
0 object_get_class (obj=obj@entry=0x0)
1 qio_channel_readv_full (ioc=0x0, iov=0x7ffe55277180 ...
2 qio_channel_read (ioc=<optimized out> ...
3 vnc_client_read_buf (vs=vs@entry=0x55625f3c6000, ...
4 vnc_client_read_plain (vs=0x55625f3c6000)
5 vnc_client_read (vs=0x55625f3c6000)
6 vnc_client_io (ioc=<optimized out>, condition=G_IO_IN, ...
7 g_main_dispatch (context=0x556251568a50)
8 g_main_context_dispatch (context=context@entry=0x556251568a50)
9 glib_pollfds_poll ()
10 os_host_main_loop_wait (timeout=<optimized out>)
11 main_loop_wait (nonblocking=nonblocking@entry=0)
12 main_loop () at vl.c:1909
13 main (argc=<optimized out>, argv=<optimized out>, ...
Having analyzed the coredump, I understood that the reason is that
ioc_tag is reset on vnc_disconnect_start and ioc is cleaned
in vnc_disconnect_finish. Between these two events due to some
reasons the ioc_tag was set again and after vnc_disconnect_finish
the handler is running with freed ioc,
which led to the segmentation fault.
The patch checks vs->disconnecting in places where we call
qio_channel_add_watch and resets handler if disconnecting == TRUE
to prevent such an occurrence.
Signed-off-by: Klim Kireev <klim.kireev@virtuozzo.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-id: 20180207094844.21402-1-klim.kireev@virtuozzo.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-02-07 10:48:44 +01:00
|
|
|
if (vs->disconnecting) {
|
|
|
|
if (vs->ioc_tag != 0) {
|
|
|
|
g_source_remove(vs->ioc_tag);
|
|
|
|
}
|
|
|
|
vs->ioc_tag = 0;
|
|
|
|
}
|
2015-02-27 17:20:57 +01:00
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2017-12-18 20:12:26 +01:00
|
|
|
/*
|
|
|
|
* Scale factor to apply to vs->throttle_output_offset when checking for
|
|
|
|
* hard limit. Worst case normal usage could be x2, if we have a complete
|
|
|
|
* incremental update and complete forced update in the output buffer.
|
|
|
|
* So x3 should be good enough, but we pick x5 to be conservative and thus
|
|
|
|
* (hopefully) never trigger incorrectly.
|
|
|
|
*/
|
|
|
|
#define VNC_THROTTLE_OUTPUT_LIMIT_SCALE 5
|
|
|
|
|
2009-03-06 21:27:23 +01:00
|
|
|
void vnc_write(VncState *vs, const void *data, size_t len)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
2018-05-07 12:22:54 +02:00
|
|
|
assert(vs->magic == VNC_MAGIC);
|
2017-12-18 20:12:26 +01:00
|
|
|
if (vs->disconnecting) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
/* Protection against malicious client/guest to prevent our output
|
|
|
|
* buffer growing without bound if client stops reading data. This
|
|
|
|
* should rarely trigger, because we have earlier throttling code
|
|
|
|
* which stops issuing framebuffer updates and drops audio data
|
|
|
|
* if the throttle_output_offset value is exceeded. So we only reach
|
|
|
|
* this higher level if a huge number of pseudo-encodings get
|
|
|
|
* triggered while data can't be sent on the socket.
|
|
|
|
*
|
|
|
|
* NB throttle_output_offset can be zero during early protocol
|
|
|
|
* handshake, or from the job thread's VncState clone
|
|
|
|
*/
|
|
|
|
if (vs->throttle_output_offset != 0 &&
|
2018-02-05 12:49:35 +01:00
|
|
|
(vs->output.offset / VNC_THROTTLE_OUTPUT_LIMIT_SCALE) >
|
|
|
|
vs->throttle_output_offset) {
|
2017-12-18 20:12:27 +01:00
|
|
|
trace_vnc_client_output_limit(vs, vs->ioc, vs->output.offset,
|
|
|
|
vs->throttle_output_offset);
|
2017-12-18 20:12:26 +01:00
|
|
|
vnc_disconnect_start(vs);
|
|
|
|
return;
|
|
|
|
}
|
2006-04-30 23:28:36 +02:00
|
|
|
buffer_reserve(&vs->output, len);
|
|
|
|
|
2015-02-27 17:20:57 +01:00
|
|
|
if (vs->ioc != NULL && buffer_empty(&vs->output)) {
|
|
|
|
if (vs->ioc_tag) {
|
|
|
|
g_source_remove(vs->ioc_tag);
|
|
|
|
}
|
|
|
|
vs->ioc_tag = qio_channel_add_watch(
|
2020-10-29 04:22:41 +01:00
|
|
|
vs->ioc, G_IO_IN | G_IO_HUP | G_IO_ERR | G_IO_OUT,
|
|
|
|
vnc_client_io, vs, NULL);
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
buffer_append(&vs->output, data, len);
|
|
|
|
}
|
|
|
|
|
2009-03-06 21:27:23 +01:00
|
|
|
void vnc_write_s32(VncState *vs, int32_t value)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
|
|
|
vnc_write_u32(vs, *(uint32_t *)&value);
|
|
|
|
}
|
|
|
|
|
2009-03-06 21:27:23 +01:00
|
|
|
void vnc_write_u32(VncState *vs, uint32_t value)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
|
|
|
uint8_t buf[4];
|
|
|
|
|
|
|
|
buf[0] = (value >> 24) & 0xFF;
|
|
|
|
buf[1] = (value >> 16) & 0xFF;
|
|
|
|
buf[2] = (value >> 8) & 0xFF;
|
|
|
|
buf[3] = value & 0xFF;
|
|
|
|
|
|
|
|
vnc_write(vs, buf, 4);
|
|
|
|
}
|
|
|
|
|
2009-03-06 21:27:23 +01:00
|
|
|
void vnc_write_u16(VncState *vs, uint16_t value)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
2006-08-24 22:36:44 +02:00
|
|
|
uint8_t buf[2];
|
2006-04-30 23:28:36 +02:00
|
|
|
|
|
|
|
buf[0] = (value >> 8) & 0xFF;
|
|
|
|
buf[1] = value & 0xFF;
|
|
|
|
|
|
|
|
vnc_write(vs, buf, 2);
|
|
|
|
}
|
|
|
|
|
2009-03-06 21:27:23 +01:00
|
|
|
void vnc_write_u8(VncState *vs, uint8_t value)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
|
|
|
vnc_write(vs, (char *)&value, 1);
|
|
|
|
}
|
|
|
|
|
2009-03-06 21:27:23 +01:00
|
|
|
void vnc_flush(VncState *vs)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
2010-07-07 20:58:02 +02:00
|
|
|
vnc_lock_output(vs);
|
2015-03-11 16:53:49 +01:00
|
|
|
if (vs->ioc != NULL && vs->output.offset) {
|
2010-07-07 20:58:02 +02:00
|
|
|
vnc_client_write_locked(vs);
|
|
|
|
}
|
vnc: fix segfault in closed connection handling
On one of our client's node, due to trying to read from closed ioc,
a segmentation fault occured. Corresponding backtrace:
0 object_get_class (obj=obj@entry=0x0)
1 qio_channel_readv_full (ioc=0x0, iov=0x7ffe55277180 ...
2 qio_channel_read (ioc=<optimized out> ...
3 vnc_client_read_buf (vs=vs@entry=0x55625f3c6000, ...
4 vnc_client_read_plain (vs=0x55625f3c6000)
5 vnc_client_read (vs=0x55625f3c6000)
6 vnc_client_io (ioc=<optimized out>, condition=G_IO_IN, ...
7 g_main_dispatch (context=0x556251568a50)
8 g_main_context_dispatch (context=context@entry=0x556251568a50)
9 glib_pollfds_poll ()
10 os_host_main_loop_wait (timeout=<optimized out>)
11 main_loop_wait (nonblocking=nonblocking@entry=0)
12 main_loop () at vl.c:1909
13 main (argc=<optimized out>, argv=<optimized out>, ...
Having analyzed the coredump, I understood that the reason is that
ioc_tag is reset on vnc_disconnect_start and ioc is cleaned
in vnc_disconnect_finish. Between these two events due to some
reasons the ioc_tag was set again and after vnc_disconnect_finish
the handler is running with freed ioc,
which led to the segmentation fault.
The patch checks vs->disconnecting in places where we call
qio_channel_add_watch and resets handler if disconnecting == TRUE
to prevent such an occurrence.
Signed-off-by: Klim Kireev <klim.kireev@virtuozzo.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-id: 20180207094844.21402-1-klim.kireev@virtuozzo.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-02-07 10:48:44 +01:00
|
|
|
if (vs->disconnecting) {
|
|
|
|
if (vs->ioc_tag != 0) {
|
|
|
|
g_source_remove(vs->ioc_tag);
|
|
|
|
}
|
|
|
|
vs->ioc_tag = 0;
|
|
|
|
}
|
2010-07-07 20:58:02 +02:00
|
|
|
vnc_unlock_output(vs);
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
|
|
|
|
2012-10-28 12:04:48 +01:00
|
|
|
static uint8_t read_u8(uint8_t *data, size_t offset)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
|
|
|
return data[offset];
|
|
|
|
}
|
|
|
|
|
2012-10-28 12:04:48 +01:00
|
|
|
static uint16_t read_u16(uint8_t *data, size_t offset)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
|
|
|
return ((data[offset] & 0xFF) << 8) | (data[offset + 1] & 0xFF);
|
|
|
|
}
|
|
|
|
|
2012-10-28 12:04:48 +01:00
|
|
|
static int32_t read_s32(uint8_t *data, size_t offset)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
|
|
|
return (int32_t)((data[offset] << 24) | (data[offset + 1] << 16) |
|
2009-03-06 21:27:40 +01:00
|
|
|
(data[offset + 2] << 8) | data[offset + 3]);
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
|
|
|
|
2009-03-06 21:27:23 +01:00
|
|
|
uint32_t read_u32(uint8_t *data, size_t offset)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
|
|
|
return ((data[offset] << 24) | (data[offset + 1] << 16) |
|
2009-03-06 21:27:40 +01:00
|
|
|
(data[offset + 2] << 8) | data[offset + 3]);
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
|
|
|
|
2011-06-20 14:06:26 +02:00
|
|
|
static void check_pointer_type_change(Notifier *notifier, void *data)
|
2007-02-05 21:14:10 +01:00
|
|
|
{
|
2010-03-10 16:38:29 +01:00
|
|
|
VncState *vs = container_of(notifier, VncState, mouse_mode_notifier);
|
2023-09-21 10:29:34 +02:00
|
|
|
int absolute = qemu_input_is_absolute(vs->vd->dcl.con);
|
2010-03-10 16:38:29 +01:00
|
|
|
|
2009-02-02 16:58:29 +01:00
|
|
|
if (vnc_has_feature(vs, VNC_FEATURE_POINTER_TYPE_CHANGE) && vs->absolute != absolute) {
|
2010-07-07 20:58:02 +02:00
|
|
|
vnc_lock_output(vs);
|
2010-03-31 19:20:43 +02:00
|
|
|
vnc_write_u8(vs, VNC_MSG_SERVER_FRAMEBUFFER_UPDATE);
|
2009-03-06 21:27:40 +01:00
|
|
|
vnc_write_u8(vs, 0);
|
|
|
|
vnc_write_u16(vs, 1);
|
|
|
|
vnc_framebuffer_update(vs, absolute, 0,
|
2014-06-30 10:57:51 +02:00
|
|
|
pixman_image_get_width(vs->vd->server),
|
|
|
|
pixman_image_get_height(vs->vd->server),
|
2009-02-02 16:58:29 +01:00
|
|
|
VNC_ENCODING_POINTER_TYPE_CHANGE);
|
2010-07-07 20:58:02 +02:00
|
|
|
vnc_unlock_output(vs);
|
2009-03-06 21:27:40 +01:00
|
|
|
vnc_flush(vs);
|
2007-02-05 21:14:10 +01:00
|
|
|
}
|
|
|
|
vs->absolute = absolute;
|
|
|
|
}
|
|
|
|
|
2006-04-30 23:28:36 +02:00
|
|
|
static void pointer_event(VncState *vs, int button_mask, int x, int y)
|
|
|
|
{
|
qapi: Don't let implicit enum MAX member collide
Now that we guarantee the user doesn't have any enum values
beginning with a single underscore, we can use that for our
own purposes. Renaming ENUM_MAX to ENUM__MAX makes it obvious
that the sentinel is generated.
This patch was mostly generated by applying a temporary patch:
|diff --git a/scripts/qapi.py b/scripts/qapi.py
|index e6d014b..b862ec9 100644
|--- a/scripts/qapi.py
|+++ b/scripts/qapi.py
|@@ -1570,6 +1570,7 @@ const char *const %(c_name)s_lookup[] = {
| max_index = c_enum_const(name, 'MAX', prefix)
| ret += mcgen('''
| [%(max_index)s] = NULL,
|+// %(max_index)s
| };
| ''',
| max_index=max_index)
then running:
$ cat qapi-{types,event}.c tests/test-qapi-types.c |
sed -n 's,^// \(.*\)MAX,s|\1MAX|\1_MAX|g,p' > list
$ git grep -l _MAX | xargs sed -i -f list
The only things not generated are the changes in scripts/qapi.py.
Rejecting enum members named 'MAX' is now useless, and will be dropped
in the next patch.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1447836791-369-23-git-send-email-eblake@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
[Rebased to current master, commit message tweaked]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-11-18 09:52:57 +01:00
|
|
|
static uint32_t bmap[INPUT_BUTTON__MAX] = {
|
2013-12-02 15:17:45 +01:00
|
|
|
[INPUT_BUTTON_LEFT] = 0x01,
|
|
|
|
[INPUT_BUTTON_MIDDLE] = 0x02,
|
|
|
|
[INPUT_BUTTON_RIGHT] = 0x04,
|
2016-01-12 12:14:12 +01:00
|
|
|
[INPUT_BUTTON_WHEEL_UP] = 0x08,
|
|
|
|
[INPUT_BUTTON_WHEEL_DOWN] = 0x10,
|
2013-12-02 15:17:45 +01:00
|
|
|
};
|
|
|
|
QemuConsole *con = vs->vd->dcl.con;
|
2014-06-30 10:57:51 +02:00
|
|
|
int width = pixman_image_get_width(vs->vd->server);
|
|
|
|
int height = pixman_image_get_height(vs->vd->server);
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2013-12-02 15:17:45 +01:00
|
|
|
if (vs->last_bmask != button_mask) {
|
|
|
|
qemu_input_update_buttons(con, bmap, vs->last_bmask, button_mask);
|
|
|
|
vs->last_bmask = button_mask;
|
|
|
|
}
|
2007-02-05 21:14:10 +01:00
|
|
|
|
|
|
|
if (vs->absolute) {
|
2017-05-05 15:39:52 +02:00
|
|
|
qemu_input_queue_abs(con, INPUT_AXIS_X, x, 0, width);
|
|
|
|
qemu_input_queue_abs(con, INPUT_AXIS_Y, y, 0, height);
|
2009-02-02 16:58:29 +01:00
|
|
|
} else if (vnc_has_feature(vs, VNC_FEATURE_POINTER_TYPE_CHANGE)) {
|
2013-12-02 15:17:45 +01:00
|
|
|
qemu_input_queue_rel(con, INPUT_AXIS_X, x - 0x7FFF);
|
|
|
|
qemu_input_queue_rel(con, INPUT_AXIS_Y, y - 0x7FFF);
|
2007-02-05 21:14:10 +01:00
|
|
|
} else {
|
2013-12-02 15:17:45 +01:00
|
|
|
if (vs->last_x != -1) {
|
|
|
|
qemu_input_queue_rel(con, INPUT_AXIS_X, x - vs->last_x);
|
|
|
|
qemu_input_queue_rel(con, INPUT_AXIS_Y, y - vs->last_y);
|
|
|
|
}
|
2009-03-06 21:27:40 +01:00
|
|
|
vs->last_x = x;
|
|
|
|
vs->last_y = y;
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
2013-12-02 15:17:45 +01:00
|
|
|
qemu_input_event_sync();
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
|
|
|
|
2019-01-22 10:28:12 +01:00
|
|
|
static void press_key(VncState *vs, QKeyCode qcode)
|
2006-08-24 22:36:44 +02:00
|
|
|
{
|
2019-01-22 10:28:12 +01:00
|
|
|
qkbd_state_key_event(vs->vd->kbd, qcode, true);
|
|
|
|
qkbd_state_key_event(vs->vd->kbd, qcode, false);
|
2007-10-30 23:38:53 +01:00
|
|
|
}
|
|
|
|
|
2013-04-25 07:29:10 +02:00
|
|
|
static void vnc_led_state_change(VncState *vs)
|
|
|
|
{
|
|
|
|
if (!vnc_has_feature(vs, VNC_FEATURE_LED_STATE)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
vnc_lock_output(vs);
|
|
|
|
vnc_write_u8(vs, VNC_MSG_SERVER_FRAMEBUFFER_UPDATE);
|
|
|
|
vnc_write_u8(vs, 0);
|
|
|
|
vnc_write_u16(vs, 1);
|
|
|
|
vnc_framebuffer_update(vs, 0, 0, 1, 1, VNC_ENCODING_LED_STATE);
|
2017-01-09 17:14:02 +01:00
|
|
|
vnc_write_u8(vs, vs->vd->ledstate);
|
2013-04-25 07:29:10 +02:00
|
|
|
vnc_unlock_output(vs);
|
|
|
|
vnc_flush(vs);
|
|
|
|
}
|
|
|
|
|
2010-02-26 17:17:39 +01:00
|
|
|
static void kbd_leds(void *opaque, int ledstate)
|
|
|
|
{
|
2017-01-09 17:14:02 +01:00
|
|
|
VncDisplay *vd = opaque;
|
|
|
|
VncState *client;
|
2010-02-26 17:17:39 +01:00
|
|
|
|
2014-05-21 13:18:20 +02:00
|
|
|
trace_vnc_key_guest_leds((ledstate & QEMU_CAPS_LOCK_LED),
|
|
|
|
(ledstate & QEMU_NUM_LOCK_LED),
|
|
|
|
(ledstate & QEMU_SCROLL_LOCK_LED));
|
|
|
|
|
2017-01-09 17:14:02 +01:00
|
|
|
if (ledstate == vd->ledstate) {
|
|
|
|
return;
|
2013-04-25 07:29:09 +02:00
|
|
|
}
|
2013-04-25 07:29:10 +02:00
|
|
|
|
2017-01-09 17:14:02 +01:00
|
|
|
vd->ledstate = ledstate;
|
|
|
|
|
|
|
|
QTAILQ_FOREACH(client, &vd->clients, next) {
|
|
|
|
vnc_led_state_change(client);
|
2013-04-25 07:29:10 +02:00
|
|
|
}
|
2010-02-26 17:17:39 +01:00
|
|
|
}
|
|
|
|
|
2008-08-24 01:27:37 +02:00
|
|
|
static void do_key_event(VncState *vs, int down, int keycode, int sym)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
2019-01-22 10:28:12 +01:00
|
|
|
QKeyCode qcode = qemu_input_key_number_to_qcode(keycode);
|
|
|
|
|
2006-08-24 22:36:44 +02:00
|
|
|
/* QEMU console switch */
|
2019-01-22 10:28:12 +01:00
|
|
|
switch (qcode) {
|
|
|
|
case Q_KEY_CODE_1 ... Q_KEY_CODE_9: /* '1' to '9' keys */
|
|
|
|
if (vs->vd->dcl.con == NULL && down &&
|
|
|
|
qkbd_state_modifier_get(vs->vd->kbd, QKBD_MOD_CTRL) &&
|
|
|
|
qkbd_state_modifier_get(vs->vd->kbd, QKBD_MOD_ALT)) {
|
2006-08-24 22:36:44 +02:00
|
|
|
/* Reset the modifiers sent to the current console */
|
2019-01-22 10:28:12 +01:00
|
|
|
qkbd_state_lift_all_keys(vs->vd->kbd);
|
|
|
|
console_select(qcode - Q_KEY_CODE_1);
|
2006-08-24 22:36:44 +02:00
|
|
|
return;
|
|
|
|
}
|
2019-01-22 10:28:12 +01:00
|
|
|
default:
|
2007-10-30 23:38:53 +01:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2013-04-25 07:29:11 +02:00
|
|
|
/* Turn off the lock state sync logic if the client support the led
|
|
|
|
state extension.
|
|
|
|
*/
|
2011-01-14 10:56:54 +01:00
|
|
|
if (down && vs->vd->lock_key_sync &&
|
2013-04-25 07:29:11 +02:00
|
|
|
!vnc_has_feature(vs, VNC_FEATURE_LED_STATE) &&
|
2010-03-10 17:12:02 +01:00
|
|
|
keycode_is_keypad(vs->vd->kbd_layout, keycode)) {
|
2007-10-30 23:38:53 +01:00
|
|
|
/* If the numlock state needs to change then simulate an additional
|
|
|
|
keypress before sending this one. This will happen if the user
|
|
|
|
toggles numlock away from the VNC window.
|
|
|
|
*/
|
2009-02-16 15:59:30 +01:00
|
|
|
if (keysym_is_numlock(vs->vd->kbd_layout, sym & 0xFFFF)) {
|
2019-01-22 10:28:12 +01:00
|
|
|
if (!qkbd_state_modifier_get(vs->vd->kbd, QKBD_MOD_NUMLOCK)) {
|
2014-05-21 13:18:20 +02:00
|
|
|
trace_vnc_key_sync_numlock(true);
|
2019-01-22 10:28:12 +01:00
|
|
|
press_key(vs, Q_KEY_CODE_NUM_LOCK);
|
2007-10-30 23:38:53 +01:00
|
|
|
}
|
|
|
|
} else {
|
2019-01-22 10:28:12 +01:00
|
|
|
if (qkbd_state_modifier_get(vs->vd->kbd, QKBD_MOD_NUMLOCK)) {
|
2014-05-21 13:18:20 +02:00
|
|
|
trace_vnc_key_sync_numlock(false);
|
2019-01-22 10:28:12 +01:00
|
|
|
press_key(vs, Q_KEY_CODE_NUM_LOCK);
|
2007-10-30 23:38:53 +01:00
|
|
|
}
|
|
|
|
}
|
2006-08-24 22:36:44 +02:00
|
|
|
}
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2011-01-14 10:56:54 +01:00
|
|
|
if (down && vs->vd->lock_key_sync &&
|
2013-04-25 07:29:11 +02:00
|
|
|
!vnc_has_feature(vs, VNC_FEATURE_LED_STATE) &&
|
2010-03-10 17:12:02 +01:00
|
|
|
((sym >= 'A' && sym <= 'Z') || (sym >= 'a' && sym <= 'z'))) {
|
2009-11-02 12:47:06 +01:00
|
|
|
/* If the capslock state needs to change then simulate an additional
|
|
|
|
keypress before sending this one. This will happen if the user
|
|
|
|
toggles capslock away from the VNC window.
|
|
|
|
*/
|
|
|
|
int uppercase = !!(sym >= 'A' && sym <= 'Z');
|
2019-01-22 10:28:12 +01:00
|
|
|
bool shift = qkbd_state_modifier_get(vs->vd->kbd, QKBD_MOD_SHIFT);
|
|
|
|
bool capslock = qkbd_state_modifier_get(vs->vd->kbd, QKBD_MOD_CAPSLOCK);
|
2009-11-02 12:47:06 +01:00
|
|
|
if (capslock) {
|
|
|
|
if (uppercase == shift) {
|
2014-05-21 13:18:20 +02:00
|
|
|
trace_vnc_key_sync_capslock(false);
|
2019-01-22 10:28:12 +01:00
|
|
|
press_key(vs, Q_KEY_CODE_CAPS_LOCK);
|
2009-11-02 12:47:06 +01:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (uppercase != shift) {
|
2014-05-21 13:18:20 +02:00
|
|
|
trace_vnc_key_sync_capslock(true);
|
2019-01-22 10:28:12 +01:00
|
|
|
press_key(vs, Q_KEY_CODE_CAPS_LOCK);
|
2009-11-02 12:47:06 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-01-22 10:28:12 +01:00
|
|
|
qkbd_state_key_event(vs->vd->kbd, qcode, down);
|
|
|
|
if (!qemu_console_is_graphic(NULL)) {
|
|
|
|
bool numlock = qkbd_state_modifier_get(vs->vd->kbd, QKBD_MOD_NUMLOCK);
|
|
|
|
bool control = qkbd_state_modifier_get(vs->vd->kbd, QKBD_MOD_CTRL);
|
2006-08-24 22:36:44 +02:00
|
|
|
/* QEMU console emulation */
|
|
|
|
if (down) {
|
|
|
|
switch (keycode) {
|
|
|
|
case 0x2a: /* Left Shift */
|
|
|
|
case 0x36: /* Right Shift */
|
|
|
|
case 0x1d: /* Left CTRL */
|
|
|
|
case 0x9d: /* Right CTRL */
|
|
|
|
case 0x38: /* Left ALT */
|
|
|
|
case 0xb8: /* Right ALT */
|
|
|
|
break;
|
|
|
|
case 0xc8:
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, QEMU_KEY_UP);
|
2006-08-24 22:36:44 +02:00
|
|
|
break;
|
|
|
|
case 0xd0:
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, QEMU_KEY_DOWN);
|
2006-08-24 22:36:44 +02:00
|
|
|
break;
|
|
|
|
case 0xcb:
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, QEMU_KEY_LEFT);
|
2006-08-24 22:36:44 +02:00
|
|
|
break;
|
|
|
|
case 0xcd:
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, QEMU_KEY_RIGHT);
|
2006-08-24 22:36:44 +02:00
|
|
|
break;
|
|
|
|
case 0xd3:
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, QEMU_KEY_DELETE);
|
2006-08-24 22:36:44 +02:00
|
|
|
break;
|
|
|
|
case 0xc7:
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, QEMU_KEY_HOME);
|
2006-08-24 22:36:44 +02:00
|
|
|
break;
|
|
|
|
case 0xcf:
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, QEMU_KEY_END);
|
2006-08-24 22:36:44 +02:00
|
|
|
break;
|
|
|
|
case 0xc9:
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, QEMU_KEY_PAGEUP);
|
2006-08-24 22:36:44 +02:00
|
|
|
break;
|
|
|
|
case 0xd1:
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, QEMU_KEY_PAGEDOWN);
|
2006-08-24 22:36:44 +02:00
|
|
|
break;
|
2009-06-11 11:32:14 +02:00
|
|
|
|
|
|
|
case 0x47:
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, numlock ? '7' : QEMU_KEY_HOME);
|
2009-06-11 11:32:14 +02:00
|
|
|
break;
|
|
|
|
case 0x48:
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, numlock ? '8' : QEMU_KEY_UP);
|
2009-06-11 11:32:14 +02:00
|
|
|
break;
|
|
|
|
case 0x49:
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, numlock ? '9' : QEMU_KEY_PAGEUP);
|
2009-06-11 11:32:14 +02:00
|
|
|
break;
|
|
|
|
case 0x4b:
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, numlock ? '4' : QEMU_KEY_LEFT);
|
2009-06-11 11:32:14 +02:00
|
|
|
break;
|
|
|
|
case 0x4c:
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, '5');
|
2009-06-11 11:32:14 +02:00
|
|
|
break;
|
|
|
|
case 0x4d:
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, numlock ? '6' : QEMU_KEY_RIGHT);
|
2009-06-11 11:32:14 +02:00
|
|
|
break;
|
|
|
|
case 0x4f:
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, numlock ? '1' : QEMU_KEY_END);
|
2009-06-11 11:32:14 +02:00
|
|
|
break;
|
|
|
|
case 0x50:
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, numlock ? '2' : QEMU_KEY_DOWN);
|
2009-06-11 11:32:14 +02:00
|
|
|
break;
|
|
|
|
case 0x51:
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, numlock ? '3' : QEMU_KEY_PAGEDOWN);
|
2009-06-11 11:32:14 +02:00
|
|
|
break;
|
|
|
|
case 0x52:
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, '0');
|
2009-06-11 11:32:14 +02:00
|
|
|
break;
|
|
|
|
case 0x53:
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, numlock ? '.' : QEMU_KEY_DELETE);
|
2009-06-11 11:32:14 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case 0xb5:
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, '/');
|
2009-06-11 11:32:14 +02:00
|
|
|
break;
|
|
|
|
case 0x37:
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, '*');
|
2009-06-11 11:32:14 +02:00
|
|
|
break;
|
|
|
|
case 0x4a:
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, '-');
|
2009-06-11 11:32:14 +02:00
|
|
|
break;
|
|
|
|
case 0x4e:
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, '+');
|
2009-06-11 11:32:14 +02:00
|
|
|
break;
|
|
|
|
case 0x9c:
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, '\n');
|
2009-06-11 11:32:14 +02:00
|
|
|
break;
|
|
|
|
|
2006-08-24 22:36:44 +02:00
|
|
|
default:
|
2011-11-08 10:02:16 +01:00
|
|
|
if (control) {
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, sym & 0x1f);
|
2011-11-08 10:02:16 +01:00
|
|
|
} else {
|
2023-08-30 11:38:20 +02:00
|
|
|
qemu_text_console_put_keysym(NULL, sym);
|
2011-11-08 10:02:16 +01:00
|
|
|
}
|
2006-08-24 22:36:44 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
|
|
|
|
2014-05-21 13:18:20 +02:00
|
|
|
static const char *code2name(int keycode)
|
|
|
|
{
|
2017-08-24 10:46:08 +02:00
|
|
|
return QKeyCode_str(qemu_input_key_number_to_qcode(keycode));
|
2014-05-21 13:18:20 +02:00
|
|
|
}
|
|
|
|
|
2006-05-01 23:44:22 +02:00
|
|
|
static void key_event(VncState *vs, int down, uint32_t sym)
|
|
|
|
{
|
2008-08-24 01:27:37 +02:00
|
|
|
int keycode;
|
2009-12-11 11:25:07 +01:00
|
|
|
int lsym = sym;
|
2008-08-24 01:27:37 +02:00
|
|
|
|
2013-03-14 14:27:08 +01:00
|
|
|
if (lsym >= 'A' && lsym <= 'Z' && qemu_console_is_graphic(NULL)) {
|
2009-12-11 11:25:07 +01:00
|
|
|
lsym = lsym - 'A' + 'a';
|
|
|
|
}
|
2008-08-24 01:27:37 +02:00
|
|
|
|
2018-02-22 08:05:13 +01:00
|
|
|
keycode = keysym2scancode(vs->vd->kbd_layout, lsym & 0xFFFF,
|
2019-01-22 10:28:14 +01:00
|
|
|
vs->vd->kbd, down) & SCANCODE_KEYMASK;
|
2014-05-21 13:18:20 +02:00
|
|
|
trace_vnc_key_event_map(down, sym, keycode, code2name(keycode));
|
2008-08-24 01:27:37 +02:00
|
|
|
do_key_event(vs, down, keycode, sym);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ext_key_event(VncState *vs, int down,
|
|
|
|
uint32_t sym, uint16_t keycode)
|
|
|
|
{
|
|
|
|
/* if the user specifies a keyboard layout, always use it */
|
2014-05-21 13:18:20 +02:00
|
|
|
if (keyboard_layout) {
|
2008-08-24 01:27:37 +02:00
|
|
|
key_event(vs, down, sym);
|
2014-05-21 13:18:20 +02:00
|
|
|
} else {
|
|
|
|
trace_vnc_key_event_ext(down, sym, keycode, code2name(keycode));
|
2008-08-24 01:27:37 +02:00
|
|
|
do_key_event(vs, down, keycode, sym);
|
2014-05-21 13:18:20 +02:00
|
|
|
}
|
2006-05-01 23:44:22 +02:00
|
|
|
}
|
|
|
|
|
2006-04-30 23:28:36 +02:00
|
|
|
static void framebuffer_update_request(VncState *vs, int incremental,
|
2014-06-30 10:57:51 +02:00
|
|
|
int x, int y, int w, int h)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
2014-06-30 10:57:51 +02:00
|
|
|
if (incremental) {
|
2017-12-18 20:12:21 +01:00
|
|
|
if (vs->update != VNC_STATE_UPDATE_FORCE) {
|
|
|
|
vs->update = VNC_STATE_UPDATE_INCREMENTAL;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
vs->update = VNC_STATE_UPDATE_FORCE;
|
|
|
|
vnc_set_area_dirty(vs->dirty, vs->vd, x, y, w, h);
|
2021-01-25 11:40:41 +01:00
|
|
|
if (vnc_has_feature(vs, VNC_FEATURE_RESIZE_EXT)) {
|
|
|
|
vnc_desktop_resize_ext(vs, 0);
|
|
|
|
}
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-08-24 01:27:37 +02:00
|
|
|
static void send_ext_key_event_ack(VncState *vs)
|
|
|
|
{
|
2010-07-07 20:58:02 +02:00
|
|
|
vnc_lock_output(vs);
|
2010-03-31 19:20:43 +02:00
|
|
|
vnc_write_u8(vs, VNC_MSG_SERVER_FRAMEBUFFER_UPDATE);
|
2008-08-24 01:27:37 +02:00
|
|
|
vnc_write_u8(vs, 0);
|
|
|
|
vnc_write_u16(vs, 1);
|
2013-02-28 17:16:48 +01:00
|
|
|
vnc_framebuffer_update(vs, 0, 0,
|
2014-06-30 10:57:51 +02:00
|
|
|
pixman_image_get_width(vs->vd->server),
|
|
|
|
pixman_image_get_height(vs->vd->server),
|
2009-02-02 16:58:29 +01:00
|
|
|
VNC_ENCODING_EXT_KEY_EVENT);
|
2010-07-07 20:58:02 +02:00
|
|
|
vnc_unlock_output(vs);
|
2008-08-24 01:27:37 +02:00
|
|
|
vnc_flush(vs);
|
|
|
|
}
|
|
|
|
|
2008-12-01 21:57:48 +01:00
|
|
|
static void send_ext_audio_ack(VncState *vs)
|
|
|
|
{
|
2010-07-07 20:58:02 +02:00
|
|
|
vnc_lock_output(vs);
|
2010-03-31 19:20:43 +02:00
|
|
|
vnc_write_u8(vs, VNC_MSG_SERVER_FRAMEBUFFER_UPDATE);
|
2008-12-01 21:57:48 +01:00
|
|
|
vnc_write_u8(vs, 0);
|
|
|
|
vnc_write_u16(vs, 1);
|
2013-02-28 17:16:48 +01:00
|
|
|
vnc_framebuffer_update(vs, 0, 0,
|
2014-06-30 10:57:51 +02:00
|
|
|
pixman_image_get_width(vs->vd->server),
|
|
|
|
pixman_image_get_height(vs->vd->server),
|
2009-02-02 16:58:29 +01:00
|
|
|
VNC_ENCODING_AUDIO);
|
2010-07-07 20:58:02 +02:00
|
|
|
vnc_unlock_output(vs);
|
2008-12-01 21:57:48 +01:00
|
|
|
vnc_flush(vs);
|
|
|
|
}
|
|
|
|
|
2020-12-11 17:08:25 +01:00
|
|
|
static void send_xvp_message(VncState *vs, int code)
|
|
|
|
{
|
|
|
|
vnc_lock_output(vs);
|
|
|
|
vnc_write_u8(vs, VNC_MSG_SERVER_XVP);
|
|
|
|
vnc_write_u8(vs, 0); /* pad */
|
|
|
|
vnc_write_u8(vs, 1); /* version */
|
|
|
|
vnc_write_u8(vs, code);
|
|
|
|
vnc_unlock_output(vs);
|
|
|
|
vnc_flush(vs);
|
|
|
|
}
|
|
|
|
|
2006-04-30 23:28:36 +02:00
|
|
|
static void set_encodings(VncState *vs, int32_t *encodings, size_t n_encodings)
|
|
|
|
{
|
|
|
|
int i;
|
2009-02-02 16:58:29 +01:00
|
|
|
unsigned int enc = 0;
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2009-02-02 16:58:29 +01:00
|
|
|
vs->features = 0;
|
2010-05-19 09:24:01 +02:00
|
|
|
vs->vnc_encoding = 0;
|
2019-08-31 17:39:22 +02:00
|
|
|
vs->tight->compression = 9;
|
|
|
|
vs->tight->quality = -1; /* Lossless by default */
|
2007-02-05 21:14:10 +01:00
|
|
|
vs->absolute = -1;
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2010-05-19 09:24:02 +02:00
|
|
|
/*
|
|
|
|
* Start from the end because the encodings are sent in order of preference.
|
2011-11-22 11:06:24 +01:00
|
|
|
* This way the preferred encoding (first encoding defined in the array)
|
2010-05-19 09:24:02 +02:00
|
|
|
* will be set at the end of the loop.
|
|
|
|
*/
|
2006-04-30 23:28:36 +02:00
|
|
|
for (i = n_encodings - 1; i >= 0; i--) {
|
2009-02-02 16:58:29 +01:00
|
|
|
enc = encodings[i];
|
|
|
|
switch (enc) {
|
|
|
|
case VNC_ENCODING_RAW:
|
2010-05-19 09:24:01 +02:00
|
|
|
vs->vnc_encoding = enc;
|
2009-02-02 16:58:29 +01:00
|
|
|
break;
|
|
|
|
case VNC_ENCODING_HEXTILE:
|
|
|
|
vs->features |= VNC_FEATURE_HEXTILE_MASK;
|
2010-05-19 09:24:01 +02:00
|
|
|
vs->vnc_encoding = enc;
|
2009-02-02 16:58:29 +01:00
|
|
|
break;
|
2010-05-19 09:24:10 +02:00
|
|
|
case VNC_ENCODING_TIGHT:
|
|
|
|
vs->features |= VNC_FEATURE_TIGHT_MASK;
|
|
|
|
vs->vnc_encoding = enc;
|
|
|
|
break;
|
2022-04-08 09:13:34 +02:00
|
|
|
#ifdef CONFIG_PNG
|
2010-07-07 20:57:56 +02:00
|
|
|
case VNC_ENCODING_TIGHT_PNG:
|
|
|
|
vs->features |= VNC_FEATURE_TIGHT_PNG_MASK;
|
|
|
|
vs->vnc_encoding = enc;
|
|
|
|
break;
|
2012-05-16 14:54:25 +02:00
|
|
|
#endif
|
2009-02-02 16:58:54 +01:00
|
|
|
case VNC_ENCODING_ZLIB:
|
2020-01-21 06:00:52 +01:00
|
|
|
/*
|
|
|
|
* VNC_ENCODING_ZRLE compresses better than VNC_ENCODING_ZLIB.
|
|
|
|
* So prioritize ZRLE, even if the client hints that it prefers
|
|
|
|
* ZLIB.
|
|
|
|
*/
|
|
|
|
if ((vs->features & VNC_FEATURE_ZRLE_MASK) == 0) {
|
|
|
|
vs->features |= VNC_FEATURE_ZLIB_MASK;
|
|
|
|
vs->vnc_encoding = enc;
|
|
|
|
}
|
2009-02-02 16:58:54 +01:00
|
|
|
break;
|
2011-02-04 09:06:01 +01:00
|
|
|
case VNC_ENCODING_ZRLE:
|
|
|
|
vs->features |= VNC_FEATURE_ZRLE_MASK;
|
|
|
|
vs->vnc_encoding = enc;
|
|
|
|
break;
|
|
|
|
case VNC_ENCODING_ZYWRLE:
|
|
|
|
vs->features |= VNC_FEATURE_ZYWRLE_MASK;
|
|
|
|
vs->vnc_encoding = enc;
|
|
|
|
break;
|
2009-02-02 16:58:29 +01:00
|
|
|
case VNC_ENCODING_DESKTOPRESIZE:
|
|
|
|
vs->features |= VNC_FEATURE_RESIZE_MASK;
|
|
|
|
break;
|
2021-01-12 14:41:20 +01:00
|
|
|
case VNC_ENCODING_DESKTOP_RESIZE_EXT:
|
|
|
|
vs->features |= VNC_FEATURE_RESIZE_EXT_MASK;
|
|
|
|
break;
|
2009-02-02 16:58:29 +01:00
|
|
|
case VNC_ENCODING_POINTER_TYPE_CHANGE:
|
|
|
|
vs->features |= VNC_FEATURE_POINTER_TYPE_CHANGE_MASK;
|
|
|
|
break;
|
2010-05-21 11:54:34 +02:00
|
|
|
case VNC_ENCODING_RICH_CURSOR:
|
|
|
|
vs->features |= VNC_FEATURE_RICH_CURSOR_MASK;
|
2020-12-08 12:57:34 +01:00
|
|
|
break;
|
|
|
|
case VNC_ENCODING_ALPHA_CURSOR:
|
|
|
|
vs->features |= VNC_FEATURE_ALPHA_CURSOR_MASK;
|
2010-05-21 11:54:34 +02:00
|
|
|
break;
|
2009-02-02 16:58:29 +01:00
|
|
|
case VNC_ENCODING_EXT_KEY_EVENT:
|
2008-08-24 01:27:37 +02:00
|
|
|
send_ext_key_event_ack(vs);
|
|
|
|
break;
|
2009-02-02 16:58:29 +01:00
|
|
|
case VNC_ENCODING_AUDIO:
|
2023-09-25 13:08:27 +02:00
|
|
|
if (vs->vd->audio_state) {
|
|
|
|
vs->features |= VNC_FEATURE_AUDIO_MASK;
|
|
|
|
send_ext_audio_ack(vs);
|
|
|
|
}
|
2008-12-01 21:57:48 +01:00
|
|
|
break;
|
2009-02-02 16:58:29 +01:00
|
|
|
case VNC_ENCODING_WMVi:
|
|
|
|
vs->features |= VNC_FEATURE_WMVI_MASK;
|
2008-09-15 18:05:16 +02:00
|
|
|
break;
|
2013-04-25 07:29:10 +02:00
|
|
|
case VNC_ENCODING_LED_STATE:
|
|
|
|
vs->features |= VNC_FEATURE_LED_STATE_MASK;
|
|
|
|
break;
|
2020-12-11 17:08:25 +01:00
|
|
|
case VNC_ENCODING_XVP:
|
|
|
|
if (vs->vd->power_control) {
|
2023-09-25 13:05:58 +02:00
|
|
|
vs->features |= VNC_FEATURE_XVP_MASK;
|
2020-12-11 17:08:25 +01:00
|
|
|
send_xvp_message(vs, VNC_XVP_CODE_INIT);
|
|
|
|
}
|
|
|
|
break;
|
2021-05-19 07:39:38 +02:00
|
|
|
case VNC_ENCODING_CLIPBOARD_EXT:
|
|
|
|
vs->features |= VNC_FEATURE_CLIPBOARD_EXT_MASK;
|
|
|
|
vnc_server_cut_text_caps(vs);
|
|
|
|
break;
|
2009-02-02 16:58:43 +01:00
|
|
|
case VNC_ENCODING_COMPRESSLEVEL0 ... VNC_ENCODING_COMPRESSLEVEL0 + 9:
|
2019-08-31 17:39:22 +02:00
|
|
|
vs->tight->compression = (enc & 0x0F);
|
2009-02-02 16:58:43 +01:00
|
|
|
break;
|
|
|
|
case VNC_ENCODING_QUALITYLEVEL0 ... VNC_ENCODING_QUALITYLEVEL0 + 9:
|
2011-02-04 09:05:54 +01:00
|
|
|
if (vs->vd->lossy) {
|
2019-08-31 17:39:22 +02:00
|
|
|
vs->tight->quality = (enc & 0x0F);
|
2011-02-04 09:05:54 +01:00
|
|
|
}
|
2009-02-02 16:58:43 +01:00
|
|
|
break;
|
2009-02-02 16:58:29 +01:00
|
|
|
default:
|
|
|
|
VNC_DEBUG("Unknown encoding: %d (0x%.8x): %d\n", i, enc, enc);
|
|
|
|
break;
|
|
|
|
}
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
2021-01-25 11:40:40 +01:00
|
|
|
vnc_desktop_resize(vs);
|
2011-06-20 14:06:26 +02:00
|
|
|
check_pointer_type_change(&vs->mouse_mode_notifier, NULL);
|
2021-01-25 11:40:40 +01:00
|
|
|
vnc_led_state_change(vs);
|
|
|
|
vnc_cursor_define(vs);
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
|
|
|
|
2009-01-15 23:17:38 +01:00
|
|
|
static void set_pixel_conversion(VncState *vs)
|
|
|
|
{
|
2012-10-10 13:29:43 +02:00
|
|
|
pixman_format_code_t fmt = qemu_pixman_get_format(&vs->client_pf);
|
|
|
|
|
|
|
|
if (fmt == VNC_SERVER_FB_FORMAT) {
|
2009-01-15 23:17:38 +01:00
|
|
|
vs->write_pixels = vnc_write_pixels_copy;
|
2010-05-03 14:31:34 +02:00
|
|
|
vnc_hextile_set_pixel_conversion(vs, 0);
|
2009-01-15 23:17:38 +01:00
|
|
|
} else {
|
|
|
|
vs->write_pixels = vnc_write_pixels_generic;
|
2010-05-03 14:31:34 +02:00
|
|
|
vnc_hextile_set_pixel_conversion(vs, 1);
|
2009-01-15 23:17:38 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-05-24 16:19:19 +02:00
|
|
|
static void send_color_map(VncState *vs)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2020-11-16 15:13:38 +01:00
|
|
|
vnc_lock_output(vs);
|
2016-05-24 16:19:19 +02:00
|
|
|
vnc_write_u8(vs, VNC_MSG_SERVER_SET_COLOUR_MAP_ENTRIES);
|
|
|
|
vnc_write_u8(vs, 0); /* padding */
|
|
|
|
vnc_write_u16(vs, 0); /* first color */
|
|
|
|
vnc_write_u16(vs, 256); /* # of colors */
|
|
|
|
|
|
|
|
for (i = 0; i < 256; i++) {
|
|
|
|
PixelFormat *pf = &vs->client_pf;
|
|
|
|
|
|
|
|
vnc_write_u16(vs, (((i >> pf->rshift) & pf->rmax) << (16 - pf->rbits)));
|
|
|
|
vnc_write_u16(vs, (((i >> pf->gshift) & pf->gmax) << (16 - pf->gbits)));
|
|
|
|
vnc_write_u16(vs, (((i >> pf->bshift) & pf->bmax) << (16 - pf->bbits)));
|
|
|
|
}
|
2020-11-16 15:13:38 +01:00
|
|
|
vnc_unlock_output(vs);
|
2016-05-24 16:19:19 +02:00
|
|
|
}
|
|
|
|
|
2016-06-06 11:18:45 +02:00
|
|
|
static void set_pixel_format(VncState *vs, int bits_per_pixel,
|
2009-03-06 21:27:40 +01:00
|
|
|
int big_endian_flag, int true_color_flag,
|
|
|
|
int red_max, int green_max, int blue_max,
|
|
|
|
int red_shift, int green_shift, int blue_shift)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
2006-05-14 20:11:49 +02:00
|
|
|
if (!true_color_flag) {
|
2016-05-24 16:19:19 +02:00
|
|
|
/* Expose a reasonable default 256 color map */
|
|
|
|
bits_per_pixel = 8;
|
|
|
|
red_max = 7;
|
|
|
|
green_max = 7;
|
|
|
|
blue_max = 3;
|
|
|
|
red_shift = 0;
|
|
|
|
green_shift = 3;
|
|
|
|
blue_shift = 6;
|
2006-05-14 20:11:49 +02:00
|
|
|
}
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2014-10-27 12:41:44 +01:00
|
|
|
switch (bits_per_pixel) {
|
|
|
|
case 8:
|
|
|
|
case 16:
|
|
|
|
case 32:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
vnc_client_error(vs);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-12-03 14:24:17 +01:00
|
|
|
vs->client_pf.rmax = red_max ? red_max : 0xFF;
|
2017-03-13 15:33:25 +01:00
|
|
|
vs->client_pf.rbits = ctpopl(red_max);
|
2012-10-10 13:29:43 +02:00
|
|
|
vs->client_pf.rshift = red_shift;
|
|
|
|
vs->client_pf.rmask = red_max << red_shift;
|
2015-12-03 14:24:17 +01:00
|
|
|
vs->client_pf.gmax = green_max ? green_max : 0xFF;
|
2017-03-13 15:33:25 +01:00
|
|
|
vs->client_pf.gbits = ctpopl(green_max);
|
2012-10-10 13:29:43 +02:00
|
|
|
vs->client_pf.gshift = green_shift;
|
|
|
|
vs->client_pf.gmask = green_max << green_shift;
|
2015-12-03 14:24:17 +01:00
|
|
|
vs->client_pf.bmax = blue_max ? blue_max : 0xFF;
|
2017-03-13 15:33:25 +01:00
|
|
|
vs->client_pf.bbits = ctpopl(blue_max);
|
2012-10-10 13:29:43 +02:00
|
|
|
vs->client_pf.bshift = blue_shift;
|
|
|
|
vs->client_pf.bmask = blue_max << blue_shift;
|
|
|
|
vs->client_pf.bits_per_pixel = bits_per_pixel;
|
|
|
|
vs->client_pf.bytes_per_pixel = bits_per_pixel / 8;
|
|
|
|
vs->client_pf.depth = bits_per_pixel == 32 ? 24 : bits_per_pixel;
|
|
|
|
vs->client_be = big_endian_flag;
|
2009-01-15 23:17:38 +01:00
|
|
|
|
2016-05-24 16:19:19 +02:00
|
|
|
if (!true_color_flag) {
|
|
|
|
send_color_map(vs);
|
|
|
|
}
|
|
|
|
|
2009-01-15 23:17:38 +01:00
|
|
|
set_pixel_conversion(vs);
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2014-09-18 12:54:49 +02:00
|
|
|
graphic_hw_invalidate(vs->vd->dcl.con);
|
|
|
|
graphic_hw_update(vs->vd->dcl.con);
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
|
|
|
|
2008-09-15 18:05:16 +02:00
|
|
|
static void pixel_format_message (VncState *vs) {
|
|
|
|
char pad[3] = { 0, 0, 0 };
|
|
|
|
|
2012-10-10 13:29:43 +02:00
|
|
|
vs->client_pf = qemu_default_pixelformat(32);
|
|
|
|
|
|
|
|
vnc_write_u8(vs, vs->client_pf.bits_per_pixel); /* bits-per-pixel */
|
|
|
|
vnc_write_u8(vs, vs->client_pf.depth); /* depth */
|
2008-09-15 18:05:16 +02:00
|
|
|
|
2022-03-23 16:57:17 +01:00
|
|
|
#if HOST_BIG_ENDIAN
|
2008-09-15 18:05:16 +02:00
|
|
|
vnc_write_u8(vs, 1); /* big-endian-flag */
|
|
|
|
#else
|
|
|
|
vnc_write_u8(vs, 0); /* big-endian-flag */
|
|
|
|
#endif
|
|
|
|
vnc_write_u8(vs, 1); /* true-color-flag */
|
2012-10-10 13:29:43 +02:00
|
|
|
vnc_write_u16(vs, vs->client_pf.rmax); /* red-max */
|
|
|
|
vnc_write_u16(vs, vs->client_pf.gmax); /* green-max */
|
|
|
|
vnc_write_u16(vs, vs->client_pf.bmax); /* blue-max */
|
|
|
|
vnc_write_u8(vs, vs->client_pf.rshift); /* red-shift */
|
|
|
|
vnc_write_u8(vs, vs->client_pf.gshift); /* green-shift */
|
|
|
|
vnc_write_u8(vs, vs->client_pf.bshift); /* blue-shift */
|
|
|
|
vnc_write(vs, pad, 3); /* padding */
|
2010-05-03 14:31:34 +02:00
|
|
|
|
|
|
|
vnc_hextile_set_pixel_conversion(vs, 0);
|
2008-09-15 18:05:16 +02:00
|
|
|
vs->write_pixels = vnc_write_pixels_copy;
|
|
|
|
}
|
|
|
|
|
2009-02-16 15:59:30 +01:00
|
|
|
static void vnc_colordepth(VncState *vs)
|
2008-09-15 18:03:41 +02:00
|
|
|
{
|
2009-02-16 15:59:30 +01:00
|
|
|
if (vnc_has_feature(vs, VNC_FEATURE_WMVI)) {
|
2008-09-15 18:05:16 +02:00
|
|
|
/* Sending a WMVi message to notify the client*/
|
2010-07-07 20:58:02 +02:00
|
|
|
vnc_lock_output(vs);
|
2010-03-31 19:20:43 +02:00
|
|
|
vnc_write_u8(vs, VNC_MSG_SERVER_FRAMEBUFFER_UPDATE);
|
2008-09-15 18:05:16 +02:00
|
|
|
vnc_write_u8(vs, 0);
|
|
|
|
vnc_write_u16(vs, 1); /* number of rects */
|
2013-02-28 17:16:48 +01:00
|
|
|
vnc_framebuffer_update(vs, 0, 0,
|
2021-03-11 19:29:56 +01:00
|
|
|
vs->client_width,
|
|
|
|
vs->client_height,
|
2013-02-28 17:16:48 +01:00
|
|
|
VNC_ENCODING_WMVi);
|
2008-09-15 18:05:16 +02:00
|
|
|
pixel_format_message(vs);
|
2010-07-07 20:58:02 +02:00
|
|
|
vnc_unlock_output(vs);
|
2008-09-15 18:05:16 +02:00
|
|
|
vnc_flush(vs);
|
2008-09-15 18:03:41 +02:00
|
|
|
} else {
|
2009-01-15 23:17:38 +01:00
|
|
|
set_pixel_conversion(vs);
|
2008-09-15 18:03:41 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-12-16 04:02:09 +01:00
|
|
|
static int protocol_client_msg(VncState *vs, uint8_t *data, size_t len)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
uint16_t limit;
|
2018-02-05 12:49:37 +01:00
|
|
|
uint32_t freq;
|
2009-08-03 11:56:01 +02:00
|
|
|
VncDisplay *vd = vs->vd;
|
|
|
|
|
|
|
|
if (data[0] > 3) {
|
2013-03-14 11:56:16 +01:00
|
|
|
update_displaychangelistener(&vd->dcl, VNC_REFRESH_INTERVAL_BASE);
|
2009-08-03 11:56:01 +02:00
|
|
|
}
|
2006-04-30 23:28:36 +02:00
|
|
|
|
|
|
|
switch (data[0]) {
|
2010-03-31 19:20:43 +02:00
|
|
|
case VNC_MSG_CLIENT_SET_PIXEL_FORMAT:
|
2009-03-06 21:27:40 +01:00
|
|
|
if (len == 1)
|
|
|
|
return 20;
|
|
|
|
|
2016-06-06 11:18:45 +02:00
|
|
|
set_pixel_format(vs, read_u8(data, 4),
|
2009-03-06 21:27:40 +01:00
|
|
|
read_u8(data, 6), read_u8(data, 7),
|
|
|
|
read_u16(data, 8), read_u16(data, 10),
|
|
|
|
read_u16(data, 12), read_u8(data, 14),
|
|
|
|
read_u8(data, 15), read_u8(data, 16));
|
|
|
|
break;
|
2010-03-31 19:20:43 +02:00
|
|
|
case VNC_MSG_CLIENT_SET_ENCODINGS:
|
2009-03-06 21:27:40 +01:00
|
|
|
if (len == 1)
|
|
|
|
return 4;
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2009-03-06 21:27:40 +01:00
|
|
|
if (len == 4) {
|
2008-12-22 22:06:23 +01:00
|
|
|
limit = read_u16(data, 2);
|
|
|
|
if (limit > 0)
|
|
|
|
return 4 + (limit * 4);
|
|
|
|
} else
|
|
|
|
limit = read_u16(data, 2);
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2009-03-06 21:27:40 +01:00
|
|
|
for (i = 0; i < limit; i++) {
|
|
|
|
int32_t val = read_s32(data, 4 + (i * 4));
|
|
|
|
memcpy(data + 4 + (i * 4), &val, sizeof(val));
|
|
|
|
}
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2009-03-06 21:27:40 +01:00
|
|
|
set_encodings(vs, (int32_t *)(data + 4), limit);
|
|
|
|
break;
|
2010-03-31 19:20:43 +02:00
|
|
|
case VNC_MSG_CLIENT_FRAMEBUFFER_UPDATE_REQUEST:
|
2009-03-06 21:27:40 +01:00
|
|
|
if (len == 1)
|
|
|
|
return 10;
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2009-03-06 21:27:40 +01:00
|
|
|
framebuffer_update_request(vs,
|
|
|
|
read_u8(data, 1), read_u16(data, 2), read_u16(data, 4),
|
|
|
|
read_u16(data, 6), read_u16(data, 8));
|
|
|
|
break;
|
2010-03-31 19:20:43 +02:00
|
|
|
case VNC_MSG_CLIENT_KEY_EVENT:
|
2009-03-06 21:27:40 +01:00
|
|
|
if (len == 1)
|
|
|
|
return 8;
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2009-03-06 21:27:40 +01:00
|
|
|
key_event(vs, read_u8(data, 1), read_u32(data, 4));
|
|
|
|
break;
|
2010-03-31 19:20:43 +02:00
|
|
|
case VNC_MSG_CLIENT_POINTER_EVENT:
|
2009-03-06 21:27:40 +01:00
|
|
|
if (len == 1)
|
|
|
|
return 6;
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2009-03-06 21:27:40 +01:00
|
|
|
pointer_event(vs, read_u8(data, 1), read_u16(data, 2), read_u16(data, 4));
|
|
|
|
break;
|
2010-03-31 19:20:43 +02:00
|
|
|
case VNC_MSG_CLIENT_CUT_TEXT:
|
2014-06-30 10:07:54 +02:00
|
|
|
if (len == 1) {
|
2009-03-06 21:27:40 +01:00
|
|
|
return 8;
|
2014-06-30 10:07:54 +02:00
|
|
|
}
|
2022-09-25 22:45:11 +02:00
|
|
|
uint32_t dlen = abs(read_s32(data, 4));
|
2009-03-06 21:27:40 +01:00
|
|
|
if (len == 8) {
|
2014-06-30 10:07:54 +02:00
|
|
|
if (dlen > (1 << 20)) {
|
|
|
|
error_report("vnc: client_cut_text msg payload has %u bytes"
|
|
|
|
" which exceeds our limit of 1MB.", dlen);
|
|
|
|
vnc_client_error(vs);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (dlen > 0) {
|
2007-09-13 14:41:42 +02:00
|
|
|
return 8 + dlen;
|
2014-06-30 10:07:54 +02:00
|
|
|
}
|
2007-09-13 14:41:42 +02:00
|
|
|
}
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2021-05-19 07:39:38 +02:00
|
|
|
if (read_s32(data, 4) < 0) {
|
2022-09-25 22:45:11 +02:00
|
|
|
if (dlen < 4) {
|
|
|
|
error_report("vnc: malformed payload (header less than 4 bytes)"
|
|
|
|
" in extended clipboard pseudo-encoding.");
|
|
|
|
vnc_client_error(vs);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
vnc_client_cut_text_ext(vs, dlen, read_u32(data, 8), data + 12);
|
2021-05-19 07:39:38 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
vnc_client_cut_text(vs, read_u32(data, 4), data + 8);
|
2009-03-06 21:27:40 +01:00
|
|
|
break;
|
2020-12-11 17:08:25 +01:00
|
|
|
case VNC_MSG_CLIENT_XVP:
|
2023-09-25 13:05:58 +02:00
|
|
|
if (!vnc_has_feature(vs, VNC_FEATURE_XVP)) {
|
2020-12-11 17:08:25 +01:00
|
|
|
error_report("vnc: xvp client message while disabled");
|
|
|
|
vnc_client_error(vs);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (len == 1) {
|
|
|
|
return 4;
|
|
|
|
}
|
|
|
|
if (len == 4) {
|
|
|
|
uint8_t version = read_u8(data, 2);
|
|
|
|
uint8_t action = read_u8(data, 3);
|
|
|
|
|
|
|
|
if (version != 1) {
|
|
|
|
error_report("vnc: xvp client message version %d != 1",
|
|
|
|
version);
|
|
|
|
vnc_client_error(vs);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (action) {
|
|
|
|
case VNC_XVP_ACTION_SHUTDOWN:
|
|
|
|
qemu_system_powerdown_request();
|
|
|
|
break;
|
|
|
|
case VNC_XVP_ACTION_REBOOT:
|
|
|
|
send_xvp_message(vs, VNC_XVP_CODE_FAIL);
|
|
|
|
break;
|
|
|
|
case VNC_XVP_ACTION_RESET:
|
|
|
|
qemu_system_reset_request(SHUTDOWN_CAUSE_HOST_QMP_SYSTEM_RESET);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
send_xvp_message(vs, VNC_XVP_CODE_FAIL);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
2010-03-31 19:20:43 +02:00
|
|
|
case VNC_MSG_CLIENT_QEMU:
|
2008-08-24 01:27:37 +02:00
|
|
|
if (len == 1)
|
|
|
|
return 2;
|
|
|
|
|
|
|
|
switch (read_u8(data, 1)) {
|
2010-03-31 19:20:43 +02:00
|
|
|
case VNC_MSG_CLIENT_QEMU_EXT_KEY_EVENT:
|
2008-08-24 01:27:37 +02:00
|
|
|
if (len == 2)
|
|
|
|
return 12;
|
|
|
|
|
|
|
|
ext_key_event(vs, read_u16(data, 2),
|
|
|
|
read_u32(data, 4), read_u32(data, 8));
|
|
|
|
break;
|
2010-03-31 19:20:43 +02:00
|
|
|
case VNC_MSG_CLIENT_QEMU_AUDIO:
|
2023-09-25 13:08:27 +02:00
|
|
|
if (!vnc_has_feature(vs, VNC_FEATURE_AUDIO)) {
|
|
|
|
error_report("Audio message %d with audio disabled", read_u8(data, 2));
|
|
|
|
vnc_client_error(vs);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2008-12-01 21:57:48 +01:00
|
|
|
if (len == 2)
|
|
|
|
return 4;
|
|
|
|
|
|
|
|
switch (read_u16 (data, 2)) {
|
2010-03-31 19:20:43 +02:00
|
|
|
case VNC_MSG_CLIENT_QEMU_AUDIO_ENABLE:
|
2021-03-11 19:29:54 +01:00
|
|
|
trace_vnc_msg_client_audio_enable(vs, vs->ioc);
|
2008-12-01 21:57:48 +01:00
|
|
|
audio_add(vs);
|
|
|
|
break;
|
2010-03-31 19:20:43 +02:00
|
|
|
case VNC_MSG_CLIENT_QEMU_AUDIO_DISABLE:
|
2021-03-11 19:29:54 +01:00
|
|
|
trace_vnc_msg_client_audio_disable(vs, vs->ioc);
|
2008-12-01 21:57:48 +01:00
|
|
|
audio_del(vs);
|
|
|
|
break;
|
2010-03-31 19:20:43 +02:00
|
|
|
case VNC_MSG_CLIENT_QEMU_AUDIO_SET_FORMAT:
|
2008-12-01 21:57:48 +01:00
|
|
|
if (len == 4)
|
|
|
|
return 10;
|
|
|
|
switch (read_u8(data, 4)) {
|
2019-03-08 23:34:13 +01:00
|
|
|
case 0: vs->as.fmt = AUDIO_FORMAT_U8; break;
|
|
|
|
case 1: vs->as.fmt = AUDIO_FORMAT_S8; break;
|
|
|
|
case 2: vs->as.fmt = AUDIO_FORMAT_U16; break;
|
|
|
|
case 3: vs->as.fmt = AUDIO_FORMAT_S16; break;
|
|
|
|
case 4: vs->as.fmt = AUDIO_FORMAT_U32; break;
|
|
|
|
case 5: vs->as.fmt = AUDIO_FORMAT_S32; break;
|
2008-12-01 21:57:48 +01:00
|
|
|
default:
|
2015-03-17 14:42:54 +01:00
|
|
|
VNC_DEBUG("Invalid audio format %d\n", read_u8(data, 4));
|
2008-12-01 21:57:48 +01:00
|
|
|
vnc_client_error(vs);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
vs->as.nchannels = read_u8(data, 5);
|
|
|
|
if (vs->as.nchannels != 1 && vs->as.nchannels != 2) {
|
2017-12-20 15:06:18 +01:00
|
|
|
VNC_DEBUG("Invalid audio channel count %d\n",
|
2015-03-17 14:42:54 +01:00
|
|
|
read_u8(data, 5));
|
2008-12-01 21:57:48 +01:00
|
|
|
vnc_client_error(vs);
|
|
|
|
break;
|
|
|
|
}
|
2018-02-05 12:49:37 +01:00
|
|
|
freq = read_u32(data, 6);
|
|
|
|
/* No official limit for protocol, but 48khz is a sensible
|
|
|
|
* upper bound for trustworthy clients, and this limit
|
|
|
|
* protects calculations involving 'vs->as.freq' later.
|
|
|
|
*/
|
|
|
|
if (freq > 48000) {
|
|
|
|
VNC_DEBUG("Invalid audio frequency %u > 48000", freq);
|
|
|
|
vnc_client_error(vs);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
vs->as.freq = freq;
|
2021-03-11 19:29:54 +01:00
|
|
|
trace_vnc_msg_client_audio_format(
|
|
|
|
vs, vs->ioc, vs->as.fmt, vs->as.nchannels, vs->as.freq);
|
2008-12-01 21:57:48 +01:00
|
|
|
break;
|
|
|
|
default:
|
2023-09-25 13:06:46 +02:00
|
|
|
VNC_DEBUG("Invalid audio message %d\n", read_u8(data, 2));
|
2008-12-01 21:57:48 +01:00
|
|
|
vnc_client_error(vs);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
2008-08-24 01:27:37 +02:00
|
|
|
default:
|
2015-03-17 14:42:54 +01:00
|
|
|
VNC_DEBUG("Msg: %d\n", read_u16(data, 0));
|
2008-08-24 01:27:37 +02:00
|
|
|
vnc_client_error(vs);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
2021-01-12 14:41:20 +01:00
|
|
|
case VNC_MSG_CLIENT_SET_DESKTOP_SIZE:
|
|
|
|
{
|
|
|
|
size_t size;
|
|
|
|
uint8_t screens;
|
2021-03-11 19:29:54 +01:00
|
|
|
int w, h;
|
2021-01-12 14:41:20 +01:00
|
|
|
|
|
|
|
if (len < 8) {
|
|
|
|
return 8;
|
|
|
|
}
|
|
|
|
|
|
|
|
screens = read_u8(data, 6);
|
|
|
|
size = 8 + screens * 16;
|
|
|
|
if (len < size) {
|
|
|
|
return size;
|
|
|
|
}
|
2021-03-11 19:29:54 +01:00
|
|
|
w = read_u16(data, 2);
|
|
|
|
h = read_u16(data, 4);
|
2021-01-12 14:41:20 +01:00
|
|
|
|
2021-03-11 19:29:54 +01:00
|
|
|
trace_vnc_msg_client_set_desktop_size(vs, vs->ioc, w, h, screens);
|
2021-01-12 14:41:20 +01:00
|
|
|
if (dpy_ui_info_supported(vs->vd->dcl.con)) {
|
|
|
|
QemuUIInfo info;
|
|
|
|
memset(&info, 0, sizeof(info));
|
2021-03-11 19:29:54 +01:00
|
|
|
info.width = w;
|
|
|
|
info.height = h;
|
2021-04-13 18:39:11 +02:00
|
|
|
dpy_set_ui_info(vs->vd->dcl.con, &info, false);
|
2021-01-12 14:41:20 +01:00
|
|
|
vnc_desktop_resize_ext(vs, 4 /* Request forwarded */);
|
|
|
|
} else {
|
|
|
|
vnc_desktop_resize_ext(vs, 3 /* Invalid screen layout */);
|
|
|
|
}
|
|
|
|
|
|
|
|
break;
|
|
|
|
}
|
2006-04-30 23:28:36 +02:00
|
|
|
default:
|
2015-03-17 14:42:54 +01:00
|
|
|
VNC_DEBUG("Msg: %d\n", data[0]);
|
2009-03-06 21:27:40 +01:00
|
|
|
vnc_client_error(vs);
|
|
|
|
break;
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
2007-09-16 23:08:06 +02:00
|
|
|
|
ui: fix VNC client throttling when audio capture is active
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check must be disabled if audio capture is
enabled, because when streaming audio the output buffer offset will rarely be
zero due to queued audio data, and so this would starve framebuffer updates.
As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then enable audio capture, and simply never
read data back from the server. This can easily make QEMU's VNC server send
buffer consume 100MB of RAM per second, until the OOM killer starts reaping
processes (hopefully the rogue QEMU process, but it might pick others...).
To address this we make the throttling more intelligent, so we can throttle
when audio capture is active too. To determine how to throttle incremental
updates or audio data, we calculate a size threshold. Normally the threshold is
the approximate number of bytes associated with a single complete framebuffer
update. ie width * height * bytes per pixel. We'll send incremental updates
until we hit this threshold, at which point we'll stop sending updates until
data has been written to the wire, causing the output buffer offset to fall
back below the threshold.
If audio capture is enabled, we increase the size of the threshold to also
allow for upto 1 seconds worth of audio data samples. ie nchannels * bytes
per sample * frequency. This allows the output buffer to have a mixture of
incremental framebuffer updates and audio data queued, but once the threshold
is exceeded, audio data will be dropped and incremental updates will be
throttled.
This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.
This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:
commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Oct 9 14:43:42 2017 +0100
io: monitor encoutput buffer size from websocket GSource
This new general memory usage flaw has been assigned CVE-2017-15124, and is
partially fixed by this patch.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20171218191228.31018-10-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-12-18 20:12:24 +01:00
|
|
|
vnc_update_throttle_offset(vs);
|
2006-04-30 23:28:36 +02:00
|
|
|
vnc_read_when(vs, protocol_client_msg, 1);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-12-16 04:02:09 +01:00
|
|
|
static int protocol_client_init(VncState *vs, uint8_t *data, size_t len)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
2007-03-19 16:17:08 +01:00
|
|
|
char buf[1024];
|
2011-11-24 18:10:49 +01:00
|
|
|
VncShareMode mode;
|
2007-03-19 16:17:08 +01:00
|
|
|
int size;
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2011-11-24 18:10:49 +01:00
|
|
|
mode = data[0] ? VNC_SHARE_MODE_SHARED : VNC_SHARE_MODE_EXCLUSIVE;
|
|
|
|
switch (vs->vd->share_policy) {
|
|
|
|
case VNC_SHARE_POLICY_IGNORE:
|
|
|
|
/*
|
|
|
|
* Ignore the shared flag. Nothing to do here.
|
|
|
|
*
|
|
|
|
* Doesn't conform to the rfb spec but is traditional qemu
|
|
|
|
* behavior, thus left here as option for compatibility
|
|
|
|
* reasons.
|
|
|
|
*/
|
|
|
|
break;
|
|
|
|
case VNC_SHARE_POLICY_ALLOW_EXCLUSIVE:
|
|
|
|
/*
|
|
|
|
* Policy: Allow clients ask for exclusive access.
|
|
|
|
*
|
|
|
|
* Implementation: When a client asks for exclusive access,
|
|
|
|
* disconnect all others. Shared connects are allowed as long
|
|
|
|
* as no exclusive connection exists.
|
|
|
|
*
|
|
|
|
* This is how the rfb spec suggests to handle the shared flag.
|
|
|
|
*/
|
|
|
|
if (mode == VNC_SHARE_MODE_EXCLUSIVE) {
|
|
|
|
VncState *client;
|
|
|
|
QTAILQ_FOREACH(client, &vs->vd->clients, next) {
|
|
|
|
if (vs == client) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (client->share_mode != VNC_SHARE_MODE_EXCLUSIVE &&
|
|
|
|
client->share_mode != VNC_SHARE_MODE_SHARED) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
vnc_disconnect_start(client);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (mode == VNC_SHARE_MODE_SHARED) {
|
|
|
|
if (vs->vd->num_exclusive > 0) {
|
|
|
|
vnc_disconnect_start(vs);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case VNC_SHARE_POLICY_FORCE_SHARED:
|
|
|
|
/*
|
|
|
|
* Policy: Shared connects only.
|
|
|
|
* Implementation: Disallow clients asking for exclusive access.
|
|
|
|
*
|
|
|
|
* Useful for shared desktop sessions where you don't want
|
|
|
|
* someone forgetting to say -shared when running the vnc
|
|
|
|
* client disconnect everybody else.
|
|
|
|
*/
|
|
|
|
if (mode == VNC_SHARE_MODE_EXCLUSIVE) {
|
|
|
|
vnc_disconnect_start(vs);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
vnc_set_share_mode(vs, mode);
|
|
|
|
|
2014-10-02 12:09:34 +02:00
|
|
|
if (vs->vd->num_shared > vs->vd->connections_limit) {
|
|
|
|
vnc_disconnect_start(vs);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
ui: avoid sign extension using client width/height
Pixman returns a signed int for the image width/height, but the VNC
protocol only permits a unsigned int16. Effective framebuffer size
is determined by the guest, limited by the video RAM size, so the
dimensions are unlikely to exceed the range of an unsigned int16,
but this is not currently validated.
With the current use of 'int' for client width/height, the calculation
of offsets in vnc_update_throttle_offset() suffers from integer size
promotion and sign extension, causing coverity warnings
*** CID 1385147: Integer handling issues (SIGN_EXTENSION)
/ui/vnc.c: 979 in vnc_update_throttle_offset()
973 * than that the client would already suffering awful audio
974 * glitches, so dropping samples is no worse really).
975 */
976 static void vnc_update_throttle_offset(VncState *vs)
977 {
978 size_t offset =
>>> CID 1385147: Integer handling issues (SIGN_EXTENSION)
>>> Suspicious implicit sign extension:
"vs->client_pf.bytes_per_pixel" with type "unsigned char" (8 bits,
unsigned) is promoted in "vs->client_width * vs->client_height *
vs->client_pf.bytes_per_pixel" to type "int" (32 bits, signed), then
sign-extended to type "unsigned long" (64 bits, unsigned). If
"vs->client_width * vs->client_height * vs->client_pf.bytes_per_pixel"
is greater than 0x7FFFFFFF, the upper bits of the result will all be 1.
979 vs->client_width * vs->client_height * vs->client_pf.bytes_per_pixel;
Change client_width / client_height to be a size_t to avoid sign
extension and integer promotion. Then validate that dimensions are in
range wrt the RFB protocol u16 limits.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20180118155254.17053-1-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-18 16:52:54 +01:00
|
|
|
assert(pixman_image_get_width(vs->vd->server) < 65536 &&
|
|
|
|
pixman_image_get_width(vs->vd->server) >= 0);
|
|
|
|
assert(pixman_image_get_height(vs->vd->server) < 65536 &&
|
|
|
|
pixman_image_get_height(vs->vd->server) >= 0);
|
2014-06-30 10:57:51 +02:00
|
|
|
vs->client_width = pixman_image_get_width(vs->vd->server);
|
|
|
|
vs->client_height = pixman_image_get_height(vs->vd->server);
|
2010-05-25 18:25:18 +02:00
|
|
|
vnc_write_u16(vs, vs->client_width);
|
|
|
|
vnc_write_u16(vs, vs->client_height);
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2008-09-15 18:05:16 +02:00
|
|
|
pixel_format_message(vs);
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2016-11-21 18:25:15 +01:00
|
|
|
if (qemu_name) {
|
2007-03-19 16:17:08 +01:00
|
|
|
size = snprintf(buf, sizeof(buf), "QEMU (%s)", qemu_name);
|
2016-11-21 18:25:15 +01:00
|
|
|
if (size > sizeof(buf)) {
|
|
|
|
size = sizeof(buf);
|
|
|
|
}
|
|
|
|
} else {
|
2007-03-19 16:17:08 +01:00
|
|
|
size = snprintf(buf, sizeof(buf), "QEMU");
|
2016-11-21 18:25:15 +01:00
|
|
|
}
|
2007-03-19 16:17:08 +01:00
|
|
|
|
|
|
|
vnc_write_u32(vs, size);
|
|
|
|
vnc_write(vs, buf, size);
|
2006-04-30 23:28:36 +02:00
|
|
|
vnc_flush(vs);
|
|
|
|
|
2010-01-14 17:50:56 +01:00
|
|
|
vnc_client_cache_auth(vs);
|
2014-06-18 08:43:49 +02:00
|
|
|
vnc_qmp_event(vs, QAPI_EVENT_VNC_INITIALIZED);
|
2010-01-14 17:50:56 +01:00
|
|
|
|
2006-04-30 23:28:36 +02:00
|
|
|
vnc_read_when(vs, protocol_client_msg, 1);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-03-06 21:27:23 +01:00
|
|
|
void start_client_init(VncState *vs)
|
|
|
|
{
|
|
|
|
vnc_read_when(vs, protocol_client_init, 1);
|
|
|
|
}
|
|
|
|
|
2019-03-14 23:33:08 +01:00
|
|
|
static void authentication_failed(VncState *vs)
|
|
|
|
{
|
|
|
|
vnc_write_u32(vs, 1); /* Reject auth */
|
|
|
|
if (vs->minor >= 8) {
|
|
|
|
static const char err[] = "Authentication failed";
|
|
|
|
vnc_write_u32(vs, sizeof(err));
|
|
|
|
vnc_write(vs, err, sizeof(err));
|
|
|
|
}
|
|
|
|
vnc_flush(vs);
|
|
|
|
vnc_client_error(vs);
|
|
|
|
}
|
|
|
|
|
crypto: replace 'des-rfb' cipher with 'des'
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: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-06-29 15:25:32 +02:00
|
|
|
static void
|
|
|
|
vnc_munge_des_rfb_key(unsigned char *key, size_t nkey)
|
|
|
|
{
|
|
|
|
size_t i;
|
|
|
|
for (i = 0; i < nkey; i++) {
|
|
|
|
uint8_t r = key[i];
|
|
|
|
r = (r & 0xf0) >> 4 | (r & 0x0f) << 4;
|
|
|
|
r = (r & 0xcc) >> 2 | (r & 0x33) << 2;
|
|
|
|
r = (r & 0xaa) >> 1 | (r & 0x55) << 1;
|
|
|
|
key[i] = r;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-12-16 04:02:09 +01:00
|
|
|
static int protocol_client_auth_vnc(VncState *vs, uint8_t *data, size_t len)
|
2007-08-25 03:37:05 +02:00
|
|
|
{
|
2007-12-16 04:02:09 +01:00
|
|
|
unsigned char response[VNC_AUTH_CHALLENGE_SIZE];
|
2015-07-01 19:10:38 +02:00
|
|
|
size_t i, pwlen;
|
2007-12-16 04:02:09 +01:00
|
|
|
unsigned char key[8];
|
2010-10-07 11:50:45 +02:00
|
|
|
time_t now = time(NULL);
|
2015-07-22 11:08:53 +02:00
|
|
|
QCryptoCipher *cipher = NULL;
|
2015-07-01 19:10:38 +02:00
|
|
|
Error *err = NULL;
|
2007-08-25 03:37:05 +02:00
|
|
|
|
2011-01-31 21:27:36 +01:00
|
|
|
if (!vs->vd->password) {
|
2017-09-21 14:15:28 +02:00
|
|
|
trace_vnc_auth_fail(vs, vs->auth, "password is not set", "");
|
2010-10-07 11:50:24 +02:00
|
|
|
goto reject;
|
2007-08-25 03:37:05 +02:00
|
|
|
}
|
2010-10-07 11:50:45 +02:00
|
|
|
if (vs->vd->expires < now) {
|
2017-09-21 14:15:28 +02:00
|
|
|
trace_vnc_auth_fail(vs, vs->auth, "password is expired", "");
|
2010-10-07 11:50:45 +02:00
|
|
|
goto reject;
|
|
|
|
}
|
2007-08-25 03:37:05 +02:00
|
|
|
|
|
|
|
memcpy(response, vs->challenge, VNC_AUTH_CHALLENGE_SIZE);
|
|
|
|
|
|
|
|
/* Calculate the expected challenge response */
|
2009-02-16 15:59:30 +01:00
|
|
|
pwlen = strlen(vs->vd->password);
|
2007-08-25 03:37:05 +02:00
|
|
|
for (i=0; i<sizeof(key); i++)
|
2009-02-16 15:59:30 +01:00
|
|
|
key[i] = i<pwlen ? vs->vd->password[i] : 0;
|
crypto: replace 'des-rfb' cipher with 'des'
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: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-06-29 15:25:32 +02:00
|
|
|
vnc_munge_des_rfb_key(key, sizeof(key));
|
2015-07-01 19:10:38 +02:00
|
|
|
|
|
|
|
cipher = qcrypto_cipher_new(
|
crypto: replace 'des-rfb' cipher with 'des'
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: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-06-29 15:25:32 +02:00
|
|
|
QCRYPTO_CIPHER_ALG_DES,
|
2015-07-01 19:10:38 +02:00
|
|
|
QCRYPTO_CIPHER_MODE_ECB,
|
|
|
|
key, G_N_ELEMENTS(key),
|
|
|
|
&err);
|
|
|
|
if (!cipher) {
|
2017-09-21 14:15:28 +02:00
|
|
|
trace_vnc_auth_fail(vs, vs->auth, "cannot create cipher",
|
|
|
|
error_get_pretty(err));
|
2015-07-01 19:10:38 +02:00
|
|
|
error_free(err);
|
|
|
|
goto reject;
|
|
|
|
}
|
|
|
|
|
2015-07-14 14:51:40 +02:00
|
|
|
if (qcrypto_cipher_encrypt(cipher,
|
2015-07-01 19:10:38 +02:00
|
|
|
vs->challenge,
|
|
|
|
response,
|
|
|
|
VNC_AUTH_CHALLENGE_SIZE,
|
|
|
|
&err) < 0) {
|
2017-09-21 14:15:28 +02:00
|
|
|
trace_vnc_auth_fail(vs, vs->auth, "cannot encrypt challenge response",
|
|
|
|
error_get_pretty(err));
|
2015-07-01 19:10:38 +02:00
|
|
|
error_free(err);
|
|
|
|
goto reject;
|
|
|
|
}
|
2007-08-25 03:37:05 +02:00
|
|
|
|
|
|
|
/* Compare expected vs actual challenge response */
|
|
|
|
if (memcmp(response, data, VNC_AUTH_CHALLENGE_SIZE) != 0) {
|
2017-09-21 14:15:28 +02:00
|
|
|
trace_vnc_auth_fail(vs, vs->auth, "mis-matched challenge response", "");
|
2010-10-07 11:50:24 +02:00
|
|
|
goto reject;
|
2007-08-25 03:37:05 +02:00
|
|
|
} else {
|
2017-09-21 14:15:28 +02:00
|
|
|
trace_vnc_auth_pass(vs, vs->auth);
|
2009-03-06 21:27:40 +01:00
|
|
|
vnc_write_u32(vs, 0); /* Accept auth */
|
|
|
|
vnc_flush(vs);
|
2007-08-25 03:37:05 +02:00
|
|
|
|
2009-03-06 21:27:23 +01:00
|
|
|
start_client_init(vs);
|
2007-08-25 03:37:05 +02:00
|
|
|
}
|
2015-07-22 11:08:53 +02:00
|
|
|
|
|
|
|
qcrypto_cipher_free(cipher);
|
2007-08-25 03:37:05 +02:00
|
|
|
return 0;
|
2010-10-07 11:50:24 +02:00
|
|
|
|
|
|
|
reject:
|
2019-03-14 23:33:08 +01:00
|
|
|
authentication_failed(vs);
|
2015-07-22 11:08:53 +02:00
|
|
|
qcrypto_cipher_free(cipher);
|
2010-10-07 11:50:24 +02:00
|
|
|
return 0;
|
2007-08-25 03:37:05 +02:00
|
|
|
}
|
|
|
|
|
2009-03-06 21:27:23 +01:00
|
|
|
void start_auth_vnc(VncState *vs)
|
2007-08-25 03:37:05 +02:00
|
|
|
{
|
2019-03-14 23:37:43 +01:00
|
|
|
Error *err = NULL;
|
|
|
|
|
|
|
|
if (qcrypto_random_bytes(vs->challenge, sizeof(vs->challenge), &err)) {
|
|
|
|
trace_vnc_auth_fail(vs, vs->auth, "cannot get random bytes",
|
|
|
|
error_get_pretty(err));
|
|
|
|
error_free(err);
|
|
|
|
authentication_failed(vs);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2007-08-25 03:37:05 +02:00
|
|
|
/* Send client a 'random' challenge */
|
|
|
|
vnc_write(vs, vs->challenge, sizeof(vs->challenge));
|
|
|
|
vnc_flush(vs);
|
|
|
|
|
|
|
|
vnc_read_when(vs, protocol_client_auth_vnc, sizeof(vs->challenge));
|
2007-08-25 03:39:10 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2007-12-16 04:02:09 +01:00
|
|
|
static int protocol_client_auth(VncState *vs, uint8_t *data, size_t len)
|
2007-08-25 03:37:05 +02:00
|
|
|
{
|
|
|
|
/* We only advertise 1 auth scheme at a time, so client
|
|
|
|
* must pick the one we sent. Verify this */
|
2011-06-23 14:31:41 +02:00
|
|
|
if (data[0] != vs->auth) { /* Reject auth */
|
2017-09-21 14:15:28 +02:00
|
|
|
trace_vnc_auth_reject(vs, vs->auth, (int)data[0]);
|
2019-03-14 23:33:08 +01:00
|
|
|
authentication_failed(vs);
|
2007-08-25 03:37:05 +02:00
|
|
|
} else { /* Accept requested auth */
|
2017-09-21 14:15:28 +02:00
|
|
|
trace_vnc_auth_start(vs, vs->auth);
|
2011-06-23 14:31:41 +02:00
|
|
|
switch (vs->auth) {
|
2007-08-25 03:37:05 +02:00
|
|
|
case VNC_AUTH_NONE:
|
2007-10-31 02:58:56 +01:00
|
|
|
if (vs->minor >= 8) {
|
|
|
|
vnc_write_u32(vs, 0); /* Accept auth completion */
|
|
|
|
vnc_flush(vs);
|
|
|
|
}
|
2017-09-21 14:15:28 +02:00
|
|
|
trace_vnc_auth_pass(vs, vs->auth);
|
2009-03-06 21:27:23 +01:00
|
|
|
start_client_init(vs);
|
2007-08-25 03:37:05 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case VNC_AUTH_VNC:
|
2009-03-06 21:27:23 +01:00
|
|
|
start_auth_vnc(vs);
|
|
|
|
break;
|
2007-08-25 03:37:05 +02:00
|
|
|
|
2007-08-25 03:37:51 +02:00
|
|
|
case VNC_AUTH_VENCRYPT:
|
2009-03-06 21:27:23 +01:00
|
|
|
start_auth_vencrypt(vs);
|
|
|
|
break;
|
2007-08-25 03:37:51 +02:00
|
|
|
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
#ifdef CONFIG_VNC_SASL
|
|
|
|
case VNC_AUTH_SASL:
|
|
|
|
start_auth_sasl(vs);
|
|
|
|
break;
|
|
|
|
#endif /* CONFIG_VNC_SASL */
|
|
|
|
|
2007-08-25 03:37:05 +02:00
|
|
|
default: /* Should not be possible, but just in case */
|
2017-09-21 14:15:28 +02:00
|
|
|
trace_vnc_auth_fail(vs, vs->auth, "Unhandled auth method", "");
|
2019-03-14 23:33:08 +01:00
|
|
|
authentication_failed(vs);
|
2007-08-25 03:37:05 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-12-16 04:02:09 +01:00
|
|
|
static int protocol_version(VncState *vs, uint8_t *version, size_t len)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
|
|
|
char local[13];
|
|
|
|
|
|
|
|
memcpy(local, version, 12);
|
|
|
|
local[12] = 0;
|
|
|
|
|
2007-08-25 03:37:05 +02:00
|
|
|
if (sscanf(local, "RFB %03d.%03d\n", &vs->major, &vs->minor) != 2) {
|
2009-03-06 21:27:40 +01:00
|
|
|
VNC_DEBUG("Malformed protocol version %s\n", local);
|
|
|
|
vnc_client_error(vs);
|
|
|
|
return 0;
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
2007-08-25 03:37:05 +02:00
|
|
|
VNC_DEBUG("Client request protocol version %d.%d\n", vs->major, vs->minor);
|
|
|
|
if (vs->major != 3 ||
|
2009-03-06 21:27:40 +01:00
|
|
|
(vs->minor != 3 &&
|
|
|
|
vs->minor != 4 &&
|
|
|
|
vs->minor != 5 &&
|
|
|
|
vs->minor != 7 &&
|
|
|
|
vs->minor != 8)) {
|
|
|
|
VNC_DEBUG("Unsupported client version\n");
|
|
|
|
vnc_write_u32(vs, VNC_AUTH_INVALID);
|
|
|
|
vnc_flush(vs);
|
|
|
|
vnc_client_error(vs);
|
|
|
|
return 0;
|
2007-08-25 03:37:05 +02:00
|
|
|
}
|
2007-09-30 15:01:15 +02:00
|
|
|
/* Some broken clients report v3.4 or v3.5, which spec requires to be treated
|
2007-08-25 03:37:05 +02:00
|
|
|
* as equivalent to v3.3 by servers
|
|
|
|
*/
|
2007-09-30 15:01:15 +02:00
|
|
|
if (vs->minor == 4 || vs->minor == 5)
|
2009-03-06 21:27:40 +01:00
|
|
|
vs->minor = 3;
|
2007-08-25 03:37:05 +02:00
|
|
|
|
|
|
|
if (vs->minor == 3) {
|
2017-09-21 14:15:28 +02:00
|
|
|
trace_vnc_auth_start(vs, vs->auth);
|
2011-06-23 14:31:41 +02:00
|
|
|
if (vs->auth == VNC_AUTH_NONE) {
|
|
|
|
vnc_write_u32(vs, vs->auth);
|
2007-08-25 03:37:05 +02:00
|
|
|
vnc_flush(vs);
|
2017-09-21 14:15:28 +02:00
|
|
|
trace_vnc_auth_pass(vs, vs->auth);
|
2009-03-06 21:27:40 +01:00
|
|
|
start_client_init(vs);
|
2011-06-23 14:31:41 +02:00
|
|
|
} else if (vs->auth == VNC_AUTH_VNC) {
|
2007-08-25 03:37:05 +02:00
|
|
|
VNC_DEBUG("Tell client VNC auth\n");
|
2011-06-23 14:31:41 +02:00
|
|
|
vnc_write_u32(vs, vs->auth);
|
2007-08-25 03:37:05 +02:00
|
|
|
vnc_flush(vs);
|
|
|
|
start_auth_vnc(vs);
|
|
|
|
} else {
|
2017-09-21 14:15:28 +02:00
|
|
|
trace_vnc_auth_fail(vs, vs->auth,
|
|
|
|
"Unsupported auth method for v3.3", "");
|
2007-08-25 03:37:05 +02:00
|
|
|
vnc_write_u32(vs, VNC_AUTH_INVALID);
|
|
|
|
vnc_flush(vs);
|
|
|
|
vnc_client_error(vs);
|
|
|
|
}
|
|
|
|
} else {
|
2009-03-06 21:27:40 +01:00
|
|
|
vnc_write_u8(vs, 1); /* num auth */
|
2011-06-23 14:31:41 +02:00
|
|
|
vnc_write_u8(vs, vs->auth);
|
2009-03-06 21:27:40 +01:00
|
|
|
vnc_read_when(vs, protocol_client_auth, 1);
|
|
|
|
vnc_flush(vs);
|
2007-08-25 03:37:05 +02:00
|
|
|
}
|
2006-04-30 23:28:36 +02:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-02-04 09:05:55 +01:00
|
|
|
static VncRectStat *vnc_stat_rect(VncDisplay *vd, int x, int y)
|
|
|
|
{
|
|
|
|
struct VncSurface *vs = &vd->guest;
|
|
|
|
|
|
|
|
return &vs->stats[y / VNC_STAT_RECT][x / VNC_STAT_RECT];
|
|
|
|
}
|
|
|
|
|
2011-02-04 09:05:56 +01:00
|
|
|
void vnc_sent_lossy_rect(VncState *vs, int x, int y, int w, int h)
|
|
|
|
{
|
|
|
|
int i, j;
|
|
|
|
|
|
|
|
w = (x + w) / VNC_STAT_RECT;
|
|
|
|
h = (y + h) / VNC_STAT_RECT;
|
|
|
|
x /= VNC_STAT_RECT;
|
|
|
|
y /= VNC_STAT_RECT;
|
|
|
|
|
2011-02-04 09:06:03 +01:00
|
|
|
for (j = y; j <= h; j++) {
|
|
|
|
for (i = x; i <= w; i++) {
|
2011-02-04 09:05:56 +01:00
|
|
|
vs->lossy_rect[j][i] = 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int vnc_refresh_lossy_rect(VncDisplay *vd, int x, int y)
|
|
|
|
{
|
|
|
|
VncState *vs;
|
|
|
|
int sty = y / VNC_STAT_RECT;
|
|
|
|
int stx = x / VNC_STAT_RECT;
|
|
|
|
int has_dirty = 0;
|
|
|
|
|
2017-06-22 13:04:16 +02:00
|
|
|
y = QEMU_ALIGN_DOWN(y, VNC_STAT_RECT);
|
|
|
|
x = QEMU_ALIGN_DOWN(x, VNC_STAT_RECT);
|
2011-02-04 09:05:56 +01:00
|
|
|
|
|
|
|
QTAILQ_FOREACH(vs, &vd->clients, next) {
|
2011-02-04 09:06:05 +01:00
|
|
|
int j;
|
2011-02-04 09:05:56 +01:00
|
|
|
|
|
|
|
/* kernel send buffers are full -> refresh later */
|
|
|
|
if (vs->output.offset) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!vs->lossy_rect[sty][stx]) {
|
|
|
|
continue;
|
|
|
|
}
|
2011-02-04 09:06:03 +01:00
|
|
|
|
2011-02-04 09:05:56 +01:00
|
|
|
vs->lossy_rect[sty][stx] = 0;
|
|
|
|
for (j = 0; j < VNC_STAT_RECT; ++j) {
|
2014-01-08 10:08:33 +01:00
|
|
|
bitmap_set(vs->dirty[y + j],
|
|
|
|
x / VNC_DIRTY_PIXELS_PER_BIT,
|
|
|
|
VNC_STAT_RECT / VNC_DIRTY_PIXELS_PER_BIT);
|
2011-02-04 09:05:56 +01:00
|
|
|
}
|
|
|
|
has_dirty++;
|
|
|
|
}
|
2011-02-04 09:06:03 +01:00
|
|
|
|
2011-02-04 09:05:56 +01:00
|
|
|
return has_dirty;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int vnc_update_stats(VncDisplay *vd, struct timeval * tv)
|
2011-02-04 09:05:55 +01:00
|
|
|
{
|
2017-01-24 10:00:28 +01:00
|
|
|
int width = MIN(pixman_image_get_width(vd->guest.fb),
|
|
|
|
pixman_image_get_width(vd->server));
|
|
|
|
int height = MIN(pixman_image_get_height(vd->guest.fb),
|
|
|
|
pixman_image_get_height(vd->server));
|
2011-02-04 09:05:55 +01:00
|
|
|
int x, y;
|
|
|
|
struct timeval res;
|
2011-02-04 09:05:56 +01:00
|
|
|
int has_dirty = 0;
|
2011-02-04 09:05:55 +01:00
|
|
|
|
2012-10-10 13:29:43 +02:00
|
|
|
for (y = 0; y < height; y += VNC_STAT_RECT) {
|
|
|
|
for (x = 0; x < width; x += VNC_STAT_RECT) {
|
2011-02-04 09:05:55 +01:00
|
|
|
VncRectStat *rect = vnc_stat_rect(vd, x, y);
|
|
|
|
|
|
|
|
rect->updated = false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-03-13 11:30:52 +01:00
|
|
|
qemu_timersub(tv, &VNC_REFRESH_STATS, &res);
|
2011-02-04 09:05:55 +01:00
|
|
|
|
|
|
|
if (timercmp(&vd->guest.last_freq_check, &res, >)) {
|
2011-02-04 09:05:56 +01:00
|
|
|
return has_dirty;
|
2011-02-04 09:05:55 +01:00
|
|
|
}
|
|
|
|
vd->guest.last_freq_check = *tv;
|
|
|
|
|
2012-10-10 13:29:43 +02:00
|
|
|
for (y = 0; y < height; y += VNC_STAT_RECT) {
|
|
|
|
for (x = 0; x < width; x += VNC_STAT_RECT) {
|
2011-02-04 09:05:55 +01:00
|
|
|
VncRectStat *rect= vnc_stat_rect(vd, x, y);
|
|
|
|
int count = ARRAY_SIZE(rect->times);
|
|
|
|
struct timeval min, max;
|
|
|
|
|
|
|
|
if (!timerisset(&rect->times[count - 1])) {
|
|
|
|
continue ;
|
|
|
|
}
|
|
|
|
|
|
|
|
max = rect->times[(rect->idx + count - 1) % count];
|
2011-03-13 11:30:52 +01:00
|
|
|
qemu_timersub(tv, &max, &res);
|
2011-02-04 09:05:55 +01:00
|
|
|
|
|
|
|
if (timercmp(&res, &VNC_REFRESH_LOSSY, >)) {
|
|
|
|
rect->freq = 0;
|
2011-02-04 09:05:56 +01:00
|
|
|
has_dirty += vnc_refresh_lossy_rect(vd, x, y);
|
2011-02-04 09:05:55 +01:00
|
|
|
memset(rect->times, 0, sizeof (rect->times));
|
|
|
|
continue ;
|
|
|
|
}
|
|
|
|
|
|
|
|
min = rect->times[rect->idx];
|
|
|
|
max = rect->times[(rect->idx + count - 1) % count];
|
2011-03-13 11:30:52 +01:00
|
|
|
qemu_timersub(&max, &min, &res);
|
2011-02-04 09:05:55 +01:00
|
|
|
|
|
|
|
rect->freq = res.tv_sec + res.tv_usec / 1000000.;
|
|
|
|
rect->freq /= count;
|
|
|
|
rect->freq = 1. / rect->freq;
|
|
|
|
}
|
|
|
|
}
|
2011-02-04 09:05:56 +01:00
|
|
|
return has_dirty;
|
2011-02-04 09:05:55 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
double vnc_update_freq(VncState *vs, int x, int y, int w, int h)
|
|
|
|
{
|
|
|
|
int i, j;
|
|
|
|
double total = 0;
|
|
|
|
int num = 0;
|
|
|
|
|
2017-06-22 13:04:16 +02:00
|
|
|
x = QEMU_ALIGN_DOWN(x, VNC_STAT_RECT);
|
|
|
|
y = QEMU_ALIGN_DOWN(y, VNC_STAT_RECT);
|
2011-02-04 09:05:55 +01:00
|
|
|
|
|
|
|
for (j = y; j <= y + h; j += VNC_STAT_RECT) {
|
|
|
|
for (i = x; i <= x + w; i += VNC_STAT_RECT) {
|
|
|
|
total += vnc_stat_rect(vs->vd, i, j)->freq;
|
|
|
|
num++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (num) {
|
|
|
|
return total / num;
|
|
|
|
} else {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void vnc_rect_updated(VncDisplay *vd, int x, int y, struct timeval * tv)
|
|
|
|
{
|
|
|
|
VncRectStat *rect;
|
|
|
|
|
|
|
|
rect = vnc_stat_rect(vd, x, y);
|
|
|
|
if (rect->updated) {
|
2022-10-24 09:28:02 +02:00
|
|
|
return;
|
2011-02-04 09:05:55 +01:00
|
|
|
}
|
|
|
|
rect->times[rect->idx] = *tv;
|
|
|
|
rect->idx = (rect->idx + 1) % ARRAY_SIZE(rect->times);
|
|
|
|
rect->updated = true;
|
|
|
|
}
|
|
|
|
|
2009-08-03 11:54:32 +02:00
|
|
|
static int vnc_refresh_server_surface(VncDisplay *vd)
|
|
|
|
{
|
2014-06-30 10:57:51 +02:00
|
|
|
int width = MIN(pixman_image_get_width(vd->guest.fb),
|
|
|
|
pixman_image_get_width(vd->server));
|
|
|
|
int height = MIN(pixman_image_get_height(vd->guest.fb),
|
|
|
|
pixman_image_get_height(vd->server));
|
2015-08-17 19:56:53 +02:00
|
|
|
int cmp_bytes, server_stride, line_bytes, guest_ll, guest_stride, y = 0;
|
2014-01-08 10:08:35 +01:00
|
|
|
uint8_t *guest_row0 = NULL, *server_row0;
|
2010-02-05 12:04:05 +01:00
|
|
|
VncState *vs;
|
2009-08-03 11:54:32 +02:00
|
|
|
int has_dirty = 0;
|
2012-10-10 13:29:43 +02:00
|
|
|
pixman_image_t *tmpbuf = NULL;
|
2022-03-15 07:50:37 +01:00
|
|
|
unsigned long offset;
|
|
|
|
int x;
|
|
|
|
uint8_t *guest_ptr, *server_ptr;
|
2009-08-03 11:54:32 +02:00
|
|
|
|
2011-02-04 09:06:08 +01:00
|
|
|
struct timeval tv = { 0, 0 };
|
2011-02-04 09:05:55 +01:00
|
|
|
|
2011-02-04 09:06:08 +01:00
|
|
|
if (!vd->non_adaptive) {
|
|
|
|
gettimeofday(&tv, NULL);
|
|
|
|
has_dirty = vnc_update_stats(vd, &tv);
|
|
|
|
}
|
2011-02-04 09:05:55 +01:00
|
|
|
|
2022-03-15 07:50:37 +01:00
|
|
|
offset = find_next_bit((unsigned long *) &vd->guest.dirty,
|
|
|
|
height * VNC_DIRTY_BPL(&vd->guest), 0);
|
|
|
|
if (offset == height * VNC_DIRTY_BPL(&vd->guest)) {
|
|
|
|
/* no dirty bits in guest surface */
|
|
|
|
return has_dirty;
|
|
|
|
}
|
|
|
|
|
2009-08-03 11:54:32 +02:00
|
|
|
/*
|
|
|
|
* Walk through the guest dirty map.
|
|
|
|
* Check and copy modified bits from guest to server surface.
|
|
|
|
* Update server dirty map.
|
|
|
|
*/
|
2014-06-30 10:57:51 +02:00
|
|
|
server_row0 = (uint8_t *)pixman_image_get_data(vd->server);
|
2015-08-17 19:56:53 +02:00
|
|
|
server_stride = guest_stride = guest_ll =
|
|
|
|
pixman_image_get_stride(vd->server);
|
2014-06-30 10:57:51 +02:00
|
|
|
cmp_bytes = MIN(VNC_DIRTY_PIXELS_PER_BIT * VNC_SERVER_FB_BYTES,
|
|
|
|
server_stride);
|
2012-10-10 13:29:43 +02:00
|
|
|
if (vd->guest.format != VNC_SERVER_FB_FORMAT) {
|
2023-09-21 14:13:08 +02:00
|
|
|
int w = pixman_image_get_width(vd->server);
|
|
|
|
tmpbuf = qemu_pixman_linebuf_create(VNC_SERVER_FB_FORMAT, w);
|
2014-01-08 10:08:35 +01:00
|
|
|
} else {
|
2015-08-17 19:56:53 +02:00
|
|
|
int guest_bpp =
|
|
|
|
PIXMAN_FORMAT_BPP(pixman_image_get_format(vd->guest.fb));
|
2014-01-08 10:08:35 +01:00
|
|
|
guest_row0 = (uint8_t *)pixman_image_get_data(vd->guest.fb);
|
|
|
|
guest_stride = pixman_image_get_stride(vd->guest.fb);
|
2018-07-04 17:39:17 +02:00
|
|
|
guest_ll = pixman_image_get_width(vd->guest.fb)
|
|
|
|
* DIV_ROUND_UP(guest_bpp, 8);
|
2014-01-08 10:08:35 +01:00
|
|
|
}
|
2015-08-17 19:56:53 +02:00
|
|
|
line_bytes = MIN(server_stride, guest_ll);
|
2014-01-08 10:08:35 +01:00
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
y = offset / VNC_DIRTY_BPL(&vd->guest);
|
|
|
|
x = offset % VNC_DIRTY_BPL(&vd->guest);
|
2009-08-03 11:54:32 +02:00
|
|
|
|
2014-01-08 10:08:35 +01:00
|
|
|
server_ptr = server_row0 + y * server_stride + x * cmp_bytes;
|
|
|
|
|
|
|
|
if (vd->guest.format != VNC_SERVER_FB_FORMAT) {
|
|
|
|
qemu_pixman_linebuf_fill(tmpbuf, vd->guest.fb, width, 0, y);
|
|
|
|
guest_ptr = (uint8_t *)pixman_image_get_data(tmpbuf);
|
|
|
|
} else {
|
|
|
|
guest_ptr = guest_row0 + y * guest_stride;
|
|
|
|
}
|
|
|
|
guest_ptr += x * cmp_bytes;
|
|
|
|
|
|
|
|
for (; x < DIV_ROUND_UP(width, VNC_DIRTY_PIXELS_PER_BIT);
|
|
|
|
x++, guest_ptr += cmp_bytes, server_ptr += cmp_bytes) {
|
2014-06-30 10:57:51 +02:00
|
|
|
int _cmp_bytes = cmp_bytes;
|
2014-01-08 10:08:35 +01:00
|
|
|
if (!test_and_clear_bit(x, vd->guest.dirty[y])) {
|
|
|
|
continue;
|
|
|
|
}
|
2015-08-17 19:56:53 +02:00
|
|
|
if ((x + 1) * cmp_bytes > line_bytes) {
|
|
|
|
_cmp_bytes = line_bytes - x * cmp_bytes;
|
2014-06-30 10:57:51 +02:00
|
|
|
}
|
2015-08-17 19:56:53 +02:00
|
|
|
assert(_cmp_bytes >= 0);
|
2014-06-30 10:57:51 +02:00
|
|
|
if (memcmp(server_ptr, guest_ptr, _cmp_bytes) == 0) {
|
2014-01-08 10:08:35 +01:00
|
|
|
continue;
|
|
|
|
}
|
2014-06-30 10:57:51 +02:00
|
|
|
memcpy(server_ptr, guest_ptr, _cmp_bytes);
|
2014-01-08 10:08:35 +01:00
|
|
|
if (!vd->non_adaptive) {
|
|
|
|
vnc_rect_updated(vd, x * VNC_DIRTY_PIXELS_PER_BIT,
|
|
|
|
y, &tv);
|
2009-08-03 11:54:32 +02:00
|
|
|
}
|
2014-01-08 10:08:35 +01:00
|
|
|
QTAILQ_FOREACH(vs, &vd->clients, next) {
|
|
|
|
set_bit(x, vs->dirty[y]);
|
|
|
|
}
|
|
|
|
has_dirty++;
|
2009-08-03 11:54:32 +02:00
|
|
|
}
|
2014-01-08 10:08:35 +01:00
|
|
|
|
|
|
|
y++;
|
2022-03-15 07:50:37 +01:00
|
|
|
offset = find_next_bit((unsigned long *) &vd->guest.dirty,
|
|
|
|
height * VNC_DIRTY_BPL(&vd->guest),
|
|
|
|
y * VNC_DIRTY_BPL(&vd->guest));
|
|
|
|
if (offset == height * VNC_DIRTY_BPL(&vd->guest)) {
|
|
|
|
/* no more dirty bits */
|
|
|
|
break;
|
|
|
|
}
|
2009-08-03 11:54:32 +02:00
|
|
|
}
|
2012-10-10 13:29:43 +02:00
|
|
|
qemu_pixman_image_unref(tmpbuf);
|
2009-08-03 11:54:32 +02:00
|
|
|
return has_dirty;
|
|
|
|
}
|
|
|
|
|
2013-03-14 11:56:16 +01:00
|
|
|
static void vnc_refresh(DisplayChangeListener *dcl)
|
2009-08-03 11:54:05 +02:00
|
|
|
{
|
2013-03-14 11:56:16 +01:00
|
|
|
VncDisplay *vd = container_of(dcl, VncDisplay, dcl);
|
2010-02-05 12:04:05 +01:00
|
|
|
VncState *vs, *vn;
|
|
|
|
int has_dirty, rects = 0;
|
2009-08-03 11:54:05 +02:00
|
|
|
|
2014-09-29 09:00:40 +02:00
|
|
|
if (QTAILQ_EMPTY(&vd->clients)) {
|
|
|
|
update_displaychangelistener(&vd->dcl, VNC_REFRESH_INTERVAL_MAX);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-09-18 12:54:49 +02:00
|
|
|
graphic_hw_update(vd->dcl.con);
|
2009-08-03 11:54:05 +02:00
|
|
|
|
2010-07-07 20:58:02 +02:00
|
|
|
if (vnc_trylock_display(vd)) {
|
2013-03-14 11:56:16 +01:00
|
|
|
update_displaychangelistener(&vd->dcl, VNC_REFRESH_INTERVAL_BASE);
|
2010-07-07 20:58:02 +02:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2009-08-03 11:54:32 +02:00
|
|
|
has_dirty = vnc_refresh_server_surface(vd);
|
2010-07-07 20:58:02 +02:00
|
|
|
vnc_unlock_display(vd);
|
2009-08-03 11:54:32 +02:00
|
|
|
|
2010-02-05 12:04:05 +01:00
|
|
|
QTAILQ_FOREACH_SAFE(vs, &vd->clients, next, vn) {
|
2017-12-18 20:12:16 +01:00
|
|
|
rects += vnc_update_client(vs, has_dirty);
|
2010-01-25 13:54:57 +01:00
|
|
|
/* vs might be free()ed here */
|
2009-08-03 11:54:05 +02:00
|
|
|
}
|
2010-07-07 20:58:02 +02:00
|
|
|
|
2009-08-03 11:56:01 +02:00
|
|
|
if (has_dirty && rects) {
|
2013-03-14 11:56:16 +01:00
|
|
|
vd->dcl.update_interval /= 2;
|
|
|
|
if (vd->dcl.update_interval < VNC_REFRESH_INTERVAL_BASE) {
|
|
|
|
vd->dcl.update_interval = VNC_REFRESH_INTERVAL_BASE;
|
|
|
|
}
|
2009-08-03 11:56:01 +02:00
|
|
|
} else {
|
2013-03-14 11:56:16 +01:00
|
|
|
vd->dcl.update_interval += VNC_REFRESH_INTERVAL_INC;
|
|
|
|
if (vd->dcl.update_interval > VNC_REFRESH_INTERVAL_MAX) {
|
|
|
|
vd->dcl.update_interval = VNC_REFRESH_INTERVAL_MAX;
|
|
|
|
}
|
2009-08-03 11:54:05 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-02-27 17:20:57 +01:00
|
|
|
static void vnc_connect(VncDisplay *vd, QIOChannelSocket *sioc,
|
2013-06-11 13:42:44 +02:00
|
|
|
bool skipauth, bool websocket)
|
2008-02-03 03:54:04 +01:00
|
|
|
{
|
2015-11-03 17:12:03 +01:00
|
|
|
VncState *vs = g_new0(VncState, 1);
|
2016-09-29 17:45:39 +02:00
|
|
|
bool first_client = QTAILQ_EMPTY(&vd->clients);
|
2011-02-04 09:05:56 +01:00
|
|
|
int i;
|
|
|
|
|
2017-09-21 14:15:27 +02:00
|
|
|
trace_vnc_client_connect(vs, sioc);
|
2019-08-31 17:39:22 +02:00
|
|
|
vs->zrle = g_new0(VncZrle, 1);
|
|
|
|
vs->tight = g_new0(VncTight, 1);
|
2018-05-07 12:22:54 +02:00
|
|
|
vs->magic = VNC_MAGIC;
|
2015-02-27 17:20:57 +01:00
|
|
|
vs->sioc = sioc;
|
|
|
|
object_ref(OBJECT(vs->sioc));
|
|
|
|
vs->ioc = QIO_CHANNEL(sioc);
|
|
|
|
object_ref(OBJECT(vs->ioc));
|
2014-07-29 12:14:08 +02:00
|
|
|
vs->vd = vd;
|
2011-06-23 14:31:41 +02:00
|
|
|
|
2015-02-27 17:20:57 +01:00
|
|
|
buffer_init(&vs->input, "vnc-input/%p", sioc);
|
|
|
|
buffer_init(&vs->output, "vnc-output/%p", sioc);
|
|
|
|
buffer_init(&vs->jobs_buffer, "vnc-jobs_buffer/%p", sioc);
|
2015-10-30 12:10:02 +01:00
|
|
|
|
2019-08-31 17:39:22 +02:00
|
|
|
buffer_init(&vs->tight->tight, "vnc-tight/%p", sioc);
|
|
|
|
buffer_init(&vs->tight->zlib, "vnc-tight-zlib/%p", sioc);
|
|
|
|
buffer_init(&vs->tight->gradient, "vnc-tight-gradient/%p", sioc);
|
2015-10-30 12:10:02 +01:00
|
|
|
#ifdef CONFIG_VNC_JPEG
|
2019-08-31 17:39:22 +02:00
|
|
|
buffer_init(&vs->tight->jpeg, "vnc-tight-jpeg/%p", sioc);
|
2015-10-30 12:10:02 +01:00
|
|
|
#endif
|
2022-04-08 09:13:34 +02:00
|
|
|
#ifdef CONFIG_PNG
|
2019-08-31 17:39:22 +02:00
|
|
|
buffer_init(&vs->tight->png, "vnc-tight-png/%p", sioc);
|
2015-10-30 12:10:02 +01:00
|
|
|
#endif
|
2015-02-27 17:20:57 +01:00
|
|
|
buffer_init(&vs->zlib.zlib, "vnc-zlib/%p", sioc);
|
2019-08-31 17:39:22 +02:00
|
|
|
buffer_init(&vs->zrle->zrle, "vnc-zrle/%p", sioc);
|
|
|
|
buffer_init(&vs->zrle->fb, "vnc-zrle-fb/%p", sioc);
|
|
|
|
buffer_init(&vs->zrle->zlib, "vnc-zrle-zlib/%p", sioc);
|
2015-10-30 12:10:02 +01:00
|
|
|
|
2011-06-23 14:31:41 +02:00
|
|
|
if (skipauth) {
|
2018-12-13 23:37:37 +01:00
|
|
|
vs->auth = VNC_AUTH_NONE;
|
|
|
|
vs->subauth = VNC_AUTH_INVALID;
|
2011-06-23 14:31:41 +02:00
|
|
|
} else {
|
2015-03-17 14:42:57 +01:00
|
|
|
if (websocket) {
|
|
|
|
vs->auth = vd->ws_auth;
|
|
|
|
vs->subauth = VNC_AUTH_INVALID;
|
|
|
|
} else {
|
|
|
|
vs->auth = vd->auth;
|
|
|
|
vs->subauth = vd->subauth;
|
|
|
|
}
|
2011-06-23 14:31:41 +02:00
|
|
|
}
|
2015-02-27 17:20:57 +01:00
|
|
|
VNC_DEBUG("Client sioc=%p ws=%d auth=%d subauth=%d\n",
|
|
|
|
sioc, websocket, vs->auth, vs->subauth);
|
2011-06-23 14:31:41 +02:00
|
|
|
|
2011-08-21 05:09:37 +02:00
|
|
|
vs->lossy_rect = g_malloc0(VNC_STAT_ROWS * sizeof (*vs->lossy_rect));
|
2011-02-04 09:05:56 +01:00
|
|
|
for (i = 0; i < VNC_STAT_ROWS; ++i) {
|
2015-11-03 17:12:03 +01:00
|
|
|
vs->lossy_rect[i] = g_new0(uint8_t, VNC_STAT_COLS);
|
2011-02-04 09:05:56 +01:00
|
|
|
}
|
2009-02-16 15:59:30 +01:00
|
|
|
|
2015-02-27 17:20:57 +01:00
|
|
|
VNC_DEBUG("New client on socket %p\n", vs->sioc);
|
2013-03-14 11:56:16 +01:00
|
|
|
update_displaychangelistener(&vd->dcl, VNC_REFRESH_INTERVAL_BASE);
|
2015-02-27 17:20:57 +01:00
|
|
|
qio_channel_set_blocking(vs->ioc, false, NULL);
|
2017-09-12 17:21:47 +02:00
|
|
|
if (vs->ioc_tag) {
|
|
|
|
g_source_remove(vs->ioc_tag);
|
|
|
|
}
|
2013-01-21 11:04:44 +01:00
|
|
|
if (websocket) {
|
|
|
|
vs->websocket = 1;
|
2016-09-29 17:45:34 +02:00
|
|
|
if (vd->tlscreds) {
|
2015-02-27 17:20:57 +01:00
|
|
|
vs->ioc_tag = qio_channel_add_watch(
|
2020-10-29 04:22:41 +01:00
|
|
|
vs->ioc, G_IO_IN | G_IO_HUP | G_IO_ERR,
|
|
|
|
vncws_tls_handshake_io, vs, NULL);
|
ui: convert VNC server to use QCryptoTLSSession
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-08-06 15:39:32 +02:00
|
|
|
} else {
|
2015-02-27 17:20:57 +01:00
|
|
|
vs->ioc_tag = qio_channel_add_watch(
|
2020-10-29 04:22:41 +01:00
|
|
|
vs->ioc, G_IO_IN | G_IO_HUP | G_IO_ERR,
|
|
|
|
vncws_handshake_io, vs, NULL);
|
2013-04-23 16:33:01 +02:00
|
|
|
}
|
2015-02-27 17:20:57 +01:00
|
|
|
} else {
|
|
|
|
vs->ioc_tag = qio_channel_add_watch(
|
2020-10-29 04:22:41 +01:00
|
|
|
vs->ioc, G_IO_IN | G_IO_HUP | G_IO_ERR,
|
|
|
|
vnc_client_io, vs, NULL);
|
2013-01-21 11:04:44 +01:00
|
|
|
}
|
2009-02-16 15:59:30 +01:00
|
|
|
|
2010-01-14 17:50:56 +01:00
|
|
|
vnc_client_cache_addr(vs);
|
2014-06-18 08:43:49 +02:00
|
|
|
vnc_qmp_event(vs, QAPI_EVENT_VNC_CONNECTED);
|
2011-11-24 18:10:49 +01:00
|
|
|
vnc_set_share_mode(vs, VNC_SHARE_MODE_CONNECTING);
|
2010-01-14 17:50:56 +01:00
|
|
|
|
2009-02-16 15:59:30 +01:00
|
|
|
vs->last_x = -1;
|
|
|
|
vs->last_y = -1;
|
|
|
|
|
|
|
|
vs->as.freq = 44100;
|
|
|
|
vs->as.nchannels = 2;
|
2019-03-08 23:34:13 +01:00
|
|
|
vs->as.fmt = AUDIO_FORMAT_S16;
|
2009-02-16 15:59:30 +01:00
|
|
|
vs->as.endianness = 0;
|
|
|
|
|
2010-07-07 20:58:02 +02:00
|
|
|
qemu_mutex_init(&vs->output_mutex);
|
2012-03-14 07:58:47 +01:00
|
|
|
vs->bh = qemu_bh_new(vnc_jobs_bh, vs);
|
2010-07-07 20:58:02 +02:00
|
|
|
|
2014-10-02 12:09:34 +02:00
|
|
|
QTAILQ_INSERT_TAIL(&vd->clients, vs, next);
|
2015-10-30 12:10:09 +01:00
|
|
|
if (first_client) {
|
|
|
|
vnc_update_server_surface(vd);
|
|
|
|
}
|
2009-08-03 11:54:32 +02:00
|
|
|
|
2014-09-18 12:54:49 +02:00
|
|
|
graphic_hw_update(vd->dcl.con);
|
2009-08-03 11:54:32 +02:00
|
|
|
|
2016-09-29 17:45:39 +02:00
|
|
|
if (!vs->websocket) {
|
2016-09-29 17:45:40 +02:00
|
|
|
vnc_start_protocol(vs);
|
2016-09-29 17:45:39 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (vd->num_connecting > vd->connections_limit) {
|
|
|
|
QTAILQ_FOREACH(vs, &vd->clients, next) {
|
|
|
|
if (vs->share_mode == VNC_SHARE_MODE_CONNECTING) {
|
|
|
|
vnc_disconnect_start(vs);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-09-29 17:45:40 +02:00
|
|
|
void vnc_start_protocol(VncState *vs)
|
2016-09-29 17:45:39 +02:00
|
|
|
{
|
2008-02-03 03:54:04 +01:00
|
|
|
vnc_write(vs, "RFB 003.008\n", 12);
|
|
|
|
vnc_flush(vs);
|
|
|
|
vnc_read_when(vs, protocol_version, 12);
|
2009-02-16 15:59:30 +01:00
|
|
|
|
2010-03-10 16:38:29 +01:00
|
|
|
vs->mouse_mode_notifier.notify = check_pointer_type_change;
|
|
|
|
qemu_add_mouse_mode_change_notifier(&vs->mouse_mode_notifier);
|
2008-02-03 03:54:04 +01:00
|
|
|
}
|
|
|
|
|
2018-02-01 17:45:14 +01:00
|
|
|
static void vnc_listen_io(QIONetListener *listener,
|
|
|
|
QIOChannelSocket *cioc,
|
|
|
|
void *opaque)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
2016-09-29 17:45:35 +02:00
|
|
|
VncDisplay *vd = opaque;
|
2018-02-01 17:45:14 +01:00
|
|
|
bool isWebsock = listener == vd->wslistener;
|
2013-01-21 11:04:44 +01:00
|
|
|
|
2018-02-01 17:45:14 +01:00
|
|
|
qio_channel_set_name(QIO_CHANNEL(cioc),
|
|
|
|
isWebsock ? "vnc-ws-server" : "vnc-server");
|
|
|
|
qio_channel_set_delay(QIO_CHANNEL(cioc), false);
|
|
|
|
vnc_connect(vd, cioc, false, isWebsock);
|
2013-01-21 11:04:44 +01:00
|
|
|
}
|
|
|
|
|
2012-11-13 14:51:41 +01:00
|
|
|
static const DisplayChangeListenerOps dcl_ops = {
|
2014-07-07 09:18:19 +02:00
|
|
|
.dpy_name = "vnc",
|
|
|
|
.dpy_refresh = vnc_refresh,
|
|
|
|
.dpy_gfx_update = vnc_dpy_update,
|
|
|
|
.dpy_gfx_switch = vnc_dpy_switch,
|
|
|
|
.dpy_gfx_check_format = qemu_pixman_check_format,
|
|
|
|
.dpy_mouse_set = vnc_mouse_set,
|
|
|
|
.dpy_cursor_define = vnc_dpy_cursor_define,
|
2012-11-13 14:51:41 +01:00
|
|
|
};
|
|
|
|
|
2018-10-17 10:26:50 +02:00
|
|
|
void vnc_display_init(const char *id, Error **errp)
|
2006-04-30 23:28:36 +02:00
|
|
|
{
|
2016-09-29 17:45:35 +02:00
|
|
|
VncDisplay *vd;
|
2014-09-16 12:33:03 +02:00
|
|
|
|
|
|
|
if (vnc_display_find(id) != NULL) {
|
|
|
|
return;
|
|
|
|
}
|
2016-09-29 17:45:35 +02:00
|
|
|
vd = g_malloc0(sizeof(*vd));
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2016-09-29 17:45:35 +02:00
|
|
|
vd->id = strdup(id);
|
|
|
|
QTAILQ_INSERT_TAIL(&vnc_displays, vd, next);
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2016-09-29 17:45:35 +02:00
|
|
|
QTAILQ_INIT(&vd->clients);
|
|
|
|
vd->expires = TIME_MAX;
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2014-05-21 13:18:20 +02:00
|
|
|
if (keyboard_layout) {
|
|
|
|
trace_vnc_key_map_init(keyboard_layout);
|
2018-10-17 10:26:50 +02:00
|
|
|
vd->kbd_layout = init_keyboard_layout(name2keysym,
|
|
|
|
keyboard_layout, errp);
|
2014-05-21 13:18:20 +02:00
|
|
|
} else {
|
2018-10-17 10:26:50 +02:00
|
|
|
vd->kbd_layout = init_keyboard_layout(name2keysym, "en-us", errp);
|
2014-05-21 13:18:20 +02:00
|
|
|
}
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2016-09-29 17:45:35 +02:00
|
|
|
if (!vd->kbd_layout) {
|
2018-10-17 10:26:50 +02:00
|
|
|
return;
|
2016-09-29 17:45:35 +02:00
|
|
|
}
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2016-09-29 17:45:35 +02:00
|
|
|
vd->share_policy = VNC_SHARE_POLICY_ALLOW_EXCLUSIVE;
|
|
|
|
vd->connections_limit = 32;
|
2016-08-02 12:45:26 +02:00
|
|
|
|
2016-09-29 17:45:35 +02:00
|
|
|
qemu_mutex_init(&vd->mutex);
|
2010-07-07 20:58:02 +02:00
|
|
|
vnc_start_worker_thread();
|
|
|
|
|
2016-09-29 17:45:35 +02:00
|
|
|
vd->dcl.ops = &dcl_ops;
|
|
|
|
register_displaychangelistener(&vd->dcl);
|
2019-01-22 10:28:12 +01:00
|
|
|
vd->kbd = qkbd_state_init(vd->dcl.con);
|
2007-08-25 03:35:38 +02:00
|
|
|
}
|
|
|
|
|
2007-08-25 03:39:57 +02:00
|
|
|
|
2016-09-29 17:45:35 +02:00
|
|
|
static void vnc_display_close(VncDisplay *vd)
|
2007-08-25 03:35:38 +02:00
|
|
|
{
|
2016-09-29 17:45:35 +02:00
|
|
|
if (!vd) {
|
2009-02-11 22:00:38 +01:00
|
|
|
return;
|
2016-09-29 17:45:35 +02:00
|
|
|
}
|
|
|
|
vd->is_unix = false;
|
2018-02-01 17:45:14 +01:00
|
|
|
|
|
|
|
if (vd->listener) {
|
|
|
|
qio_net_listener_disconnect(vd->listener);
|
|
|
|
object_unref(OBJECT(vd->listener));
|
2007-08-25 03:35:38 +02:00
|
|
|
}
|
2018-02-01 17:45:14 +01:00
|
|
|
vd->listener = NULL;
|
2017-02-03 13:06:44 +01:00
|
|
|
|
2018-02-01 17:45:14 +01:00
|
|
|
if (vd->wslistener) {
|
|
|
|
qio_net_listener_disconnect(vd->wslistener);
|
|
|
|
object_unref(OBJECT(vd->wslistener));
|
2013-01-21 11:04:44 +01:00
|
|
|
}
|
2018-02-01 17:45:14 +01:00
|
|
|
vd->wslistener = NULL;
|
2017-02-03 13:06:44 +01:00
|
|
|
|
2016-09-29 17:45:35 +02:00
|
|
|
vd->auth = VNC_AUTH_INVALID;
|
|
|
|
vd->subauth = VNC_AUTH_INVALID;
|
|
|
|
if (vd->tlscreds) {
|
2021-01-11 14:19:11 +01:00
|
|
|
object_unref(OBJECT(vd->tlscreds));
|
2016-09-29 17:45:35 +02:00
|
|
|
vd->tlscreds = NULL;
|
ui: convert VNC server to use QCryptoTLSSession
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-08-06 15:39:32 +02:00
|
|
|
}
|
2016-02-18 19:40:24 +01:00
|
|
|
if (vd->tlsauthz) {
|
|
|
|
object_unparent(OBJECT(vd->tlsauthz));
|
|
|
|
vd->tlsauthz = NULL;
|
|
|
|
}
|
|
|
|
g_free(vd->tlsauthzid);
|
|
|
|
vd->tlsauthzid = NULL;
|
2017-01-09 17:14:02 +01:00
|
|
|
if (vd->lock_key_sync) {
|
|
|
|
qemu_remove_led_event_handler(vd->led);
|
2017-02-21 14:05:32 +01:00
|
|
|
vd->led = NULL;
|
2017-01-09 17:14:02 +01:00
|
|
|
}
|
2016-02-18 19:40:24 +01:00
|
|
|
#ifdef CONFIG_VNC_SASL
|
|
|
|
if (vd->sasl.authz) {
|
|
|
|
object_unparent(OBJECT(vd->sasl.authz));
|
|
|
|
vd->sasl.authz = NULL;
|
|
|
|
}
|
|
|
|
g_free(vd->sasl.authzid);
|
|
|
|
vd->sasl.authzid = NULL;
|
|
|
|
#endif
|
2007-08-25 03:37:05 +02:00
|
|
|
}
|
|
|
|
|
2014-07-29 12:24:55 +02:00
|
|
|
int vnc_display_password(const char *id, const char *password)
|
2007-08-25 03:37:05 +02:00
|
|
|
{
|
2016-09-29 17:45:35 +02:00
|
|
|
VncDisplay *vd = vnc_display_find(id);
|
2007-08-25 03:37:05 +02:00
|
|
|
|
2016-09-29 17:45:35 +02:00
|
|
|
if (!vd) {
|
2011-12-07 13:19:10 +01:00
|
|
|
return -EINVAL;
|
2009-07-30 12:15:00 +02:00
|
|
|
}
|
2016-09-29 17:45:35 +02:00
|
|
|
if (vd->auth == VNC_AUTH_NONE) {
|
2013-12-11 13:15:37 +01:00
|
|
|
error_printf_unless_qmp("If you want use passwords please enable "
|
2016-08-03 13:37:54 +02:00
|
|
|
"password auth using '-vnc ${dpy},password'.\n");
|
2013-12-11 13:15:37 +01:00
|
|
|
return -EINVAL;
|
2011-01-31 21:27:36 +01:00
|
|
|
}
|
|
|
|
|
2016-09-29 17:45:35 +02:00
|
|
|
g_free(vd->password);
|
|
|
|
vd->password = g_strdup(password);
|
2011-12-07 13:19:10 +01:00
|
|
|
|
|
|
|
return 0;
|
2007-08-25 03:35:38 +02:00
|
|
|
}
|
|
|
|
|
2014-07-29 12:24:55 +02:00
|
|
|
int vnc_display_pw_expire(const char *id, time_t expires)
|
2010-10-07 11:50:45 +02:00
|
|
|
{
|
2016-09-29 17:45:35 +02:00
|
|
|
VncDisplay *vd = vnc_display_find(id);
|
2010-10-07 11:50:45 +02:00
|
|
|
|
2016-09-29 17:45:35 +02:00
|
|
|
if (!vd) {
|
2012-05-24 10:55:01 +02:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2016-09-29 17:45:35 +02:00
|
|
|
vd->expires = expires;
|
2010-10-07 11:50:45 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-09-29 17:45:35 +02:00
|
|
|
static void vnc_display_print_local_addr(VncDisplay *vd)
|
2009-05-20 20:01:02 +02:00
|
|
|
{
|
2017-04-26 09:36:41 +02:00
|
|
|
SocketAddress *addr;
|
2014-07-29 12:14:08 +02:00
|
|
|
|
2018-02-01 17:45:14 +01:00
|
|
|
if (!vd->listener || !vd->listener->nsioc) {
|
2017-02-03 13:06:44 +01:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2020-06-30 11:03:36 +02:00
|
|
|
addr = qio_channel_socket_get_local_address(vd->listener->sioc[0], NULL);
|
2015-02-27 17:20:57 +01:00
|
|
|
if (!addr) {
|
2016-05-31 14:59:08 +02:00
|
|
|
return;
|
2015-02-27 17:20:57 +01:00
|
|
|
}
|
|
|
|
|
2017-04-26 09:36:41 +02:00
|
|
|
if (addr->type != SOCKET_ADDRESS_TYPE_INET) {
|
|
|
|
qapi_free_SocketAddress(addr);
|
2016-05-31 14:59:08 +02:00
|
|
|
return;
|
2015-02-27 17:20:57 +01:00
|
|
|
}
|
2016-05-31 14:59:08 +02:00
|
|
|
error_printf_unless_qmp("VNC server running on %s:%s\n",
|
2017-04-26 09:36:41 +02:00
|
|
|
addr->u.inet.host,
|
|
|
|
addr->u.inet.port);
|
|
|
|
qapi_free_SocketAddress(addr);
|
2009-05-20 20:01:02 +02:00
|
|
|
}
|
|
|
|
|
2014-09-16 12:33:03 +02:00
|
|
|
static QemuOptsList qemu_vnc_opts = {
|
|
|
|
.name = "vnc",
|
|
|
|
.head = QTAILQ_HEAD_INITIALIZER(qemu_vnc_opts.head),
|
|
|
|
.implied_opt_name = "vnc",
|
|
|
|
.desc = {
|
|
|
|
{
|
|
|
|
.name = "vnc",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
},{
|
|
|
|
.name = "websocket",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
},{
|
ui: convert VNC server to use QCryptoTLSSession
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-08-06 15:39:32 +02:00
|
|
|
.name = "tls-creds",
|
|
|
|
.type = QEMU_OPT_STRING,
|
2014-09-16 12:33:03 +02:00
|
|
|
},{
|
|
|
|
.name = "share",
|
|
|
|
.type = QEMU_OPT_STRING,
|
2014-09-18 12:54:49 +02:00
|
|
|
},{
|
|
|
|
.name = "display",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
},{
|
|
|
|
.name = "head",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
2014-10-02 12:09:34 +02:00
|
|
|
},{
|
|
|
|
.name = "connections",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
2015-01-30 03:14:34 +01:00
|
|
|
},{
|
|
|
|
.name = "to",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
|
|
|
},{
|
|
|
|
.name = "ipv4",
|
|
|
|
.type = QEMU_OPT_BOOL,
|
|
|
|
},{
|
|
|
|
.name = "ipv6",
|
|
|
|
.type = QEMU_OPT_BOOL,
|
2014-09-16 12:33:03 +02:00
|
|
|
},{
|
|
|
|
.name = "password",
|
|
|
|
.type = QEMU_OPT_BOOL,
|
2021-03-11 12:43:41 +01:00
|
|
|
},{
|
|
|
|
.name = "password-secret",
|
|
|
|
.type = QEMU_OPT_STRING,
|
2014-09-16 12:33:03 +02:00
|
|
|
},{
|
|
|
|
.name = "reverse",
|
|
|
|
.type = QEMU_OPT_BOOL,
|
|
|
|
},{
|
|
|
|
.name = "lock-key-sync",
|
|
|
|
.type = QEMU_OPT_BOOL,
|
2016-06-01 08:22:30 +02:00
|
|
|
},{
|
|
|
|
.name = "key-delay-ms",
|
|
|
|
.type = QEMU_OPT_NUMBER,
|
2014-09-16 12:33:03 +02:00
|
|
|
},{
|
|
|
|
.name = "sasl",
|
|
|
|
.type = QEMU_OPT_BOOL,
|
vnc: allow specifying a custom authorization object name
The VNC server has historically had support for ACLs to check both the
SASL username and the TLS x509 distinguished name. The VNC server was
responsible for creating the initial ACL, and the client app was then
responsible for populating it with rules using the HMP 'acl_add' command.
This is not satisfactory for a variety of reasons. There is no way to
populate the ACLs from the command line, users are forced to use the
HMP. With multiple network services all supporting TLS and ACLs now, it
is desirable to be able to define a single ACL that is referenced by all
services.
To address these limitations, two new options are added to the VNC
server CLI. The 'tls-authz' option takes the ID of a QAuthZ object to
use for checking TLS x509 distinguished names, and the 'sasl-authz'
option takes the ID of another object to use for checking SASL usernames.
In this example, we setup two authorization rules. The first allows any
client with a certificate issued by the 'RedHat' organization in the
'London' locality. The second ACL allows clients with either the
'joe@REDHAT.COM' or 'fred@REDHAT.COM' kerberos usernames. Both checks
must pass for the user to be allowed.
$QEMU -object tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\
endpoint=server,verify-peer=yes \
-object authz-simple,id=authz0,policy=deny,\
rules.0.match=O=RedHat,,L=London,rules.0.policy=allow \
-object authz-simple,id=authz1,policy=deny,\
rules.0.match=fred@REDHAT.COM,rules.0.policy=allow \
rules.0.match=joe@REDHAT.COM,rules.0.policy=allow \
-vnc 0.0.0.0:1,tls-creds=tls0,tls-authz=authz0,
sasl,sasl-authz=authz1 \
...other QEMU args...
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20190227145755.26556-2-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-02-27 15:57:54 +01:00
|
|
|
},{
|
|
|
|
.name = "tls-authz",
|
|
|
|
.type = QEMU_OPT_STRING,
|
|
|
|
},{
|
|
|
|
.name = "sasl-authz",
|
|
|
|
.type = QEMU_OPT_STRING,
|
2014-09-16 12:33:03 +02:00
|
|
|
},{
|
|
|
|
.name = "lossy",
|
|
|
|
.type = QEMU_OPT_BOOL,
|
|
|
|
},{
|
|
|
|
.name = "non-adaptive",
|
|
|
|
.type = QEMU_OPT_BOOL,
|
2019-08-19 01:06:48 +02:00
|
|
|
},{
|
|
|
|
.name = "audiodev",
|
|
|
|
.type = QEMU_OPT_STRING,
|
2020-12-11 17:08:25 +01:00
|
|
|
},{
|
|
|
|
.name = "power-control",
|
|
|
|
.type = QEMU_OPT_BOOL,
|
2014-09-16 12:33:03 +02:00
|
|
|
},
|
|
|
|
{ /* end of list */ }
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2015-03-17 14:42:56 +01:00
|
|
|
|
ui: convert VNC server to use QCryptoTLSSession
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-08-06 15:39:32 +02:00
|
|
|
static int
|
2016-09-29 17:45:36 +02:00
|
|
|
vnc_display_setup_auth(int *auth,
|
|
|
|
int *subauth,
|
|
|
|
QCryptoTLSCreds *tlscreds,
|
2015-03-17 14:42:56 +01:00
|
|
|
bool password,
|
|
|
|
bool sasl,
|
ui: convert VNC server to use QCryptoTLSSession
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-08-06 15:39:32 +02:00
|
|
|
bool websocket,
|
|
|
|
Error **errp)
|
2015-03-17 14:42:56 +01:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* We have a choice of 3 authentication options
|
|
|
|
*
|
|
|
|
* 1. none
|
|
|
|
* 2. vnc
|
|
|
|
* 3. sasl
|
|
|
|
*
|
|
|
|
* The channel can be run in 2 modes
|
|
|
|
*
|
|
|
|
* 1. clear
|
|
|
|
* 2. tls
|
|
|
|
*
|
|
|
|
* And TLS can use 2 types of credentials
|
|
|
|
*
|
|
|
|
* 1. anon
|
|
|
|
* 2. x509
|
|
|
|
*
|
|
|
|
* We thus have 9 possible logical combinations
|
|
|
|
*
|
|
|
|
* 1. clear + none
|
|
|
|
* 2. clear + vnc
|
|
|
|
* 3. clear + sasl
|
|
|
|
* 4. tls + anon + none
|
|
|
|
* 5. tls + anon + vnc
|
|
|
|
* 6. tls + anon + sasl
|
|
|
|
* 7. tls + x509 + none
|
|
|
|
* 8. tls + x509 + vnc
|
|
|
|
* 9. tls + x509 + sasl
|
|
|
|
*
|
|
|
|
* These need to be mapped into the VNC auth schemes
|
|
|
|
* in an appropriate manner. In regular VNC, all the
|
|
|
|
* TLS options get mapped into VNC_AUTH_VENCRYPT
|
|
|
|
* sub-auth types.
|
2015-03-17 14:42:57 +01:00
|
|
|
*
|
|
|
|
* In websockets, the https:// protocol already provides
|
|
|
|
* TLS support, so there is no need to make use of the
|
|
|
|
* VeNCrypt extension. Furthermore, websockets browser
|
|
|
|
* clients could not use VeNCrypt even if they wanted to,
|
|
|
|
* as they cannot control when the TLS handshake takes
|
|
|
|
* place. Thus there is no option but to rely on https://,
|
|
|
|
* meaning combinations 4->6 and 7->9 will be mapped to
|
|
|
|
* VNC auth schemes in the same way as combos 1->3.
|
|
|
|
*
|
|
|
|
* Regardless of fact that we have a different mapping to
|
|
|
|
* VNC auth mechs for plain VNC vs websockets VNC, the end
|
|
|
|
* result has the same security characteristics.
|
2015-03-17 14:42:56 +01:00
|
|
|
*/
|
2016-09-29 17:45:36 +02:00
|
|
|
if (websocket || !tlscreds) {
|
|
|
|
if (password) {
|
2015-03-17 14:42:56 +01:00
|
|
|
VNC_DEBUG("Initializing VNC server with password auth\n");
|
2016-09-29 17:45:36 +02:00
|
|
|
*auth = VNC_AUTH_VNC;
|
|
|
|
} else if (sasl) {
|
|
|
|
VNC_DEBUG("Initializing VNC server with SASL auth\n");
|
|
|
|
*auth = VNC_AUTH_SASL;
|
2015-03-17 14:42:57 +01:00
|
|
|
} else {
|
2016-09-29 17:45:36 +02:00
|
|
|
VNC_DEBUG("Initializing VNC server with no auth\n");
|
|
|
|
*auth = VNC_AUTH_NONE;
|
2015-03-17 14:42:57 +01:00
|
|
|
}
|
2016-09-29 17:45:36 +02:00
|
|
|
*subauth = VNC_AUTH_INVALID;
|
|
|
|
} else {
|
|
|
|
bool is_x509 = object_dynamic_cast(OBJECT(tlscreds),
|
|
|
|
TYPE_QCRYPTO_TLS_CREDS_X509) != NULL;
|
|
|
|
bool is_anon = object_dynamic_cast(OBJECT(tlscreds),
|
|
|
|
TYPE_QCRYPTO_TLS_CREDS_ANON) != NULL;
|
|
|
|
|
|
|
|
if (!is_x509 && !is_anon) {
|
|
|
|
error_setg(errp,
|
|
|
|
"Unsupported TLS cred type %s",
|
|
|
|
object_get_typename(OBJECT(tlscreds)));
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
*auth = VNC_AUTH_VENCRYPT;
|
|
|
|
if (password) {
|
|
|
|
if (is_x509) {
|
|
|
|
VNC_DEBUG("Initializing VNC server with x509 password auth\n");
|
|
|
|
*subauth = VNC_AUTH_VENCRYPT_X509VNC;
|
|
|
|
} else {
|
|
|
|
VNC_DEBUG("Initializing VNC server with TLS password auth\n");
|
|
|
|
*subauth = VNC_AUTH_VENCRYPT_TLSVNC;
|
|
|
|
}
|
|
|
|
|
|
|
|
} else if (sasl) {
|
|
|
|
if (is_x509) {
|
2015-03-17 14:42:56 +01:00
|
|
|
VNC_DEBUG("Initializing VNC server with x509 SASL auth\n");
|
2016-09-29 17:45:36 +02:00
|
|
|
*subauth = VNC_AUTH_VENCRYPT_X509SASL;
|
ui: convert VNC server to use QCryptoTLSSession
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-08-06 15:39:32 +02:00
|
|
|
} else {
|
2016-09-29 17:45:36 +02:00
|
|
|
VNC_DEBUG("Initializing VNC server with TLS SASL auth\n");
|
|
|
|
*subauth = VNC_AUTH_VENCRYPT_TLSSASL;
|
2015-03-17 14:42:56 +01:00
|
|
|
}
|
|
|
|
} else {
|
2016-09-29 17:45:36 +02:00
|
|
|
if (is_x509) {
|
2015-03-17 14:42:56 +01:00
|
|
|
VNC_DEBUG("Initializing VNC server with x509 no auth\n");
|
2016-09-29 17:45:36 +02:00
|
|
|
*subauth = VNC_AUTH_VENCRYPT_X509NONE;
|
ui: convert VNC server to use QCryptoTLSSession
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-08-06 15:39:32 +02:00
|
|
|
} else {
|
2016-09-29 17:45:36 +02:00
|
|
|
VNC_DEBUG("Initializing VNC server with TLS no auth\n");
|
|
|
|
*subauth = VNC_AUTH_VENCRYPT_TLSNONE;
|
2015-03-17 14:42:56 +01:00
|
|
|
}
|
2015-03-17 14:42:57 +01:00
|
|
|
}
|
2015-03-17 14:42:56 +01:00
|
|
|
}
|
ui: convert VNC server to use QCryptoTLSSession
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-08-06 15:39:32 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2017-02-03 13:06:45 +01:00
|
|
|
static int vnc_display_get_address(const char *addrstr,
|
|
|
|
bool websocket,
|
2017-03-14 09:26:58 +01:00
|
|
|
bool reverse,
|
2017-02-03 13:06:45 +01:00
|
|
|
int displaynum,
|
|
|
|
int to,
|
|
|
|
bool has_ipv4,
|
|
|
|
bool has_ipv6,
|
|
|
|
bool ipv4,
|
|
|
|
bool ipv6,
|
2017-04-26 09:36:41 +02:00
|
|
|
SocketAddress **retaddr,
|
2017-02-03 13:06:45 +01:00
|
|
|
Error **errp)
|
|
|
|
{
|
|
|
|
int ret = -1;
|
2017-04-26 09:36:41 +02:00
|
|
|
SocketAddress *addr = NULL;
|
2017-02-03 13:06:45 +01:00
|
|
|
|
2017-04-26 09:36:41 +02:00
|
|
|
addr = g_new0(SocketAddress, 1);
|
2017-02-03 13:06:45 +01:00
|
|
|
|
|
|
|
if (strncmp(addrstr, "unix:", 5) == 0) {
|
2017-04-26 09:36:41 +02:00
|
|
|
addr->type = SOCKET_ADDRESS_TYPE_UNIX;
|
|
|
|
addr->u.q_unix.path = g_strdup(addrstr + 5);
|
2017-02-03 13:06:45 +01:00
|
|
|
|
|
|
|
if (websocket) {
|
|
|
|
error_setg(errp, "UNIX sockets not supported with websock");
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (to) {
|
|
|
|
error_setg(errp, "Port range not support with UNIX socket");
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
ret = 0;
|
|
|
|
} else {
|
|
|
|
const char *port;
|
|
|
|
size_t hostlen;
|
2023-05-22 21:04:29 +02:00
|
|
|
uint64_t baseport = 0;
|
2017-02-03 13:06:45 +01:00
|
|
|
InetSocketAddress *inet;
|
|
|
|
|
|
|
|
port = strrchr(addrstr, ':');
|
|
|
|
if (!port) {
|
|
|
|
if (websocket) {
|
|
|
|
hostlen = 0;
|
|
|
|
port = addrstr;
|
|
|
|
} else {
|
|
|
|
error_setg(errp, "no vnc port specified");
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
hostlen = port - addrstr;
|
|
|
|
port++;
|
|
|
|
if (*port == '\0') {
|
|
|
|
error_setg(errp, "vnc port cannot be empty");
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-04-26 09:36:41 +02:00
|
|
|
addr->type = SOCKET_ADDRESS_TYPE_INET;
|
|
|
|
inet = &addr->u.inet;
|
2023-03-30 14:23:40 +02:00
|
|
|
if (hostlen && addrstr[0] == '[' && addrstr[hostlen - 1] == ']') {
|
2017-02-03 13:06:45 +01:00
|
|
|
inet->host = g_strndup(addrstr + 1, hostlen - 2);
|
|
|
|
} else {
|
|
|
|
inet->host = g_strndup(addrstr, hostlen);
|
|
|
|
}
|
|
|
|
/* plain VNC port is just an offset, for websocket
|
|
|
|
* port is absolute */
|
|
|
|
if (websocket) {
|
|
|
|
if (g_str_equal(addrstr, "") ||
|
|
|
|
g_str_equal(addrstr, "on")) {
|
2017-02-03 13:06:49 +01:00
|
|
|
if (displaynum == -1) {
|
|
|
|
error_setg(errp, "explicit websocket port is required");
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2017-02-03 13:06:45 +01:00
|
|
|
inet->port = g_strdup_printf(
|
|
|
|
"%d", displaynum + 5700);
|
|
|
|
if (to) {
|
|
|
|
inet->has_to = true;
|
|
|
|
inet->to = to + 5700;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
inet->port = g_strdup(port);
|
|
|
|
}
|
|
|
|
} else {
|
2017-03-14 09:26:58 +01:00
|
|
|
int offset = reverse ? 0 : 5900;
|
2023-05-22 21:04:29 +02:00
|
|
|
if (parse_uint_full(port, 10, &baseport) < 0) {
|
2017-02-03 13:06:45 +01:00
|
|
|
error_setg(errp, "can't convert to a number: %s", port);
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
if (baseport > 65535 ||
|
2017-03-14 09:26:58 +01:00
|
|
|
baseport + offset > 65535) {
|
2017-02-03 13:06:45 +01:00
|
|
|
error_setg(errp, "port %s out of range", port);
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
inet->port = g_strdup_printf(
|
2017-03-14 09:26:58 +01:00
|
|
|
"%d", (int)baseport + offset);
|
2017-02-03 13:06:45 +01:00
|
|
|
|
|
|
|
if (to) {
|
|
|
|
inet->has_to = true;
|
2017-03-14 09:26:58 +01:00
|
|
|
inet->to = to + offset;
|
2017-02-03 13:06:45 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
inet->ipv4 = ipv4;
|
|
|
|
inet->has_ipv4 = has_ipv4;
|
|
|
|
inet->ipv6 = ipv6;
|
|
|
|
inet->has_ipv6 = has_ipv6;
|
|
|
|
|
|
|
|
ret = baseport;
|
|
|
|
}
|
|
|
|
|
|
|
|
*retaddr = addr;
|
|
|
|
|
|
|
|
cleanup:
|
|
|
|
if (ret < 0) {
|
2017-04-26 09:36:41 +02:00
|
|
|
qapi_free_SocketAddress(addr);
|
2017-02-03 13:06:45 +01:00
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int vnc_display_get_addresses(QemuOpts *opts,
|
2017-03-14 09:26:58 +01:00
|
|
|
bool reverse,
|
2022-04-01 16:39:34 +02:00
|
|
|
SocketAddressList **saddr_list_ret,
|
|
|
|
SocketAddressList **wsaddr_list_ret,
|
2017-02-03 13:06:45 +01:00
|
|
|
Error **errp)
|
|
|
|
{
|
2017-04-26 09:36:41 +02:00
|
|
|
SocketAddress *saddr = NULL;
|
|
|
|
SocketAddress *wsaddr = NULL;
|
2022-04-01 16:39:34 +02:00
|
|
|
g_autoptr(SocketAddressList) saddr_list = NULL;
|
|
|
|
SocketAddressList **saddr_tail = &saddr_list;
|
|
|
|
SocketAddress *single_saddr = NULL;
|
|
|
|
g_autoptr(SocketAddressList) wsaddr_list = NULL;
|
|
|
|
SocketAddressList **wsaddr_tail = &wsaddr_list;
|
2017-02-03 13:06:49 +01:00
|
|
|
QemuOptsIter addriter;
|
|
|
|
const char *addr;
|
2017-02-03 13:06:45 +01:00
|
|
|
int to = qemu_opt_get_number(opts, "to", 0);
|
|
|
|
bool has_ipv4 = qemu_opt_get(opts, "ipv4");
|
|
|
|
bool has_ipv6 = qemu_opt_get(opts, "ipv6");
|
|
|
|
bool ipv4 = qemu_opt_get_bool(opts, "ipv4", false);
|
|
|
|
bool ipv6 = qemu_opt_get_bool(opts, "ipv6", false);
|
2017-02-03 13:06:49 +01:00
|
|
|
int displaynum = -1;
|
2017-02-03 13:06:45 +01:00
|
|
|
|
2017-02-03 13:06:49 +01:00
|
|
|
addr = qemu_opt_get(opts, "vnc");
|
|
|
|
if (addr == NULL || g_str_equal(addr, "none")) {
|
2022-04-01 16:39:34 +02:00
|
|
|
return 0;
|
2017-02-03 13:06:49 +01:00
|
|
|
}
|
|
|
|
if (qemu_opt_get(opts, "websocket") &&
|
2017-02-03 13:06:45 +01:00
|
|
|
!qcrypto_hash_supports(QCRYPTO_HASH_ALG_SHA1)) {
|
|
|
|
error_setg(errp,
|
|
|
|
"SHA1 hash support is required for websockets");
|
2022-04-01 16:39:34 +02:00
|
|
|
return -1;
|
2017-02-03 13:06:49 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
qemu_opt_iter_init(&addriter, opts, "vnc");
|
|
|
|
while ((addr = qemu_opt_iter_next(&addriter)) != NULL) {
|
|
|
|
int rv;
|
2017-03-14 09:26:58 +01:00
|
|
|
rv = vnc_display_get_address(addr, false, reverse, 0, to,
|
2017-02-03 13:06:49 +01:00
|
|
|
has_ipv4, has_ipv6,
|
|
|
|
ipv4, ipv6,
|
|
|
|
&saddr, errp);
|
|
|
|
if (rv < 0) {
|
2022-04-01 16:39:34 +02:00
|
|
|
return -1;
|
2017-02-03 13:06:49 +01:00
|
|
|
}
|
|
|
|
/* Historical compat - first listen address can be used
|
|
|
|
* to set the default websocket port
|
|
|
|
*/
|
|
|
|
if (displaynum == -1) {
|
|
|
|
displaynum = rv;
|
|
|
|
}
|
2022-04-01 16:39:34 +02:00
|
|
|
QAPI_LIST_APPEND(saddr_tail, saddr);
|
2017-02-03 13:06:45 +01:00
|
|
|
}
|
|
|
|
|
2022-04-01 16:39:34 +02:00
|
|
|
if (saddr_list && !saddr_list->next) {
|
|
|
|
single_saddr = saddr_list->value;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* If we had multiple primary displays, we don't do defaults
|
|
|
|
* for websocket, and require explicit config instead.
|
|
|
|
*/
|
2017-02-03 13:06:49 +01:00
|
|
|
displaynum = -1;
|
2017-02-03 13:06:45 +01:00
|
|
|
}
|
2017-02-03 13:06:49 +01:00
|
|
|
|
|
|
|
qemu_opt_iter_init(&addriter, opts, "websocket");
|
|
|
|
while ((addr = qemu_opt_iter_next(&addriter)) != NULL) {
|
2017-03-14 09:26:58 +01:00
|
|
|
if (vnc_display_get_address(addr, true, reverse, displaynum, to,
|
2017-02-03 13:06:45 +01:00
|
|
|
has_ipv4, has_ipv6,
|
|
|
|
ipv4, ipv6,
|
|
|
|
&wsaddr, errp) < 0) {
|
2022-04-01 16:39:34 +02:00
|
|
|
return -1;
|
2017-02-03 13:06:45 +01:00
|
|
|
}
|
2017-02-03 13:06:49 +01:00
|
|
|
|
|
|
|
/* Historical compat - if only a single listen address was
|
|
|
|
* provided, then this is used to set the default listen
|
|
|
|
* address for websocket too
|
|
|
|
*/
|
2022-04-01 16:39:34 +02:00
|
|
|
if (single_saddr &&
|
|
|
|
single_saddr->type == SOCKET_ADDRESS_TYPE_INET &&
|
2017-04-26 09:36:41 +02:00
|
|
|
wsaddr->type == SOCKET_ADDRESS_TYPE_INET &&
|
|
|
|
g_str_equal(wsaddr->u.inet.host, "") &&
|
2022-04-01 16:39:34 +02:00
|
|
|
!g_str_equal(single_saddr->u.inet.host, "")) {
|
2017-04-26 09:36:41 +02:00
|
|
|
g_free(wsaddr->u.inet.host);
|
2022-04-01 16:39:34 +02:00
|
|
|
wsaddr->u.inet.host = g_strdup(single_saddr->u.inet.host);
|
2017-02-03 13:06:45 +01:00
|
|
|
}
|
2017-02-03 13:06:49 +01:00
|
|
|
|
2022-04-01 16:39:34 +02:00
|
|
|
QAPI_LIST_APPEND(wsaddr_tail, wsaddr);
|
2017-02-03 13:06:45 +01:00
|
|
|
}
|
|
|
|
|
2022-04-01 16:39:34 +02:00
|
|
|
*saddr_list_ret = g_steal_pointer(&saddr_list);
|
|
|
|
*wsaddr_list_ret = g_steal_pointer(&wsaddr_list);
|
|
|
|
return 0;
|
2017-02-03 13:06:45 +01:00
|
|
|
}
|
|
|
|
|
2017-02-03 13:06:46 +01:00
|
|
|
static int vnc_display_connect(VncDisplay *vd,
|
2022-04-01 16:39:34 +02:00
|
|
|
SocketAddressList *saddr_list,
|
|
|
|
SocketAddressList *wsaddr_list,
|
2017-02-03 13:06:46 +01:00
|
|
|
Error **errp)
|
|
|
|
{
|
|
|
|
/* connect to viewer */
|
|
|
|
QIOChannelSocket *sioc = NULL;
|
2022-04-01 16:39:34 +02:00
|
|
|
if (wsaddr_list) {
|
2017-02-03 13:06:46 +01:00
|
|
|
error_setg(errp, "Cannot use websockets in reverse mode");
|
|
|
|
return -1;
|
|
|
|
}
|
2022-04-01 16:39:34 +02:00
|
|
|
if (!saddr_list || saddr_list->next) {
|
2017-02-03 13:06:49 +01:00
|
|
|
error_setg(errp, "Expected a single address in reverse mode");
|
|
|
|
return -1;
|
|
|
|
}
|
2017-04-26 09:36:41 +02:00
|
|
|
/* TODO SOCKET_ADDRESS_TYPE_FD when fd has AF_UNIX */
|
2022-04-01 16:39:34 +02:00
|
|
|
vd->is_unix = saddr_list->value->type == SOCKET_ADDRESS_TYPE_UNIX;
|
2017-02-03 13:06:46 +01:00
|
|
|
sioc = qio_channel_socket_new();
|
|
|
|
qio_channel_set_name(QIO_CHANNEL(sioc), "vnc-reverse");
|
2022-04-01 16:39:34 +02:00
|
|
|
if (qio_channel_socket_connect_sync(sioc, saddr_list->value, errp) < 0) {
|
2020-11-26 07:57:02 +01:00
|
|
|
object_unref(OBJECT(sioc));
|
2017-02-03 13:06:46 +01:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
vnc_connect(vd, sioc, false, false);
|
|
|
|
object_unref(OBJECT(sioc));
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static int vnc_display_listen(VncDisplay *vd,
|
2022-04-01 16:39:34 +02:00
|
|
|
SocketAddressList *saddr_list,
|
|
|
|
SocketAddressList *wsaddr_list,
|
2017-02-03 13:06:46 +01:00
|
|
|
Error **errp)
|
|
|
|
{
|
2022-04-01 16:39:34 +02:00
|
|
|
SocketAddressList *el;
|
2017-02-03 13:06:46 +01:00
|
|
|
|
2022-04-01 16:39:34 +02:00
|
|
|
if (saddr_list) {
|
2018-02-01 17:45:14 +01:00
|
|
|
vd->listener = qio_net_listener_new();
|
|
|
|
qio_net_listener_set_name(vd->listener, "vnc-listen");
|
2022-04-01 16:39:34 +02:00
|
|
|
for (el = saddr_list; el; el = el->next) {
|
2018-02-01 17:45:14 +01:00
|
|
|
if (qio_net_listener_open_sync(vd->listener,
|
2022-04-01 16:39:34 +02:00
|
|
|
el->value, 1,
|
2018-02-01 17:45:14 +01:00
|
|
|
errp) < 0) {
|
|
|
|
return -1;
|
|
|
|
}
|
2017-02-03 13:06:49 +01:00
|
|
|
}
|
2018-02-01 17:45:14 +01:00
|
|
|
|
|
|
|
qio_net_listener_set_client_func(vd->listener,
|
|
|
|
vnc_listen_io, vd, NULL);
|
2017-02-03 13:06:46 +01:00
|
|
|
}
|
2018-02-01 17:45:14 +01:00
|
|
|
|
2022-04-01 16:39:34 +02:00
|
|
|
if (wsaddr_list) {
|
2018-02-01 17:45:14 +01:00
|
|
|
vd->wslistener = qio_net_listener_new();
|
|
|
|
qio_net_listener_set_name(vd->wslistener, "vnc-ws-listen");
|
2022-04-01 16:39:34 +02:00
|
|
|
for (el = wsaddr_list; el; el = el->next) {
|
2018-02-01 17:45:14 +01:00
|
|
|
if (qio_net_listener_open_sync(vd->wslistener,
|
2022-04-01 16:39:34 +02:00
|
|
|
el->value, 1,
|
2018-02-01 17:45:14 +01:00
|
|
|
errp) < 0) {
|
|
|
|
return -1;
|
|
|
|
}
|
2017-02-03 13:06:49 +01:00
|
|
|
}
|
2018-02-01 17:45:14 +01:00
|
|
|
|
|
|
|
qio_net_listener_set_client_func(vd->wslistener,
|
|
|
|
vnc_listen_io, vd, NULL);
|
2017-02-03 13:06:46 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2022-04-01 16:39:35 +02:00
|
|
|
bool vnc_display_update(DisplayUpdateOptionsVNC *arg, Error **errp)
|
|
|
|
{
|
|
|
|
VncDisplay *vd = vnc_display_find(NULL);
|
|
|
|
|
|
|
|
if (!vd) {
|
|
|
|
error_setg(errp, "Can not find vnc display");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (arg->has_addresses) {
|
|
|
|
if (vd->listener) {
|
|
|
|
qio_net_listener_disconnect(vd->listener);
|
|
|
|
object_unref(OBJECT(vd->listener));
|
|
|
|
vd->listener = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (vnc_display_listen(vd, arg->addresses, NULL, errp) < 0) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
2017-02-03 13:06:46 +01:00
|
|
|
|
2014-09-16 12:33:03 +02:00
|
|
|
void vnc_display_open(const char *id, Error **errp)
|
2007-08-25 03:35:38 +02:00
|
|
|
{
|
2016-09-29 17:45:35 +02:00
|
|
|
VncDisplay *vd = vnc_display_find(id);
|
2014-09-16 12:33:03 +02:00
|
|
|
QemuOpts *opts = qemu_opts_find(&qemu_vnc_opts, id);
|
2022-04-01 16:39:34 +02:00
|
|
|
g_autoptr(SocketAddressList) saddr_list = NULL;
|
|
|
|
g_autoptr(SocketAddressList) wsaddr_list = NULL;
|
2015-01-30 03:14:35 +01:00
|
|
|
const char *share, *device_id;
|
2014-09-18 12:54:49 +02:00
|
|
|
QemuConsole *con;
|
2015-01-30 03:14:36 +01:00
|
|
|
bool password = false;
|
|
|
|
bool reverse = false;
|
ui: convert VNC server to use QCryptoTLSSession
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-08-06 15:39:32 +02:00
|
|
|
const char *credid;
|
2015-01-30 03:14:36 +01:00
|
|
|
bool sasl = false;
|
vnc: allow specifying a custom authorization object name
The VNC server has historically had support for ACLs to check both the
SASL username and the TLS x509 distinguished name. The VNC server was
responsible for creating the initial ACL, and the client app was then
responsible for populating it with rules using the HMP 'acl_add' command.
This is not satisfactory for a variety of reasons. There is no way to
populate the ACLs from the command line, users are forced to use the
HMP. With multiple network services all supporting TLS and ACLs now, it
is desirable to be able to define a single ACL that is referenced by all
services.
To address these limitations, two new options are added to the VNC
server CLI. The 'tls-authz' option takes the ID of a QAuthZ object to
use for checking TLS x509 distinguished names, and the 'sasl-authz'
option takes the ID of another object to use for checking SASL usernames.
In this example, we setup two authorization rules. The first allows any
client with a certificate issued by the 'RedHat' organization in the
'London' locality. The second ACL allows clients with either the
'joe@REDHAT.COM' or 'fred@REDHAT.COM' kerberos usernames. Both checks
must pass for the user to be allowed.
$QEMU -object tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\
endpoint=server,verify-peer=yes \
-object authz-simple,id=authz0,policy=deny,\
rules.0.match=O=RedHat,,L=London,rules.0.policy=allow \
-object authz-simple,id=authz1,policy=deny,\
rules.0.match=fred@REDHAT.COM,rules.0.policy=allow \
rules.0.match=joe@REDHAT.COM,rules.0.policy=allow \
-vnc 0.0.0.0:1,tls-creds=tls0,tls-authz=authz0,
sasl,sasl-authz=authz1 \
...other QEMU args...
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20190227145755.26556-2-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-02-27 15:57:54 +01:00
|
|
|
const char *tlsauthz;
|
|
|
|
const char *saslauthz;
|
2010-03-10 17:12:02 +01:00
|
|
|
int lock_key_sync = 1;
|
2016-06-01 08:22:30 +02:00
|
|
|
int key_delay_ms;
|
2019-08-19 01:06:48 +02:00
|
|
|
const char *audiodev;
|
2021-03-11 12:43:41 +01:00
|
|
|
const char *passwordSecret;
|
2007-08-25 03:35:38 +02:00
|
|
|
|
2016-09-29 17:45:35 +02:00
|
|
|
if (!vd) {
|
2012-10-02 10:17:21 +02:00
|
|
|
error_setg(errp, "VNC display not active");
|
|
|
|
return;
|
|
|
|
}
|
2016-09-29 17:45:35 +02:00
|
|
|
vnc_display_close(vd);
|
2006-04-30 23:28:36 +02:00
|
|
|
|
2014-09-16 12:33:03 +02:00
|
|
|
if (!opts) {
|
|
|
|
return;
|
|
|
|
}
|
2015-04-27 17:03:14 +02:00
|
|
|
|
2017-03-14 09:26:58 +01:00
|
|
|
reverse = qemu_opt_get_bool(opts, "reverse", false);
|
2022-04-01 16:39:34 +02:00
|
|
|
if (vnc_display_get_addresses(opts, reverse, &saddr_list, &wsaddr_list,
|
|
|
|
errp) < 0) {
|
2015-02-19 11:31:44 +01:00
|
|
|
goto fail;
|
2015-01-30 03:14:35 +01:00
|
|
|
}
|
2015-02-19 11:31:44 +01:00
|
|
|
|
2021-03-11 12:43:41 +01:00
|
|
|
|
|
|
|
passwordSecret = qemu_opt_get(opts, "password-secret");
|
|
|
|
if (passwordSecret) {
|
|
|
|
if (qemu_opt_get(opts, "password")) {
|
|
|
|
error_setg(errp,
|
|
|
|
"'password' flag is redundant with 'password-secret'");
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
vd->password = qcrypto_secret_lookup_as_utf8(passwordSecret,
|
|
|
|
errp);
|
|
|
|
if (!vd->password) {
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
password = true;
|
|
|
|
} else {
|
|
|
|
password = qemu_opt_get_bool(opts, "password", false);
|
|
|
|
}
|
2015-07-01 19:10:38 +02:00
|
|
|
if (password) {
|
|
|
|
if (!qcrypto_cipher_supports(
|
crypto: replace 'des-rfb' cipher with 'des'
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: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-06-29 15:25:32 +02:00
|
|
|
QCRYPTO_CIPHER_ALG_DES, QCRYPTO_CIPHER_MODE_ECB)) {
|
2015-07-01 19:10:38 +02:00
|
|
|
error_setg(errp,
|
crypto: replace 'des-rfb' cipher with 'des'
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: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-06-29 15:25:32 +02:00
|
|
|
"Cipher backend does not support DES algorithm");
|
2015-07-01 19:10:38 +02:00
|
|
|
goto fail;
|
|
|
|
}
|
2014-09-16 12:33:03 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
lock_key_sync = qemu_opt_get_bool(opts, "lock-key-sync", true);
|
2017-07-12 14:43:45 +02:00
|
|
|
key_delay_ms = qemu_opt_get_number(opts, "key-delay-ms", 10);
|
2014-09-16 12:33:03 +02:00
|
|
|
sasl = qemu_opt_get_bool(opts, "sasl", false);
|
2015-03-17 14:42:55 +01:00
|
|
|
#ifndef CONFIG_VNC_SASL
|
|
|
|
if (sasl) {
|
|
|
|
error_setg(errp, "VNC SASL auth requires cyrus-sasl support");
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_VNC_SASL */
|
ui: convert VNC server to use QCryptoTLSSession
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-08-06 15:39:32 +02:00
|
|
|
credid = qemu_opt_get(opts, "tls-creds");
|
|
|
|
if (credid) {
|
|
|
|
Object *creds;
|
|
|
|
creds = object_resolve_path_component(
|
|
|
|
object_get_objects_root(), credid);
|
|
|
|
if (!creds) {
|
|
|
|
error_setg(errp, "No TLS credentials with id '%s'",
|
|
|
|
credid);
|
|
|
|
goto fail;
|
|
|
|
}
|
2016-09-29 17:45:35 +02:00
|
|
|
vd->tlscreds = (QCryptoTLSCreds *)
|
ui: convert VNC server to use QCryptoTLSSession
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-08-06 15:39:32 +02:00
|
|
|
object_dynamic_cast(creds,
|
|
|
|
TYPE_QCRYPTO_TLS_CREDS);
|
2016-09-29 17:45:35 +02:00
|
|
|
if (!vd->tlscreds) {
|
ui: convert VNC server to use QCryptoTLSSession
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-08-06 15:39:32 +02:00
|
|
|
error_setg(errp, "Object with id '%s' is not TLS credentials",
|
|
|
|
credid);
|
|
|
|
goto fail;
|
|
|
|
}
|
2016-09-29 17:45:35 +02:00
|
|
|
object_ref(OBJECT(vd->tlscreds));
|
ui: convert VNC server to use QCryptoTLSSession
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-08-06 15:39:32 +02:00
|
|
|
|
2021-06-28 18:09:13 +02:00
|
|
|
if (!qcrypto_tls_creds_check_endpoint(vd->tlscreds,
|
|
|
|
QCRYPTO_TLS_CREDS_ENDPOINT_SERVER,
|
|
|
|
errp)) {
|
ui: convert VNC server to use QCryptoTLSSession
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-08-06 15:39:32 +02:00
|
|
|
goto fail;
|
|
|
|
}
|
2014-09-16 12:33:03 +02:00
|
|
|
}
|
vnc: allow specifying a custom authorization object name
The VNC server has historically had support for ACLs to check both the
SASL username and the TLS x509 distinguished name. The VNC server was
responsible for creating the initial ACL, and the client app was then
responsible for populating it with rules using the HMP 'acl_add' command.
This is not satisfactory for a variety of reasons. There is no way to
populate the ACLs from the command line, users are forced to use the
HMP. With multiple network services all supporting TLS and ACLs now, it
is desirable to be able to define a single ACL that is referenced by all
services.
To address these limitations, two new options are added to the VNC
server CLI. The 'tls-authz' option takes the ID of a QAuthZ object to
use for checking TLS x509 distinguished names, and the 'sasl-authz'
option takes the ID of another object to use for checking SASL usernames.
In this example, we setup two authorization rules. The first allows any
client with a certificate issued by the 'RedHat' organization in the
'London' locality. The second ACL allows clients with either the
'joe@REDHAT.COM' or 'fred@REDHAT.COM' kerberos usernames. Both checks
must pass for the user to be allowed.
$QEMU -object tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\
endpoint=server,verify-peer=yes \
-object authz-simple,id=authz0,policy=deny,\
rules.0.match=O=RedHat,,L=London,rules.0.policy=allow \
-object authz-simple,id=authz1,policy=deny,\
rules.0.match=fred@REDHAT.COM,rules.0.policy=allow \
rules.0.match=joe@REDHAT.COM,rules.0.policy=allow \
-vnc 0.0.0.0:1,tls-creds=tls0,tls-authz=authz0,
sasl,sasl-authz=authz1 \
...other QEMU args...
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20190227145755.26556-2-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-02-27 15:57:54 +01:00
|
|
|
tlsauthz = qemu_opt_get(opts, "tls-authz");
|
|
|
|
if (tlsauthz && !vd->tlscreds) {
|
|
|
|
error_setg(errp, "'tls-authz' provided but TLS is not enabled");
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
saslauthz = qemu_opt_get(opts, "sasl-authz");
|
|
|
|
if (saslauthz && !sasl) {
|
|
|
|
error_setg(errp, "'sasl-authz' provided but SASL auth is not enabled");
|
|
|
|
goto fail;
|
|
|
|
}
|
2014-09-16 12:33:03 +02:00
|
|
|
|
|
|
|
share = qemu_opt_get(opts, "share");
|
|
|
|
if (share) {
|
|
|
|
if (strcmp(share, "ignore") == 0) {
|
2016-09-29 17:45:35 +02:00
|
|
|
vd->share_policy = VNC_SHARE_POLICY_IGNORE;
|
2014-09-16 12:33:03 +02:00
|
|
|
} else if (strcmp(share, "allow-exclusive") == 0) {
|
2016-09-29 17:45:35 +02:00
|
|
|
vd->share_policy = VNC_SHARE_POLICY_ALLOW_EXCLUSIVE;
|
2014-09-16 12:33:03 +02:00
|
|
|
} else if (strcmp(share, "force-shared") == 0) {
|
2016-09-29 17:45:35 +02:00
|
|
|
vd->share_policy = VNC_SHARE_POLICY_FORCE_SHARED;
|
2014-09-16 12:33:03 +02:00
|
|
|
} else {
|
|
|
|
error_setg(errp, "unknown vnc share= option");
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
} else {
|
2016-09-29 17:45:35 +02:00
|
|
|
vd->share_policy = VNC_SHARE_POLICY_ALLOW_EXCLUSIVE;
|
2014-09-16 12:33:03 +02:00
|
|
|
}
|
2016-09-29 17:45:35 +02:00
|
|
|
vd->connections_limit = qemu_opt_get_number(opts, "connections", 32);
|
2014-09-16 12:33:03 +02:00
|
|
|
|
|
|
|
#ifdef CONFIG_VNC_JPEG
|
2016-09-29 17:45:35 +02:00
|
|
|
vd->lossy = qemu_opt_get_bool(opts, "lossy", false);
|
2014-09-16 12:33:03 +02:00
|
|
|
#endif
|
2016-09-29 17:45:35 +02:00
|
|
|
vd->non_adaptive = qemu_opt_get_bool(opts, "non-adaptive", false);
|
2014-01-08 10:08:38 +01:00
|
|
|
/* adaptive updates are only used with tight encoding and
|
|
|
|
* if lossy updates are enabled so we can disable all the
|
|
|
|
* calculations otherwise */
|
2016-09-29 17:45:35 +02:00
|
|
|
if (!vd->lossy) {
|
|
|
|
vd->non_adaptive = true;
|
2014-01-08 10:08:38 +01:00
|
|
|
}
|
|
|
|
|
2020-12-11 17:08:25 +01:00
|
|
|
vd->power_control = qemu_opt_get_bool(opts, "power-control", false);
|
|
|
|
|
vnc: allow specifying a custom authorization object name
The VNC server has historically had support for ACLs to check both the
SASL username and the TLS x509 distinguished name. The VNC server was
responsible for creating the initial ACL, and the client app was then
responsible for populating it with rules using the HMP 'acl_add' command.
This is not satisfactory for a variety of reasons. There is no way to
populate the ACLs from the command line, users are forced to use the
HMP. With multiple network services all supporting TLS and ACLs now, it
is desirable to be able to define a single ACL that is referenced by all
services.
To address these limitations, two new options are added to the VNC
server CLI. The 'tls-authz' option takes the ID of a QAuthZ object to
use for checking TLS x509 distinguished names, and the 'sasl-authz'
option takes the ID of another object to use for checking SASL usernames.
In this example, we setup two authorization rules. The first allows any
client with a certificate issued by the 'RedHat' organization in the
'London' locality. The second ACL allows clients with either the
'joe@REDHAT.COM' or 'fred@REDHAT.COM' kerberos usernames. Both checks
must pass for the user to be allowed.
$QEMU -object tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\
endpoint=server,verify-peer=yes \
-object authz-simple,id=authz0,policy=deny,\
rules.0.match=O=RedHat,,L=London,rules.0.policy=allow \
-object authz-simple,id=authz1,policy=deny,\
rules.0.match=fred@REDHAT.COM,rules.0.policy=allow \
rules.0.match=joe@REDHAT.COM,rules.0.policy=allow \
-vnc 0.0.0.0:1,tls-creds=tls0,tls-authz=authz0,
sasl,sasl-authz=authz1 \
...other QEMU args...
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20190227145755.26556-2-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-02-27 15:57:54 +01:00
|
|
|
if (tlsauthz) {
|
|
|
|
vd->tlsauthzid = g_strdup(tlsauthz);
|
2015-03-02 20:01:05 +01:00
|
|
|
}
|
Support ACLs for controlling VNC access ("Daniel P. Berrange")
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-06 21:27:37 +01:00
|
|
|
#ifdef CONFIG_VNC_SASL
|
vnc: allow specifying a custom authorization object name
The VNC server has historically had support for ACLs to check both the
SASL username and the TLS x509 distinguished name. The VNC server was
responsible for creating the initial ACL, and the client app was then
responsible for populating it with rules using the HMP 'acl_add' command.
This is not satisfactory for a variety of reasons. There is no way to
populate the ACLs from the command line, users are forced to use the
HMP. With multiple network services all supporting TLS and ACLs now, it
is desirable to be able to define a single ACL that is referenced by all
services.
To address these limitations, two new options are added to the VNC
server CLI. The 'tls-authz' option takes the ID of a QAuthZ object to
use for checking TLS x509 distinguished names, and the 'sasl-authz'
option takes the ID of another object to use for checking SASL usernames.
In this example, we setup two authorization rules. The first allows any
client with a certificate issued by the 'RedHat' organization in the
'London' locality. The second ACL allows clients with either the
'joe@REDHAT.COM' or 'fred@REDHAT.COM' kerberos usernames. Both checks
must pass for the user to be allowed.
$QEMU -object tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\
endpoint=server,verify-peer=yes \
-object authz-simple,id=authz0,policy=deny,\
rules.0.match=O=RedHat,,L=London,rules.0.policy=allow \
-object authz-simple,id=authz1,policy=deny,\
rules.0.match=fred@REDHAT.COM,rules.0.policy=allow \
rules.0.match=joe@REDHAT.COM,rules.0.policy=allow \
-vnc 0.0.0.0:1,tls-creds=tls0,tls-authz=authz0,
sasl,sasl-authz=authz1 \
...other QEMU args...
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 20190227145755.26556-2-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-02-27 15:57:54 +01:00
|
|
|
if (sasl) {
|
|
|
|
if (saslauthz) {
|
|
|
|
vd->sasl.authzid = g_strdup(saslauthz);
|
2014-10-21 14:50:42 +02:00
|
|
|
}
|
Support ACLs for controlling VNC access ("Daniel P. Berrange")
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-06 21:27:37 +01:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2016-09-29 17:45:36 +02:00
|
|
|
if (vnc_display_setup_auth(&vd->auth, &vd->subauth,
|
|
|
|
vd->tlscreds, password,
|
|
|
|
sasl, false, errp) < 0) {
|
|
|
|
goto fail;
|
|
|
|
}
|
2017-09-21 14:15:28 +02:00
|
|
|
trace_vnc_auth_init(vd, 0, vd->auth, vd->subauth);
|
2016-09-29 17:45:36 +02:00
|
|
|
|
|
|
|
if (vnc_display_setup_auth(&vd->ws_auth, &vd->ws_subauth,
|
|
|
|
vd->tlscreds, password,
|
|
|
|
sasl, true, errp) < 0) {
|
ui: convert VNC server to use QCryptoTLSSession
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-08-06 15:39:32 +02:00
|
|
|
goto fail;
|
|
|
|
}
|
2017-09-21 14:15:28 +02:00
|
|
|
trace_vnc_auth_init(vd, 1, vd->ws_auth, vd->ws_subauth);
|
2006-04-30 23:28:36 +02:00
|
|
|
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
#ifdef CONFIG_VNC_SASL
|
2021-06-04 14:09:15 +02:00
|
|
|
if (sasl && !vnc_sasl_server_init(errp)) {
|
|
|
|
goto fail;
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
}
|
|
|
|
#endif
|
2016-09-29 17:45:35 +02:00
|
|
|
vd->lock_key_sync = lock_key_sync;
|
2017-01-09 17:14:02 +01:00
|
|
|
if (lock_key_sync) {
|
|
|
|
vd->led = qemu_add_led_event_handler(kbd_leds, vd);
|
|
|
|
}
|
|
|
|
vd->ledstate = 0;
|
Add SASL authentication support ("Daniel P. Berrange")
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-06 21:27:28 +01:00
|
|
|
|
2019-08-19 01:06:48 +02:00
|
|
|
audiodev = qemu_opt_get(opts, "audiodev");
|
|
|
|
if (audiodev) {
|
2023-09-22 17:29:19 +02:00
|
|
|
vd->audio_state = audio_state_by_name(audiodev, errp);
|
2019-08-19 01:06:48 +02:00
|
|
|
if (!vd->audio_state) {
|
|
|
|
goto fail;
|
|
|
|
}
|
2023-10-05 18:42:54 +02:00
|
|
|
} else {
|
|
|
|
vd->audio_state = audio_get_default_audio_state(NULL);
|
2019-08-19 01:06:48 +02:00
|
|
|
}
|
|
|
|
|
2014-09-18 12:54:49 +02:00
|
|
|
device_id = qemu_opt_get(opts, "display");
|
|
|
|
if (device_id) {
|
|
|
|
int head = qemu_opt_get_number(opts, "head", 0);
|
2016-01-12 11:45:43 +01:00
|
|
|
Error *err = NULL;
|
2014-09-18 12:54:49 +02:00
|
|
|
|
2016-01-12 11:45:43 +01:00
|
|
|
con = qemu_console_lookup_by_device_name(device_id, head, &err);
|
|
|
|
if (err) {
|
|
|
|
error_propagate(errp, err);
|
2014-09-18 12:54:49 +02:00
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
con = NULL;
|
|
|
|
}
|
|
|
|
|
2016-09-29 17:45:35 +02:00
|
|
|
if (con != vd->dcl.con) {
|
2019-01-22 10:28:12 +01:00
|
|
|
qkbd_state_free(vd->kbd);
|
2016-09-29 17:45:35 +02:00
|
|
|
unregister_displaychangelistener(&vd->dcl);
|
|
|
|
vd->dcl.con = con;
|
|
|
|
register_displaychangelistener(&vd->dcl);
|
2019-01-22 10:28:12 +01:00
|
|
|
vd->kbd = qkbd_state_init(vd->dcl.con);
|
2014-09-18 12:54:49 +02:00
|
|
|
}
|
2019-01-22 10:28:12 +01:00
|
|
|
qkbd_state_set_delay(vd->kbd, key_delay_ms);
|
2014-09-18 12:54:49 +02:00
|
|
|
|
2022-04-01 16:39:34 +02:00
|
|
|
if (saddr_list == NULL) {
|
|
|
|
return;
|
2017-03-28 18:06:46 +02:00
|
|
|
}
|
|
|
|
|
2008-02-03 03:54:04 +01:00
|
|
|
if (reverse) {
|
2022-04-01 16:39:34 +02:00
|
|
|
if (vnc_display_connect(vd, saddr_list, wsaddr_list, errp) < 0) {
|
2012-10-18 09:01:01 +02:00
|
|
|
goto fail;
|
|
|
|
}
|
2008-11-11 21:51:59 +01:00
|
|
|
} else {
|
2022-04-01 16:39:34 +02:00
|
|
|
if (vnc_display_listen(vd, saddr_list, wsaddr_list, errp) < 0) {
|
2015-08-14 19:56:44 +02:00
|
|
|
goto fail;
|
|
|
|
}
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
2015-08-14 19:56:44 +02:00
|
|
|
|
2017-02-03 13:06:45 +01:00
|
|
|
if (qemu_opt_get(opts, "to")) {
|
2016-09-29 17:45:35 +02:00
|
|
|
vnc_display_print_local_addr(vd);
|
2016-05-31 14:59:08 +02:00
|
|
|
}
|
|
|
|
|
2022-04-01 16:39:34 +02:00
|
|
|
/* Success */
|
2012-10-02 10:17:21 +02:00
|
|
|
return;
|
2012-10-18 09:07:05 +02:00
|
|
|
|
|
|
|
fail:
|
2017-02-03 13:06:44 +01:00
|
|
|
vnc_display_close(vd);
|
2006-04-30 23:28:36 +02:00
|
|
|
}
|
Introduce a 'client_add' monitor command accepting an open FD
Allow client connections for VNC and socket based character
devices to be passed in over the monitor using SCM_RIGHTS.
One intended usage scenario is to start QEMU with VNC on a
UNIX domain socket. An unprivileged user which cannot access
the UNIX domain socket, can then connect to QEMU's VNC server
by passing an open FD to libvirt, which passes it onto QEMU.
{ "execute": "get_fd", "arguments": { "fdname": "myclient" } }
{ "return": {} }
{ "execute": "add_client", "arguments": { "protocol": "vnc",
"fdname": "myclient",
"skipauth": true } }
{ "return": {} }
In this case 'protocol' can be 'vnc' or 'spice', or the name
of a character device (eg from -chardev id=XXXX)
The 'skipauth' parameter can be used to skip any configured
VNC authentication scheme, which is useful if the mgmt layer
talking to the monitor has already authenticated the client
in another way.
* console.h: Define 'vnc_display_add_client' method
* monitor.c: Implement 'client_add' command
* qemu-char.c, qemu-char.h: Add 'qemu_char_add_client' method
* qerror.c, qerror.h: Add QERR_ADD_CLIENT_FAILED
* qmp-commands.hx: Declare 'client_add' command
* ui/vnc.c: Implement 'vnc_display_add_client' method
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-06-23 14:31:42 +02:00
|
|
|
|
2014-07-29 12:24:55 +02:00
|
|
|
void vnc_display_add_client(const char *id, int csock, bool skipauth)
|
Introduce a 'client_add' monitor command accepting an open FD
Allow client connections for VNC and socket based character
devices to be passed in over the monitor using SCM_RIGHTS.
One intended usage scenario is to start QEMU with VNC on a
UNIX domain socket. An unprivileged user which cannot access
the UNIX domain socket, can then connect to QEMU's VNC server
by passing an open FD to libvirt, which passes it onto QEMU.
{ "execute": "get_fd", "arguments": { "fdname": "myclient" } }
{ "return": {} }
{ "execute": "add_client", "arguments": { "protocol": "vnc",
"fdname": "myclient",
"skipauth": true } }
{ "return": {} }
In this case 'protocol' can be 'vnc' or 'spice', or the name
of a character device (eg from -chardev id=XXXX)
The 'skipauth' parameter can be used to skip any configured
VNC authentication scheme, which is useful if the mgmt layer
talking to the monitor has already authenticated the client
in another way.
* console.h: Define 'vnc_display_add_client' method
* monitor.c: Implement 'client_add' command
* qemu-char.c, qemu-char.h: Add 'qemu_char_add_client' method
* qerror.c, qerror.h: Add QERR_ADD_CLIENT_FAILED
* qmp-commands.hx: Declare 'client_add' command
* ui/vnc.c: Implement 'vnc_display_add_client' method
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-06-23 14:31:42 +02:00
|
|
|
{
|
2016-09-29 17:45:35 +02:00
|
|
|
VncDisplay *vd = vnc_display_find(id);
|
2015-02-27 17:20:57 +01:00
|
|
|
QIOChannelSocket *sioc;
|
Introduce a 'client_add' monitor command accepting an open FD
Allow client connections for VNC and socket based character
devices to be passed in over the monitor using SCM_RIGHTS.
One intended usage scenario is to start QEMU with VNC on a
UNIX domain socket. An unprivileged user which cannot access
the UNIX domain socket, can then connect to QEMU's VNC server
by passing an open FD to libvirt, which passes it onto QEMU.
{ "execute": "get_fd", "arguments": { "fdname": "myclient" } }
{ "return": {} }
{ "execute": "add_client", "arguments": { "protocol": "vnc",
"fdname": "myclient",
"skipauth": true } }
{ "return": {} }
In this case 'protocol' can be 'vnc' or 'spice', or the name
of a character device (eg from -chardev id=XXXX)
The 'skipauth' parameter can be used to skip any configured
VNC authentication scheme, which is useful if the mgmt layer
talking to the monitor has already authenticated the client
in another way.
* console.h: Define 'vnc_display_add_client' method
* monitor.c: Implement 'client_add' command
* qemu-char.c, qemu-char.h: Add 'qemu_char_add_client' method
* qerror.c, qerror.h: Add QERR_ADD_CLIENT_FAILED
* qmp-commands.hx: Declare 'client_add' command
* ui/vnc.c: Implement 'vnc_display_add_client' method
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-06-23 14:31:42 +02:00
|
|
|
|
2016-09-29 17:45:35 +02:00
|
|
|
if (!vd) {
|
2014-07-29 12:14:08 +02:00
|
|
|
return;
|
|
|
|
}
|
2015-02-27 17:20:57 +01:00
|
|
|
|
|
|
|
sioc = qio_channel_socket_new_fd(csock, NULL);
|
|
|
|
if (sioc) {
|
2016-09-30 12:57:14 +02:00
|
|
|
qio_channel_set_name(QIO_CHANNEL(sioc), "vnc-server");
|
2016-09-29 17:45:35 +02:00
|
|
|
vnc_connect(vd, sioc, skipauth, false);
|
2015-02-27 17:20:57 +01:00
|
|
|
object_unref(OBJECT(sioc));
|
|
|
|
}
|
Introduce a 'client_add' monitor command accepting an open FD
Allow client connections for VNC and socket based character
devices to be passed in over the monitor using SCM_RIGHTS.
One intended usage scenario is to start QEMU with VNC on a
UNIX domain socket. An unprivileged user which cannot access
the UNIX domain socket, can then connect to QEMU's VNC server
by passing an open FD to libvirt, which passes it onto QEMU.
{ "execute": "get_fd", "arguments": { "fdname": "myclient" } }
{ "return": {} }
{ "execute": "add_client", "arguments": { "protocol": "vnc",
"fdname": "myclient",
"skipauth": true } }
{ "return": {} }
In this case 'protocol' can be 'vnc' or 'spice', or the name
of a character device (eg from -chardev id=XXXX)
The 'skipauth' parameter can be used to skip any configured
VNC authentication scheme, which is useful if the mgmt layer
talking to the monitor has already authenticated the client
in another way.
* console.h: Define 'vnc_display_add_client' method
* monitor.c: Implement 'client_add' command
* qemu-char.c, qemu-char.h: Add 'qemu_char_add_client' method
* qerror.c, qerror.h: Add QERR_ADD_CLIENT_FAILED
* qmp-commands.hx: Declare 'client_add' command
* ui/vnc.c: Implement 'vnc_display_add_client' method
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-06-23 14:31:42 +02:00
|
|
|
}
|
2014-09-16 12:33:03 +02:00
|
|
|
|
2015-02-17 09:28:17 +01:00
|
|
|
static void vnc_auto_assign_id(QemuOptsList *olist, QemuOpts *opts)
|
2015-02-05 10:43:34 +01:00
|
|
|
{
|
|
|
|
int i = 2;
|
|
|
|
char *id;
|
|
|
|
|
|
|
|
id = g_strdup("default");
|
|
|
|
while (qemu_opts_find(olist, id)) {
|
|
|
|
g_free(id);
|
|
|
|
id = g_strdup_printf("vnc%d", i++);
|
|
|
|
}
|
|
|
|
qemu_opts_set_id(opts, id);
|
|
|
|
}
|
|
|
|
|
2021-01-20 15:42:35 +01:00
|
|
|
void vnc_parse(const char *str)
|
2014-09-16 12:33:03 +02:00
|
|
|
{
|
|
|
|
QemuOptsList *olist = qemu_find_opts("vnc");
|
2021-01-20 15:42:35 +01:00
|
|
|
QemuOpts *opts = qemu_opts_parse_noisily(olist, str, !is_help_option(str));
|
2015-03-12 08:33:45 +01:00
|
|
|
const char *id;
|
2014-09-16 12:33:03 +02:00
|
|
|
|
2015-03-12 08:33:45 +01:00
|
|
|
if (!opts) {
|
2021-01-20 15:42:35 +01:00
|
|
|
exit(1);
|
2015-03-12 08:33:45 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
id = qemu_opts_id(opts);
|
2014-09-16 12:33:03 +02:00
|
|
|
if (!id) {
|
|
|
|
/* auto-assign id if not present */
|
2015-02-05 10:43:34 +01:00
|
|
|
vnc_auto_assign_id(olist, opts);
|
2014-09-16 12:33:03 +02:00
|
|
|
}
|
2015-02-17 09:28:17 +01:00
|
|
|
}
|
|
|
|
|
2015-03-13 13:35:14 +01:00
|
|
|
int vnc_init_func(void *opaque, QemuOpts *opts, Error **errp)
|
2015-02-17 09:28:17 +01:00
|
|
|
{
|
|
|
|
Error *local_err = NULL;
|
|
|
|
char *id = (char *)qemu_opts_id(opts);
|
2014-09-16 12:33:03 +02:00
|
|
|
|
2015-02-17 09:28:17 +01:00
|
|
|
assert(id);
|
2018-10-17 10:26:50 +02:00
|
|
|
vnc_display_init(id, &local_err);
|
|
|
|
if (local_err) {
|
2018-10-17 10:26:51 +02:00
|
|
|
error_propagate(errp, local_err);
|
|
|
|
return -1;
|
2018-10-17 10:26:50 +02:00
|
|
|
}
|
2014-09-16 12:33:03 +02:00
|
|
|
vnc_display_open(id, &local_err);
|
|
|
|
if (local_err != NULL) {
|
2018-10-17 10:26:51 +02:00
|
|
|
error_propagate(errp, local_err);
|
|
|
|
return -1;
|
2014-09-16 12:33:03 +02:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void vnc_register_config(void)
|
|
|
|
{
|
|
|
|
qemu_add_opts(&qemu_vnc_opts);
|
|
|
|
}
|
2016-02-16 21:59:07 +01:00
|
|
|
opts_init(vnc_register_config);
|