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]

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