[0/2] TLS: fix read stall with large buffers

Message

Antoine Damhet Nov. 15, 2022, 2:23 p.m. UTC

From: Antoine Damhet <[e-mail]>

At least with the TCP backend the tls implementation can stall because
the current notification mechanism is based on the readyness status of
the underlying file descriptor but gnutls can read all the data
available while the consumer has only handled part (eg: the TCP
implementation is capped to 4096 bytes per read).

We encountered the bug on the real world using encrypted
USB-redirection but we could reproduce it with virtio-serial.

On the host side:

```
$ mkdir /tmp/tls-test
$ echo 'test:8e6da54b954357236ec2eed1df0dc3542163dd03bf9c94f2d90781a3a3e443c9' > /tmp/tls-test/keys.psk
$ qemu-system-x86_64 -m 4G -enable-kvm -device virtio-serial \
	-object tls-creds-psk,id=tls0,endpoint=server,dir=/tmp/tls-test \
	-chardev socket,server=on,wait=off,id=serial-sock,port=4242,host=127.0.0.1,tls-creds=tls0 \
	-device virtserialport,chardev=serial-sock,name=test.serial \
	-cdrom archlinux-2022.11.01-x86_64.iso
# The sleep is to keep the socket open during the test
$ python -c 'print(8192 * "a"); import time; time.sleep(600);' | \
	openssl s_client -connect 127.0.0.1:4242 \
	-psk 8e6da54b954357236ec2eed1df0dc3542163dd03bf9c94f2d90781a3a3e443c9 \
	-psk_identity test
```

On the guest side:

```
# The socket is forced open, we stop cat manually
$ cat /dev/virtio-ports/test.serial > test.data
^C
# only part of the data was readable
$ wc -c test.data
4096
```

Antoine Damhet (2):
  crypto: TLS: introduce `check_pending`
  io/channel-tls: fix handling of bigger read buffers

 crypto/tlssession.c         | 14 ++++++++
 include/crypto/tlssession.h | 11 +++++++
 io/channel-tls.c            | 66 ++++++++++++++++++++++++++++++++++++-
 3 files changed, 90 insertions(+), 1 deletion(-)