[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <048cba69-aa9a-08d1-789f-fe17c408cfb2@suse.de>
Date: Sun, 29 Jan 2023 17:21:04 +0100
From: Hannes Reinecke <hare@...e.de>
To: Jakub Kicinski <kuba@...nel.org>,
Chuck Lever <chuck.lever@...cle.com>
Cc: netdev@...r.kernel.org, hare@...e.com, dhowells@...hat.com,
kolga@...app.com, jmeneghi@...hat.com, bcodding@...hat.com,
jlayton@...hat.com
Subject: Re: [PATCH v2 2/3] net/handshake: Add support for PF_HANDSHAKE
On 1/28/23 09:32, Jakub Kicinski wrote:
> On Thu, 26 Jan 2023 11:02:22 -0500 Chuck Lever wrote:
>> I've designed a way to pass a connected kernel socket endpoint to
>> user space using the traditional listen/accept mechanism. accept(2)
>> gives us a well-worn building block that can materialize a connected
>> socket endpoint as a file descriptor in a specific user space
>> process. Like any open socket descriptor, the accepted FD can then
>> be passed to a library such as GnuTLS to perform a TLS handshake.
>
> I can't bring myself to like the new socket family layer.
> I'd like a second opinion on that, if anyone within netdev
> is willing to share..
I am not particularly fond of that, either, but the alternative of using
netlink doesn't make it any better
You can't pass the fd/socket directly via netlink messages, you can only
pass the (open!) fd number with the message.
The fd itself _needs_ be be part of the process context of the
application by the time the application processes that message.
Consequently:
- I can't see how an application can _reject_ the message; the fd needs
to be present in the fd table even before the message is processed,
rendering any decision by the application pointless (and I would _so_
love to be proven wrong on this point)
- It's slightly tricky to handle processes which go away prior to
handling the message; I _think_ the process cleanup code will close the
fd, but I guess it also depends on how and when the fd is stored in the
process context.
If someone can point me to a solution for these points I would vastly
prefer to move to netlink. But with these issues in place I'm not sure
if netlink doesn't cause more issues than it solves.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@...e.de +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew
Myers, Andrew McDonald, Martje Boudien Moerman
Powered by blists - more mailing lists