reds.c is using strncpy with a length one byte less than the
destination buffer size, and is relying on the fact that the
destination buffers are static global variables.
Now that we depend on glib, we can use g_strlcpy instead, which
avoids relying on such a subtle trick to get a nul-terminated
string.
We currently output a warning when getaddrinfo fails, but then
we go on trying to use the information it couldn't read. Make
sure we bail out of reds_init_socket if getaddrinfo fails.
spice_server_set_ticket and spice_server_set_addr get (library)
user-provided strings as arguments, and copy them to fixed-size
buffers using strncpy. However, if these strings are too long,
the copied string will not be 0-terminated, which will cause issues
later. This commit copies one byte less than the size of the
destination buffer. In both cases, this buffer is a static global
variable, so its memory will be set to 0.
A Spice port channel carry arbitrary data between the Spice client and
the Spice server. It may be used to provide additional services on top
of a Spice connection. For example, a channel can be associated with
the qemu monitor for the client to interact with it, just like any
qemu chardev. Or it may be used with various protocols, such as the
Spice Controller.
A port kind is identified simply by its fqdn, such as org.qemu.monitor,
org.spice.spicy.test or org.ovirt.controller...
The channel is based on Spicevmc which simply tunnels data between
client and server, with a few additional messages.
See the description of the channel protocol in spice-common history.
The server can receive from the client agent data even when the agent
is disconnected. This can happen if the client sends the agent data
before it receives the AGENT_DISCONNECTED msg. We should receive and handle such msgs, instead
of disconnecting the client.
This bug can also lead to a server crash if the agent gets reconnected
fast enough, and it receives an agent data msg from the client before MSGC_AGENT_START.
upstream bz#55726
rhbz#881980
New API: spice_server_set_ws_ports
This adds an optional dependency on libwebsockets. You need to get my
patched 0.0.3 version here:
git://people.freedesktop.org/~alon/libwebsockets
There is no qemu patches yet, to test change in reds.c the default value
of spice_ws_port to 5959 (for the default of spice-html5).
For testing there is an online client at
http://spice-space.org/spice-html5/spice.html
Known issues:
1. The tester (server/tests/test_display_no_ssl) gets into dropping all
data after a few seconds, I think it's an issue with the implemented
watches, but haven't figured it out.
2. libwebsocket's read interface is inverted to what our code expects,
i.e. there is no libwebsocket_read, so there is an additional copy
involved (see RedsWebSocket). This can be fixed.
3. Listening on a separate port. Since the headers are different, we
could listen on the same port (first three bytes RED/GET). I don't know
if we want to?
Todos:
1. SSL not implemented yet. Needs some thought as to how.
2. Serve spice-html5 when accessed as a http server. Nice to have.
This used to abort with spice_error. The caller currently does
not check spice_server_char_device_add_interface return value, but
it's still cleaner to report an error in this case.
Errors occurring in reds_init_ssl used to be fatal through the use
of spice_error, but this was downgraded to non-fatal spice_warning
calls recently. This means we no longer error out when invalid SSL
(certificates, ...) parameters are passed by the user.
This commit changes reds_init_ssl return value from void to int so
that errors can be reported to the caller.
We used to be aborting in such situations, but this was changed
during the big spice_error/printerr cleanup. We are currently
outputting a warning but not reporting the error with the caller
when reds_init_net fails to register listening watches with the
mainloop. As it's unlikely that things will work as expected in
such cases, better to error out of the function instead of pretending
everything is all right.
BN_new returns NULL on allocation failures. Given that we abort
on malloc allocation failures, we should also abort here. The
current code will segfault when BN_new fails as it immediatly tries
to use the NULL pointer.
If the guest supports client monitors config we pass it the
VDAgentMonitorsConfig message via the
QXLInterface::client_monitors_config api instead of via the vdagent.
If reading/writing from the device have occured before migration data
has arrived, the migration data might no longer be relvant, and we
disconnect the client.
Before sending the above msg, if there is a pending partial msg that
has been read from the agent, we send it to the client. The alternative
was to keep the msg as part of the migration data, and then
to send it to the destination server via the client and to wait there
for the msg chunk completion, before sending it to the client. Of
course, the latter is less efficient.
Tracking the channels that wait for migration data. If there
is a new migration process pending, when all the channels have
restored their state, we begin the new migration.
In semi-seamless, SPICE_MSG_MAIN_MIGRATE_END is sent.
In seamless, each channel migrates separately.
The src waits till all the clients are disconnected (or a timeout), and
then it notifies qemu that spice migration has completed.
The patch doesn't include the per-channel logic for seamless migration
(sending MSG_MIGRATE, MIGRATE_DATA, etc.).
- handle SPICE_MSGC_MAIN_MIGRATE_DST_DO_SEAMLESS
- reply with SPICE_MSG_MAIN_MIGRATE_DST_SEAMLESS_ACK/NACK
- prepare the channels for migration according to the migration
type (semi/seamless)
see spice-protocol for more details:
commit 3838ad140a046c4ddf42fef58c9727ecfdc09f9f
sending SPICE_MSG_MAIN_MIGRATE_BEGIN_SEAMLESS and handling
SPICE_MSGC_MAIN_MIGRATE_CONNECTED_SEAMLESS
The src side signals the client to establish a connection
to the destination.
In seamless migration, the client is also used to perform
a sort of handshake with the destination, for verifying
if seamless migration can be supported.
see spice-protocol for more details:
commit 3838ad140a046c4ddf42fef58c9727ecfdc09f9f
This new call is used in order to identify whether qemu, or
the management (e.g. libvirt), support seamless migration.
If it is supported, qemu spice cmd-line configuration should have
seamless-migration=on.
In addition, we disable seamless migration support if multiple clients
are allowed. Currently, only one client is supported.
Till now, red_worker was notfied about vm status changes via QXLWorker->start/stop
(or spice_qxl_start/stop).
Newer qemu, that supports calling spice_server_vm_start/stop, will call only
these routines, and won't call QXLWorker->start/stop.
When vm state changes (started/stopped), we notify all the
attached SpiceCharDeviceStates about the change. This is mainly required
for avoiding writing/reading to/from the device during the non-live
stage of migration.
spice version will be bumped in one of the following patches.
The list of attached char_devices will be used in the next patch
for notifying each instance of SpiceCharDeviceState when the vm
is started or stopped.
Rules for replacing spice_printerr:
* if it's a client drop / agent drop, spice_error
* if it's important, spice_warning
* else, spice_info.
The fourth rule is spice_debug if it's going to fill up the log, but
nothing of the sort here.
Other things this patch does:
* changed reds_show_new_channel to reds_info_new_channel in an attempt to
advertise it doesn't always show anything, unless SPICE_DEBUG_LOG_LEVEL
>= SPICE_DEVUG_LOG_INFO (==3)
* removes two lines of whitespace.
* added "crashy" to multiple client warning (only warning introduced,
the rest are errors).
This patch and the following one do not introduce tokening to the smartcard
channel. But this can be done easily later, by setting the appropriate
variables in SpiceCharDeviceState (after adding the appropriate protocol messages,
and implementing this in the client side).
This patch and the following one do not introduce tokening to the
spicevmc channel. But this can be done easily later, by setting the appropriate
variables in SpiceCharDeviceState (after adding
the appropriate protocol messages, and implementing this in the client
side).
This code is never called, it was relevant for seamless migration.
Most of the data that needs to be migrated was moved to
SpiceCharDeviceState. When we implement seamless migration,
we will have routines in char_device.c for migrating the relevant data.
- Allow sending tokens to a specific client.
- Do not ignore tokens that are sent from the client to the server.
The tokens support for multiple clients and for server side tokens
is still broken in reds. It will be fixed in following patches, when
the server-side agent code will use the SpiceCharDeviceState api.
Notice that ignoring the server-side tokens didn't introduce a problem
since both the client and the server set it to ~0.
If a 'goto' statement jumps across a variable declaration
which also has an initializer, the variable is in an undefined
state. Splitting the the declaration & initialization doesn't
change that, but the compiler can at least now detect use of
the unintialized variable
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
