This lets me adjust the clients to do proper error propagation first,
thus avoiding temporary regressions in the quality of the error messages.
Reviewed-by: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
If TIGHT_PNG is not enabled by the --enable-vnc-png configure flag
then do not report to the client that it is supported.
Also, since TIGHT_PNG is the same as the TIGHT encoding but with the
filter/copy replaced with PNG data, adding it to the supported
encodings list when it is disabled will cause the TIGHT encoding to be
used even though the client requested TIGHT_PNG.
Signed-off-by: Joel Martin <github@martintribe.org>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
When reverse connection is in use, there is no active VNC server
socket. Because of this, getsockopt(-1, ...) is attempted and
the following error is emitted:
$ socat TCP-LISTEN:5900,reuseaddr TCP-LISTEN:5901,reuseaddr &
$ x86_64-softmmu/qemu-system-x86_64 -vnc localhost:5900,reverse -monitor stdio
QEMU 1.2.50 monitor - type 'help' for more information
(qemu) info vnc
An undefined error has occurred
Because however the host, family, service and auth fields are
optional, we can just exit if there is no active server socket.
$ x86_64-softmmu/qemu-system-x86_64 -vnc localhost:5900,reverse -monitor stdio
QEMU 1.2.50 monitor - type 'help' for more information
(qemu) info vnc
Server:
Client:
address: 127.0.0.1:5900
x509_dname: none
username: none
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
No need to add non blocking parameters to the blocking inet_connect
add block parameter for inet_connect_opts instead of using QemuOpt "block".
Signed-off-by: Orit Wasserman <owasserm@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
It's used to indicate the special case where a valid file-descriptor
is returned (ie. success) but the connection can't be completed
w/o blocking.
This is needed because QERR_SOCKET_CONNECT_IN_PROGRESS is not
treated like an error and a future commit will drop it.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
FIPS 140-2 requires disabling certain ciphers, including DES, which is used
by VNC to obscure passwords when they are sent over the network. The
solution for FIPS users is to disable the use of VNC password auth when the
host system is operating in FIPS compliance mode and the user has specified
'-enable-fips' on the QEMU command line.
This patch causes QEMU to emit a message to stderr when the host system is
running in FIPS mode and a VNC password was specified on the commend line.
If the system is not running in FIPS mode, or is running in FIPS mode but
VNC password authentication was not requested, QEMU operates normally.
Signed-off-by: Paul Moore <pmoore@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
QEMU now has a fundamental requirement for pthreads, so there
is no compelling reason to retain support for the non-threaded
VNC server. Remove the --{enable,disable}-vnc-thread configure
arguments, and all CONFIG_VNC_THREAD conditionals
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
NULL pointer dereference in case no vnc server is configured.
Catch this and return -EINVAL like vnc_display_password() does.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Add a new argument in inet_listen()/inet_listen_opts()
to pass back listen error.
Change nbd, qemu-char, vnc to use new interface.
Signed-off-by: Amos Kong <akong@redhat.com>
Reviewed-by: Orit Wasserman <owasserm@redhat.com>
Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Add a bool argument to inet_connect() to assign if set socket
to block/nonblock, and delete original argument 'socktype'
that is unused.
Add a new argument to inet_connect()/inet_connect_opts(),
to pass back connect error by error class.
Retry to connect when -EINTR is got. Connect's successful
for nonblock socket when following errors are got, user
should wait for connecting by select():
-EINPROGRESS
-EWOULDBLOCK (win32)
-WSAEALREADY (win32)
Change nbd, vnc to use new interface.
Signed-off-by: Amos Kong <akong@redhat.com>
Reviewed-by: Orit Wasserman <owasserm@redhat.com>
Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This fixes memory reads and writes which exceeded the upper limit
of allocated memory vd->guest.ds->data and vd->server->data.
Cc: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The threaded VNC servers messed up with QEMU fd handlers without
any kind of locking, and that can cause some nasty race conditions.
Using qemu_mutex_lock_iothread() won't work because vnc_dpy_cpy(),
which will wait for the current job queue to finish, can be called with
the iothread lock held.
Instead, we now store the data in a temporary buffer, and use a bottom
half to notify the main thread that new data is available.
vnc_[un]lock_ouput() is still needed to access VncState members like
abort, csock or jobs_buffer.
Signed-off-by: Corentin Chary <corentin.chary@gmail.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The comment is wrong, we have to do something in the setdata callback.
Changing the framebuffer backing storage (happens when the guest pans
the display) renders the whole screen content invalid.
Trigger #1: cirrus vga + 32bit linux guest + vesafb with ypan enabled.
Trigger #2: std vga + http://patchwork.ozlabs.org/patch/145479/
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Currently when disabling login in VNC, the password is cleared out and the
authentication protocol is forced to AUTH_VNC. If you're using a stronger
authentication protocol, this has the effect of downgrading your security
protocol.
Fix this by only changing the authentication protocol if the current
authentication protocol is AUTH_NONE. That ensures we're never downgrading.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
--
NB. This patch is derived from one posted by Anthony last year, which got
accidentally lost after Luiz took over the QMP series work
https://lists.gnu.org/archive/html/qemu-devel/2011-09/msg00392.html
v1 -> v2
- Make sure to not demote when changing password (Daniel)
v2 -> v3
- Rebase to latest GIT master wrt QMP changes
For any modifier key (shift, ctrl, alt) still pressed on disconnect
inject a key-up event into the guest. The vnc client is gone, it will
not do that, so qemu has to do it instead.
Without this keys will get stuck, making the guest act in weird ways
after reconnecting. Reproducer: exit vnc client via Alt-F4, guest
continues to see the pressed alt key and will not react to key events
in any useful way until you tap the alt key once to unstuck it.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
VNC clients send a shared flag in the client init message. Up to now
qemu completely ignores this. This patch implements shared flag
handling. It comes with three policies: By default qemu behaves as one
would expect: Asking for a exclusive access grants exclusive access to
the client connecting. There is also a desktop sharing mode which
disallows exclusive connects (so one forgetting -shared wouldn't drop
everybody else) and a compatibility mode which mimics the traditional
(but non-conforming) qemu behavior.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Make the control keys for terminals on the vnc display
(i.e. qemu -vnc :0 -serial vc) work. Makes the terminals
alot more usable as typing Ctrl-C in your serial console
actually has the desired effect ;)
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
vnc assumes that the screen width is a multiple of 16 in several places.
If this is not the case vnc will overrun buffers, corrupt memory, make
qemu crash.
This is the minimum fix for this bug. It makes sure we don't overrun the
scanline, thereby fixing the segfault. The rendering is *not* correct
though, there is a black border at the right side of the screen, 8
pixels wide because 1400 % 16 == 8.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Drop the qerror_report() call from it and let its callers set the error
themselves. This also allows for dropping the 'ret' variable.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
The no-lock-key-sync option is being parsed incorrectly because of an
outdated strcmp() length value. Use the correct length so that invalid
option names do not match.
Reported-by: Dr David Alan Gilbert <davidagilbert@uk.ibm.com>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Double semicolons should be single.
Signed-off-by: Dong Xu Wang <wdongxu@linux.vnet.ibm.com>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Dong Xu Wang <wdongxu@linux.vnet.ibm.com>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Please note that mechlist still uses malloc / strdup / free.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
There are three important remarks in relation to the non-qapi command:
1. This commit also fixes the behavior of the 'query-vnc' and 'info vnc'
commands to return an error when qemu is built without VNC support
(ie. --disable-vnc). The non-qapi command would return the OK
response in QMP and no response in HMP
2. The qapi version explicitly marks the fields 'host', 'family',
'service' and 'auth' as optional. Their are not documented as optional
in the non-qapi command doc, but they would not be returned if
vnc support is disabled. The qapi version maintains the same
semantics, but documents those fields correctly
3. The 'clients' field, which is a list, is marked as optional but is
always returned. If there are no clients connected an empty list
is returned. This is not the Right Way to this in the qapi but it's
how the non-qapi command used to work
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Avoid warnings like these by wrapping recv():
CC slirp/ip_icmp.o
/src/qemu/slirp/ip_icmp.c: In function 'icmp_receive':
/src/qemu/slirp/ip_icmp.c:418:5: error: passing argument 2 of 'recv' from incompatible pointer type [-Werror]
/usr/local/lib/gcc/i686-mingw32msvc/4.6.0/../../../../i686-mingw32msvc/include/winsock2.h:547:32: note: expected 'char *' but argument is of type 'struct icmp *'
Remove also casts used to avoid warnings.
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
This allows to pass additional information to the notifier callback
which is useful if sender and receiver do not share any other distinct
data structure.
Will be used first for the clock reset notifier.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
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>
A future patch will introduce a situation where different
clients may have different authentication schemes set.
When a new client arrives, copy the 'auth' and 'subauth'
fields from VncDisplay into the client's VncState, and
use the latter in all authentication functions.
* ui/vnc.h: Add 'auth' and 'subauth' to VncState
* ui/vnc-auth-sasl.c, ui/vnc-auth-vencrypt.c,
ui/vnc.c: Make auth functions pull auth scheme
from VncState instead of VncDisplay
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This patch fix the following regression:
1. we should use bitmap_set() and bitmap_clear() to replace vnc_set_bits().
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This was done with:
sed -i '/get_clock\>.*rt_clock/s/get_clock\>/get_clock_ms/' \
$(git grep -l 'get_clock\>.*rt_clock' )
sed -i '/new_timer\>.*rt_clock/s/new_timer\>/new_timer_ms/' \
$(git grep -l 'new_timer\>.*rt_clock' )
after checking that get_clock and new_timer never occur twice
on the same line. There were no missed occurrences; however, even
if there had been, they would have been caught by the compiler.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Commit bc2429b917 introduced
a severe bug (stack corruption).
bitmap_clear was called with a wrong argument
which caused out-of-bound writes to the local variable width_mask.
This bug was detected with QEMU running on windows.
It also occurs with wine:
*** stack smashing detected ***: terminated
wine: Unhandled illegal instruction at address 0x6115c7 (thread 0009), starting debugger...
The bug is not windows specific!
Instead of fixing the wrong parameter value, bitmap_clear(), bitmap_set
and width_mask were removed, and bitmap_intersect() was replaced by
!bitmap_empty(). The new operation is much shorter and equivalent to
the old operations.
The declarations of the dirty bitmaps in vnc.h were also wrong for 64 bit
hosts because of a rounding effect: for these hosts, VNC_MAX_WIDTH is no
longer a multiple of (16 * BITS_PER_LONG), so the rounded value of
VNC_DIRTY_WORDS was too small.
Fix both declarations by using the macro which is designed for this
purpose.
Cc: Corentin Chary <corentincj@iksaif.net>
Cc: Wen Congyang <wency@cn.fujitsu.com>
Cc: Gerhard Wiesinger <lists@wiesinger.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Reverse mode is unusable:
qemu -vnc localhost:5500,reverse
crashes in vnc_refresh_server_surface because some pointers are NULL.
Fix this by calling vnc_dpy_resize (which initializes these pointers)
before calling vnc_refresh.
Cc: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This option allow to disable adaptive behaviors in some encodings.
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Respect client size if it doesn't not support desktop resizing.
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Switch to bitmap.h and bitops.h instead of redefining our own bitmap
helpers.
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The for loop in send_lossy_rect was totally wrong, and we can't
call vnc_set_bits() because it does not really do what it should.
Use vnc_set_bit() directly instead.
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
If an adaptive encoding has choosen to send a lossy update
based on the result of vnc_update_freq(), then it should advertise
it with vnc_sent_lossy_rect(). This will allow to automatically refresh
this rect once it's static again.
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This patch compute the update frequency (in Hz) for each 64x64 rects.
Any adaptive encoding can get this value using vnc_update_freq(), and
switch to a lossy encoding if the value is too high.
The frequency is pre-calculated every 500ms, based on the last 10
updates per 64x64 rect.
If a 64x64 rect was not updated in the last 2 second, then the frequency
became 0, and all the stored timestamp are reseted.
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This should not change the current behavior, but if any new
encoding try to use the tight quality, it will always be set
to -1 when lossy encodings are disabled.
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
commit 52c18be9e9 introduced a regression in the
change vnc password command that changed the behavior of setting the VNC
password to an empty string from disabling login to disabling authentication.
This commit refactors the code to eliminate this overloaded semantics in
vnc_display_password and instead introduces the vnc_display_disable_login. The
monitor implementation then determines the behavior of an empty or missing
string.
Recently, a set_password command was added that allows both the Spice and VNC
password to be set. This command has not shown up in a release yet so the
behavior is not yet defined.
This patch proposes that an empty password be treated as an empty password with
no special handling. For specifically disabling login, I believe a new command
should be introduced instead of overloading semantics.
I'm not sure how Spice handles this but I would recommend that we have Spice
and VNC have consistent semantics here for the 0.14.0 release.
Reported-by: Neil Wilson <neil@aldur.co.uk>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
---
v1 -> v2
- Add a proper return to make sure that login is really disabled instead of
relying on the VNC server to treat empty passwords specially
This patch makes the numlock+capslock tracking logic only look at
keydown events. Without this patch the vnc server will insert
bogous capslock keypress in case it sees the following key sequence:
shift down --- 'A' down --- shift up --- 'A' up
^ here
It doesn't hurt with a PS/2 keyboard, but it disturbs the USB Keyboard.
And with the key event queue just added to the usb keyboard the guest
will actually notice.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
