[gnutls-devel] GnuTLS | kTLS gets desynchronised when sending (in gnutls_record_send) (#1470)

[Read-only notification of GnuTLS library development activities]

Richard W_M_ Jones created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1470



## Description of problem:

Since both `nbdkit` and `libnbd` support gnutls + kTLS, I can test (k)TLS sending and receiving between our server and client.  I have found that if the sending process is using kTLS, then the data gets desynchronised under load.  However receiving using kTLS seems fine.  It seems there is a problem in gnutls_record_send (or perhaps the kernel related to sendmsg when using kTLS).

Here is my test:

```
$ psktool -u alice -p keys.psk
$ nbdkit --tls=require --tls-psk=keys.psk pattern 10G \
         --run 'nbdcopy -p --no-extents "nbds://alice@localhost?tls-psk-file=keys.psk" null:'
```

It copies 10G of pattern data from nbdkit (server) to nbdcopy (client) and then throws it away (`null:`) over TCP localhost port 10809.

The pattern data is generated by https://libguestfs.org/nbdkit-pattern-plugin.1.html

Without kTLS it works fine.  With kTLS it fails.

I also hacked gnutls so I could disable kTLS selectively.  Using LD_LIBRARY_PATH I am able to selectively enable and disable kTLS at either end.  I found that it only fails if the **sender** is using kTLS, not if the sender is using userspace TLS and the receiver is using kTLS.  This seems to indicate the problem happens on the sending side.

I also used strace to show that it is a desynchronisation problem, because we can see the patterns produced by https://libguestfs.org/nbdkit-pattern-plugin.1.html in what is supposed to be an NBD reply header.

## Version of gnutls used:

gnutls @ 496b4bb357adfbaa
kernel 6.2.0-0.rc7.20230206gitd2d11f342b17.50.fc38.x86_64

## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL)

Fedora, but self-built.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1470
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20230310/3fe09627/attachment.html>