| Message ID | 20240318182330.96738-3-berrange@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Fix TLS support for chardevs and incoming data loss on EOF | expand |
Hi On Mon, Mar 18, 2024 at 10:23 PM Daniel P. Berrangé <berrange@redhat.com> wrote: > > This commit results in unexpected termination of the TLS connection. > When 'fd_can_read' returns 0, the code goes on to pass a zero length > buffer to qio_channel_read. The TLS impl calls into gnutls_recv() > with this zero length buffer, at which point GNUTLS returns an error > GNUTLS_E_INVALID_REQUEST. This is treated as fatal by QEMU's TLS code > resulting in the connection being torn down by the chardev. > > Simply skipping the qio_channel_read when the buffer length is zero > is also not satisfactory, as it results in a high CPU burn busy loop > massively slowing QEMU's functionality. > > The proper solution is to avoid tcp_chr_read being called at all > unless the frontend is able to accept more data. This will be done > in a followup commit. > > This reverts commit 1907f4d149c3589ade641423c6a33fd7598fa4d3. Actually 462945cd22d2bcd233401ed3aa167d83a8e35b05 upstream. > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> > --- > chardev/char-socket.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/chardev/char-socket.c b/chardev/char-socket.c > index 2c4dffc0e6..812d7aa38a 100644 > --- a/chardev/char-socket.c > +++ b/chardev/char-socket.c > @@ -496,9 +496,9 @@ static gboolean tcp_chr_read(QIOChannel *chan, GIOCondition cond, void *opaque) > s->max_size <= 0) { > return TRUE; > } > - len = tcp_chr_read_poll(opaque); > - if (len > sizeof(buf)) { > - len = sizeof(buf); > + len = sizeof(buf); > + if (len > s->max_size) { > + len = s->max_size; > } > size = tcp_chr_recv(chr, (void *)buf, len); > if (size == 0 || (size == -1 && errno != EAGAIN)) { > -- > 2.43.0 >
On 18/03/2024 19.23, Daniel P. Berrangé wrote: > This commit results in unexpected termination of the TLS connection. > When 'fd_can_read' returns 0, the code goes on to pass a zero length > buffer to qio_channel_read. The TLS impl calls into gnutls_recv() > with this zero length buffer, at which point GNUTLS returns an error > GNUTLS_E_INVALID_REQUEST. This is treated as fatal by QEMU's TLS code > resulting in the connection being torn down by the chardev. > > Simply skipping the qio_channel_read when the buffer length is zero > is also not satisfactory, as it results in a high CPU burn busy loop > massively slowing QEMU's functionality. > > The proper solution is to avoid tcp_chr_read being called at all > unless the frontend is able to accept more data. This will be done > in a followup commit. > > This reverts commit 1907f4d149c3589ade641423c6a33fd7598fa4d3. > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> > --- > chardev/char-socket.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Reviewed-by: Thomas Huth <thuth@redhat.com>
On Mon, Mar 18, 2024 at 11:09:23PM +0400, Marc-André Lureau wrote: > Hi > > On Mon, Mar 18, 2024 at 10:23 PM Daniel P. Berrangé <berrange@redhat.com> wrote: > > > > This commit results in unexpected termination of the TLS connection. > > When 'fd_can_read' returns 0, the code goes on to pass a zero length > > buffer to qio_channel_read. The TLS impl calls into gnutls_recv() > > with this zero length buffer, at which point GNUTLS returns an error > > GNUTLS_E_INVALID_REQUEST. This is treated as fatal by QEMU's TLS code > > resulting in the connection being torn down by the chardev. > > > > Simply skipping the qio_channel_read when the buffer length is zero > > is also not satisfactory, as it results in a high CPU burn busy loop > > massively slowing QEMU's functionality. > > > > The proper solution is to avoid tcp_chr_read being called at all > > unless the frontend is able to accept more data. This will be done > > in a followup commit. > > > > This reverts commit 1907f4d149c3589ade641423c6a33fd7598fa4d3. > > Actually 462945cd22d2bcd233401ed3aa167d83a8e35b05 upstream. Opps, yes, will fix this before I send a pull. > > > > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> > > --- > > chardev/char-socket.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/chardev/char-socket.c b/chardev/char-socket.c > > index 2c4dffc0e6..812d7aa38a 100644 > > --- a/chardev/char-socket.c > > +++ b/chardev/char-socket.c > > @@ -496,9 +496,9 @@ static gboolean tcp_chr_read(QIOChannel *chan, GIOCondition cond, void *opaque) > > s->max_size <= 0) { > > return TRUE; > > } > > - len = tcp_chr_read_poll(opaque); > > - if (len > sizeof(buf)) { > > - len = sizeof(buf); > > + len = sizeof(buf); > > + if (len > s->max_size) { > > + len = s->max_size; > > } > > size = tcp_chr_recv(chr, (void *)buf, len); > > if (size == 0 || (size == -1 && errno != EAGAIN)) { > > -- > > 2.43.0 > > > With regards, Daniel
diff --git a/chardev/char-socket.c b/chardev/char-socket.c index 2c4dffc0e6..812d7aa38a 100644 --- a/chardev/char-socket.c +++ b/chardev/char-socket.c @@ -496,9 +496,9 @@ static gboolean tcp_chr_read(QIOChannel *chan, GIOCondition cond, void *opaque) s->max_size <= 0) { return TRUE; } - len = tcp_chr_read_poll(opaque); - if (len > sizeof(buf)) { - len = sizeof(buf); + len = sizeof(buf); + if (len > s->max_size) { + len = s->max_size; } size = tcp_chr_recv(chr, (void *)buf, len); if (size == 0 || (size == -1 && errno != EAGAIN)) {
This commit results in unexpected termination of the TLS connection. When 'fd_can_read' returns 0, the code goes on to pass a zero length buffer to qio_channel_read. The TLS impl calls into gnutls_recv() with this zero length buffer, at which point GNUTLS returns an error GNUTLS_E_INVALID_REQUEST. This is treated as fatal by QEMU's TLS code resulting in the connection being torn down by the chardev. Simply skipping the qio_channel_read when the buffer length is zero is also not satisfactory, as it results in a high CPU burn busy loop massively slowing QEMU's functionality. The proper solution is to avoid tcp_chr_read being called at all unless the frontend is able to accept more data. This will be done in a followup commit. This reverts commit 1907f4d149c3589ade641423c6a33fd7598fa4d3. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- chardev/char-socket.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)