From: "Benjamin Coddington" <email@example.com> To: "Hannes Reinecke" <firstname.lastname@example.org> Cc: "Jakub Kicinski" <email@example.com>, "Sagi Grimberg" <firstname.lastname@example.org>, "Chuck Lever" <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com Subject: Re: [PATCH RFC 4/5] net/tls: Add support for PF_TLSH (a TLS handshake listener) Date: Thu, 28 Apr 2022 10:09:17 -0400 [thread overview] Message-ID: <E2BF9CFF-9361-400B-BDEE-CF5E0AFDCA63@redhat.com> (raw) In-Reply-To: <firstname.lastname@example.org> On 28 Apr 2022, at 9:51, Hannes Reinecke wrote: > On 4/28/22 15:30, Jakub Kicinski wrote: >> On Thu, 28 Apr 2022 09:26:41 +0200 Hannes Reinecke wrote: >>> The whole thing started off with the problem on _how_ sockets could be >>> passed between kernel and userspace and vice versa. >>> While there is fd passing between processes via AF_UNIX, there is no >>> such mechanism between kernel and userspace. >> >> Noob question - the kernel <> user space FD sharing is just >> not implemented yet, or somehow fundamentally hard because kernel >> fds are "special"? > > Noob reply: wish I knew. (I somewhat hoped _you_ would've been able to > tell me.) > > Thing is, the only method I could think of for fd passing is the POSIX fd > passing via unix_attach_fds()/unix_detach_fds(). But that's AF_UNIX, > which really is designed for process-to-process communication, not > process-to-kernel. So you probably have to move a similar logic over to > AF_NETLINK. And design a new interface on how fds should be passed over > AF_NETLINK. > > But then you have to face the issue that AF_NELINK is essentially UDP, and > you have _no_ idea if and how many processes do listen on the other end. > Thing is, you (as the sender) have to copy the fd over to the receiving > process, so you'd better _hope_ there is a receiving process. Not to > mention that there might be several processes listening in... > > And that's something I _definitely_ don't feel comfortable with without > guidance from the networking folks, so I didn't pursue it further and we > went with the 'accept()' mechanism Chuck implemented. > > I'm open to suggestions, though. EXPORT_SYMBOL(receive_fd) would allow interesting implementations. The kernel keyring facilities have a good API for creating various key_types which are able to perform work such as this from userspace contexts. I have a working prototype for a keyring key instantiation which allows a userspace process to install a kernel fd on its file table. The problem here is how to match/route such fd passing to appropriate processes in appropriate namespaces. I think this problem is shared by all kernel-to-userspace upcalls, which I hope we can discuss at LSF/MM. I don't think kernel fds are very special as compared to userspace fds. Ben
next prev parent reply other threads:[~2022-04-28 14:09 UTC|newest] Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-18 16:49 [PATCH RFC 0/5] Implement a TLS handshake upcall Chuck Lever 2022-04-18 16:49 ` [PATCH RFC 1/5] net: Add distinct sk_psock field Chuck Lever 2022-04-21 7:35 ` Hannes Reinecke 2022-07-13 4:46 ` Hawkins Jiawei 2022-07-13 4:46 ` Hawkins Jiawei 2022-04-18 16:49 ` [PATCH RFC 2/5] tls: build proto after context has been initialized Chuck Lever 2022-04-25 17:11 ` Jakub Kicinski 2022-04-25 17:51 ` Chuck Lever III 2022-05-20 16:39 ` Chuck Lever III 2022-04-18 16:49 ` [PATCH RFC 3/5] net/tls: Add an AF_TLSH address family Chuck Lever 2022-04-21 7:35 ` Hannes Reinecke 2022-04-18 16:49 ` [PATCH RFC 4/5] net/tls: Add support for PF_TLSH (a TLS handshake listener) Chuck Lever 2022-04-21 7:36 ` Hannes Reinecke 2022-04-25 17:14 ` Jakub Kicinski 2022-04-26 9:43 ` Hannes Reinecke 2022-04-26 14:29 ` Sagi Grimberg 2022-04-26 15:02 ` Jakub Kicinski 2022-04-26 15:58 ` Hannes Reinecke 2022-04-27 0:03 ` Jakub Kicinski 2022-04-27 15:24 ` Chuck Lever III 2022-04-28 7:26 ` Hannes Reinecke 2022-04-28 13:30 ` Jakub Kicinski 2022-04-28 13:51 ` Hannes Reinecke 2022-04-28 14:09 ` Benjamin Coddington [this message] 2022-04-28 21:08 ` Jakub Kicinski 2022-05-24 10:05 ` [ovs-dev] " Ilya Maximets 2022-04-26 14:55 ` Jakub Kicinski 2022-04-26 13:48 ` Chuck Lever III 2022-04-26 14:55 ` Jakub Kicinski 2022-04-26 15:58 ` Chuck Lever III 2022-04-26 23:47 ` Jakub Kicinski 2022-04-27 14:42 ` Chuck Lever III 2022-04-27 23:53 ` Jakub Kicinski 2022-04-28 1:29 ` Chuck Lever III 2022-04-28 21:08 ` Jakub Kicinski 2022-04-28 21:54 ` Chuck Lever III 2022-04-28 8:49 ` Boris Pismenny 2022-04-28 13:12 ` Simo Sorce 2022-04-29 15:19 ` Chuck Lever III 2022-04-28 15:24 ` Chuck Lever III 2022-04-29 6:25 ` Hannes Reinecke 2022-04-18 16:49 ` [PATCH RFC 5/5] net/tls: Add observability for AF_TLSH sockets Chuck Lever 2022-04-21 7:36 ` Hannes Reinecke
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=E2BF9CFF-9361-400B-BDEE-CF5E0AFDCA63@redhat.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH RFC 4/5] net/tls: Add support for PF_TLSH (a TLS handshake listener)' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.