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

[Hannes Reinecke]

On 3/22/23 12:50, 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 ...
> 
> Most likely read_sock() is the wrong place to ignore alerts. Probably
> the better way is to do this in nvme, although its a bit harder.

But that's just the point; you don't have OOB information for 
read_sock(). So I wouldn't know how you could pass the TLS alert 
messages. Hence my idea of converting them into a connection reset for 
read_sock().
As the whole idea of using ktls is that you do _not_ have to handle TLS 
details, it's questionable what exactly one could do here except from 
resetting the connection...

Cheers,

Hannes