All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Yongji Xie" <elohimes@gmail.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Thomas Huth" <thuth@redhat.com>,
	"Laurent Vivier" <lvivier@redhat.com>
Subject: [Qemu-devel] [PATCH v3 13/16] chardev: disallow TLS/telnet/websocket with tcp_chr_wait_connected
Date: Mon, 11 Feb 2019 18:24:39 +0000	[thread overview]
Message-ID: <20190211182442.8542-14-berrange@redhat.com> (raw)
In-Reply-To: <20190211182442.8542-1-berrange@redhat.com>

In the previous commit

    commit 1dc8a6695c731abb7461c637b2512c3670d82be4
    Author: Marc-André Lureau <marcandre.lureau@redhat.com>
    Date:   Tue Aug 16 12:33:32 2016 +0400

      char: fix waiting for TLS and telnet connection

the tcp_chr_wait_connected() method was changed to check for a non-NULL
's->ioc' as a sign that there is already a connection present, as
opposed to checking the "connected" flag to supposedly fix handling of
TLS/telnet connections.

The original code would repeatedly call tcp_chr_wait_connected creating
many connections as 'connected' would never become true. The changed
code would still repeatedly call tcp_chr_wait_connected busy waiting
because s->ioc is set but the chardev will never see CHR_EVENT_OPENED.
IOW, the code is still broken with TLS/telnet, but in a different way.

Checking for a non-NULL 's->ioc' does not mean that a CHR_EVENT_OPENED
will be ready for a TLS/telnet connection. These protocols (and the
websocket protocol) all require the main loop to be running in order
to complete the protocol handshake before emitting CHR_EVENT_OPENED.
The tcp_chr_wait_connected() method is only used during early startup
before a main loop is running, so TLS/telnet/websock connections can
never complete initialization.

Making this work would require changing tcp_chr_wait_connected to run
a main loop. This is quite complex since we must not allow GSource's
that other parts of QEMU have registered to run yet. The current callers
of tcp_chr_wait_connected do not require use of the TLS/telnet/websocket
protocols, so the simplest option is to just forbid this combination
completely for now.

Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 chardev/char-socket.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/chardev/char-socket.c b/chardev/char-socket.c
index 7db20ff0a0..86c1f502d6 100644
--- a/chardev/char-socket.c
+++ b/chardev/char-socket.c
@@ -951,8 +951,20 @@ static void tcp_chr_accept_server_sync(Chardev *chr)
 static int tcp_chr_wait_connected(Chardev *chr, Error **errp)
 {
     SocketChardev *s = SOCKET_CHARDEV(chr);
-    /* It can't wait on s->connected, since it is set asynchronously
-     * in TLS and telnet cases, only wait for an accepted socket */
+    const char *opts[] = { "telnet", "tn3270", "websock", "tls-creds" };
+    bool optset[] = { s->is_telnet, s->is_tn3270, s->is_websock, s->tls_creds };
+    size_t i;
+
+    QEMU_BUILD_BUG_ON(G_N_ELEMENTS(opts) != G_N_ELEMENTS(optset));
+    for (i = 0; i < G_N_ELEMENTS(opts); i++) {
+        if (optset[i]) {
+            error_setg(errp,
+                       "'%s' option is incompatible with waiting for "
+                       "connection completion", opts[i]);
+            return -1;
+        }
+    }
+
     while (!s->ioc) {
         if (s->is_listen) {
             tcp_chr_accept_server_sync(chr);
-- 
2.20.1

  parent reply	other threads:[~2019-02-11 18:26 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-11 18:24 [Qemu-devel] [PATCH v3 00/16] chardev: refactoring & many bugfixes related tcp_chr_wait_connected Daniel P. Berrangé
2019-02-11 18:24 ` [Qemu-devel] [PATCH v3 01/16] io: store reference to thread information in the QIOTask struct Daniel P. Berrangé
2019-02-11 18:24 ` [Qemu-devel] [PATCH v3 02/16] io: add qio_task_wait_thread to join with a background thread Daniel P. Berrangé
2019-02-11 18:24 ` [Qemu-devel] [PATCH v3 03/16] chardev: fix validation of options for QMP created chardevs Daniel P. Berrangé
2019-02-11 18:24 ` [Qemu-devel] [PATCH v3 04/16] chardev: forbid 'reconnect' option with server sockets Daniel P. Berrangé
2019-02-11 18:24 ` [Qemu-devel] [PATCH v3 05/16] chardev: forbid 'wait' option with client sockets Daniel P. Berrangé
2019-02-11 18:24 ` [Qemu-devel] [PATCH v3 06/16] chardev: remove many local variables in qemu_chr_parse_socket Daniel P. Berrangé
2019-02-11 18:24 ` [Qemu-devel] [PATCH v3 07/16] chardev: ensure qemu_chr_parse_compat reports missing driver error Daniel P. Berrangé
2019-02-11 18:24 ` [Qemu-devel] [PATCH v3 08/16] chardev: remove unused 'sioc' variable & cleanup paths Daniel P. Berrangé
2019-02-11 18:24 ` [Qemu-devel] [PATCH v3 09/16] chardev: split tcp_chr_wait_connected into two methods Daniel P. Berrangé
2019-02-11 18:24 ` [Qemu-devel] [PATCH v3 10/16] chardev: split up qmp_chardev_open_socket connection code Daniel P. Berrangé
2019-02-11 18:24 ` [Qemu-devel] [PATCH v3 11/16] chardev: use a state machine for socket connection state Daniel P. Berrangé
2019-02-11 18:24 ` [Qemu-devel] [PATCH v3 12/16] chardev: honour the reconnect setting in tcp_chr_wait_connected Daniel P. Berrangé
2019-02-11 18:24 ` Daniel P. Berrangé [this message]
2019-02-11 18:24 ` [Qemu-devel] [PATCH v3 14/16] chardev: fix race with client connections " Daniel P. Berrangé
2019-02-11 18:24 ` [Qemu-devel] [PATCH v3 15/16] tests: expand coverage of socket chardev test Daniel P. Berrangé
2019-02-11 18:24 ` [Qemu-devel] [PATCH v3 16/16] chardev: ensure termios is fully initialized Daniel P. Berrangé
2019-04-22 14:51 ` [Qemu-devel] [PATCH v3 00/16] chardev: refactoring & many bugfixes related tcp_chr_wait_connected Eric Blake
2019-04-22 14:51   ` Eric Blake
2019-04-23 14:13   ` Daniel P. Berrangé
2019-04-23 14:13     ` Daniel P. Berrangé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190211182442.8542-14-berrange@redhat.com \
    --to=berrange@redhat.com \
    --cc=elohimes@gmail.com \
    --cc=lvivier@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.