Re: [PATCH 11/18] nvme-tcp: control message handling for recvmsg()

[Hannes Reinecke <hare@suse.de>]

On 3/22/23 12:33, Sagi Grimberg wrote:
> 
>> kTLS is sending TLS ALERT messages as control messages for recvmsg().
>> As we can't do anything sensible with it just abort the connection
>> and let the userspace agent to a re-negotiation.
> 
> Is this a problem if we do end up adding read_sock to tls?
> Although I do see that the tls code does manage this in the
> sk_buff control buffer, so I assume there is access to this info.
> 
> CC'ing Boris here as well.
> 
Yeah, that was the other reason; cmsg aka TLS alerts are only available 
for recvmsg().

However, for TLS 1.3 the only TLS alert which does not trigger a 
connection reset would the the ominous 'new session ticket' alert.
But during TLS handshake development we already decided to _disable_
session tickets as they are pretty meaningless for our us.
Consequently all TLS alerts will trigger a connection reset, and 
realistically we don't _need_ to know which alert type has triggered
the reset.

So 'read_sock()' could be implemented by closing the connection on
any TLS alert, and not giving us access to any of the alerts via
control messages. If that makes life easier ...

Cheers,

Hannes