On 9/17/25 05:14, Alistair Francis wrote:

On Tue, Sep 16, 2025 at 11:04 PM Hannes Reinecke [off-list ref] wrote:

quoted

[ .. ]

quoted

Oh bugger. Seems like gnutls is generating the KeyUpdate message
itself, and we have to wait for that.

Yes, we have gnutls generate the message.

quoted

So much for KeyUpdate being transparent without having to stop I/O...

Can't we fix gnutls to make sending the KeyUpdate message and changing
the IV parameters an atomic operation? That would be a far better

I'm not sure I follow.

ktls-utils will first restore the gnutls session. Then have gnutls
trigger a KeyUpdate.gnutls will send a KeyUpdate and then tell the
kernel the new keys. The kernel cannot send or encrypt any data after
the KeyUpdate has been sent until the keys are updated.

I don't see how we could make it an atomic operation. We have to stop
the traffic between sending a KeyUpdate and updating the keys.
Otherwise we will send invalid data.

Fully agree with that.
But thing is, the KeyUpdate message is a unidirectional thing.
Host A initiating a KeyUpdate must only change the _sender_ side
keys after sending a KeyUpdate message to host B; the receiver
side keys on host A can only be update once it received the 
corresponding KeyUpdate from host B. If both keys on host A
are modified at the same time we cannot receive the KeyUpdate
message from host B as that will be encoded with the old
keys ...

I wonder how that can be modeled in gnutls; I only see
gnutls_session_key_update() which apparently will update both
keys at once.
Which would fit perfectly for host B receiving the initial KeyUpdate,
(and is probably the reason why you did that side first :-)
but what to do for host A?

Looking at the code gnutls seem to expect to read the handshake
message from the socket, but that message is already processed by
the in-kernel TLS socket.
So either we need to patch gnutls or push a fake handshake
message onto the socket for gnutls to read. Bah.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich