Re: [PATCH 1/4] tls-handshake: add 'timeout' netlink attribute

[Hannes Reinecke <hare@suse.de>]

On 2/17/23 12:58, Chuck Lever III wrote:
> 
> 
>> On Feb 17, 2023, at 6:31 AM, Hannes Reinecke <hare@suse.de> wrote:
>>
>> Add a 'timeout' netlink attribute to the 'request' netlink
>> message to allow the kernel to communicate an internal timeout
>> to userspace.
> 
> Can you describe the use caae?
> 
> I'm not clear on why we need to parametrize the handshake
> timeout. Why would it need to be changed? Why would, say,
> a PSK handshake need a different timeout than x.509? And,
> why doesn't a timeout wait in the API consumer work just
> as well?
> 
> Last we left this, you were using the timeout to work
> around some socket reference counting issues. I think we
> need to address those first.
> 
The problem is that we have have a timeout on the kernel side, and 
another timeout on the userland side.
This is primarily an issue for the client, as the kernel code
needs to continue _eventually_, otherwise the connection will
stall.
So we do need a timeout for the client to ensure forward progress.
Hence the kernel client needs a timeout to eventually declare the 
handshake non-functional and either abort or retry without TLS.

But as the kernel now has a timeout, that would need to be transported
to userland to tell the application to stop trying after a certain time.
Which is what this parameter does.

The alternative would be to kill the application directly from the 
kernel (or send some other signal), but that's really nasty and then we 
would need to worry about cleanup effects. Hence I'd rather not.

This approach has the benefit that the kernel can wait slightly longer 
than the timeout sent to userspace (in my code I've added two seconds), 
giving userspace enough time to send a completion message to the kernel.
With that we can be sure that userspace has given up control of the 
socket, and we remain the sole owner.
Without such a message it's always tricky to figure out _who_ has 
control over the socket, leading to all sorts of reference counting issues.

Cheers,

Hannes