Re: Question regarding TLS Key update for NVMe-TCP protocol

[Sabrina Dubroca <sd@queasysnail.net>]

2024-12-06, 15:26:08 +0100, Hannes Reinecke wrote:
> On 12/6/24 14:05, Sabrina Dubroca wrote:
> > 2024-12-06, 13:09:23 +0100, Hannes Reinecke wrote:
> > > But how does userspace get the KeyUpdate message in the first place?
> > > I _think_ we should get something like TLS_ALERT from the ktls stack.
> > > How is that implemented?
> > 
> > (talking strictly about "pure" ktls, not tls-handshake/tlshd)
> > 
> > Data records are passed to userspace via a simple recv(). Non-data
> > records (for example a KeyUpdate) need cmsg: the record type is
> > stuffed into a cmsg, the payload goes in the usual buffer. If the next
> > available record is non-data and no cmsg is provided, the read will
> > fail. See Documentation/networking/tls.rst (or
> > https://docs.kernel.org/networking/tls.html) for more details on how
> > cmsg is used.
> > 
> 
> Ah, right. And that's the issue.
> NVMe-TLS is using the 'read_sock()' interface, which doesn't do control
> messages. And changing it over to recvmsg() would not only be a major churn,
> but we also lose the ability to calculate data digests.
> 
> So if you have ideas how to handle that ...

But you have to use recvmsg for the control record if read_sock can't
read anything, which will happen when you hit a control record in the
stream. At this point you have to call recvmsg() to dequeue the
non-data record, process it, and then you can go back to read_sock
until the next non-data record arrives. Like a splice-based userspace
application, I guess. As long as you don't pop that control record
from the socket, you can't read the rest of the stream.

On the TX side, if you have to initiate a KeyUpdate because you've hit
the limit on the current key (or the peer sent its own KeyUpdate and
requested you to also update your key), you'll have to send that
KeyUpdate with sendmsg and the correct cmsg (see the selftest patch
for basic examples from a userspace program [1]).

[1] mainly TEST_F(tls, rekey), and maybe TEST_F(tls, splice_rekey) if
read_sock is similar enough to splice
https://lore.kernel.org/netdev/e00a6aed157b20573afbfc6c2353af2afa54f48e.1731597571.git.sd@queasysnail.net/

-- 
Sabrina