netdev - Re: [PATCH v2 2/3] net/handshake: Add support for PF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9B7B66AA-E885-4317-8FE7-C9ABC94E027C@oracle.com>
Date:   Tue, 31 Jan 2023 15:18:02 +0000
From:   Chuck Lever III <chuck.lever@...cle.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     netdev <netdev@...r.kernel.org>, "hare@...e.com" <hare@...e.com>,
        David Howells <dhowells@...hat.com>,
        Olga Kornievskaia <kolga@...app.com>,
        "jmeneghi@...hat.com" <jmeneghi@...hat.com>,
        Benjamin Coddington <bcodding@...hat.com>,
        Jeff Layton <jlayton@...hat.com>
Subject: Re: [PATCH v2 2/3] net/handshake: Add support for PF_HANDSHAKE



> On Jan 30, 2023, at 11:35 PM, Jakub Kicinski <kuba@...nel.org> wrote:
> 
> On Sat, 28 Jan 2023 14:06:49 +0000 Chuck Lever III wrote:
>>> On Jan 28, 2023, at 3:32 AM, Jakub Kicinski <kuba@...nel.org> 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.  
>> 
>> poll/listen/accept is the simplest and most natural way of
>> materializing a socket endpoint in a process that I can think
>> of. It's a well-understood building block. What specifically
>> is troubling you about it?
> 
> poll/listen/accept yes, but that's not the entire socket interface. 
> Our overall experience with the TCP ULPs is rather painful, proxying
> all the other callbacks here may add another dimension.

> Also I have a fear (perhaps unjustified) of reusing constructs which are
> cornerstones of the networking stack and treating them as abstractions.

OK, then I take this as a NAK for listen/poll/accept in
any form. I need some finality here because we need to
move forward.


>>> I'd like a second opinion on that, if anyone within netdev
>>> is willing to share..  
>> 
>> Hopefully that opinion comes with an alternative way of getting
>> a connected kernel socket endpoint up to user space without
>> race issues.
> 
> If the user application decides the fd, wouldn't that solve the problem
> in netlink?

David or Hannes will have to answer that because they
understand the races better than I do.

However, I will prototype "fd passing" with netlink and
ignore the races for now, just to get something to
continue the conversation.


>  kernel                          user space
> 
>   notification     ---------->
> (new connection awaits)
> 
>                    <----------
>                                  request (target fd=100)
> 
>                    ---------->
>   reply
> (fd 100 is installed;
>  extra params)

What type of notification do you prefer for this? You've
said in the past that RT signals are not appropriate. It
would be easy for user space to simply wait on nlm_recvmsg()
but I worry that netlink is not a reliable message service.

And, do you have a preferred mechanism or code sample for
installing a socket descriptor? 


--
Chuck Lever