All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ilya Maximets <i.maximets@ovn.org>
To: Jakub Kicinski <kuba@kernel.org>,
	Benjamin Coddington <bcodding@redhat.com>
Cc: dev@openvswitch.org, linux-cifs@vger.kernel.org,
	linux-nfs@vger.kernel.org, Sagi Grimberg <sagi@grimberg.me>,
	borisp@nvidia.com, netdev@vger.kernel.org,
	linux-nvme@lists.infradead.org,
	Chuck Lever <chuck.lever@oracle.com>,
	Hannes Reinecke <hare@suse.de>,
	simo@redhat.com, linux-fsdevel@vger.kernel.org,
	ak@tempesta-tech.com, i.maximets@ovn.org
Subject: Re: [ovs-dev] [PATCH RFC 4/5] net/tls: Add support for PF_TLSH (a TLS handshake listener)
Date: Tue, 24 May 2022 12:05:01 +0200	[thread overview]
Message-ID: <457ccb80-d41d-ff95-1edc-751741465416@ovn.org> (raw)
In-Reply-To: <20220428140856.61e53533@kernel.org>

On 4/28/22 23:08, Jakub Kicinski wrote:
> On Thu, 28 Apr 2022 10:09:17 -0400 Benjamin Coddington wrote:
>>> 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...
> 
> Sort of. I double checked the netlink upcall implementations we have,
> they work by user space entity "registering" their netlink address
> (portid) at startup. Kernel then directs the upcalls to that address.
> But AFAICT there's currently no way for the netlink "server" to see
> when a "client" goes away, which makes me slightly uneasy about using
> such schemes for security related stuff. The user agent may crash and
> something else could grab the same address, I think.
> 
> Let me CC OvS who uses it the most, perhaps I'm missing a trick.

I don't think there are any tricks.  From what I see OVS creates
several netlink sockets, connects them to the kernel (nl_pid = 0)
and obtains their nl_pid's from the kernel.
These pids are either just a task_tgid_vnr() or a random negative
value from the [S32_MIN, -4096] range.  After that OVS "registers"
those pids in the openvswitch kernel module.  That just means sending
an array of integers to the kernel.  Kernel will later use these
integer pids to find the socket and send data to the userspace.

openvswitch module inside the kernel has no way to detect that
socket with a certain pid no longer exists.  So, it will continue
to try to find the socket and send, even if the user-space process
is dead.

So, if you can find a way to reliably create a process with the
same task_tgid or trick the randomizer inside the netlink_autobind(),
you can start receiving upcalls from the kernel in a new process,
IIUC.  Also, netlink_bind() allows to just specify the nl_pid
for listening sockets.  That might be another way.

> 
> My thinking was to use the netlink attribute format (just to reuse the
> helpers and parsing, but we can invent a new TLV format if needed) but
> create a new socket type specifically for upcalls.
> 
>>> 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.
> 
> Almost made me wish I was coming to LFS/MM :)
> 
>> I don't think kernel fds are very special as compared to userspace fds.
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> 


  reply	other threads:[~2022-05-24 10:05 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
2022-04-28 21:08                       ` Jakub Kicinski
2022-05-24 10:05                         ` Ilya Maximets [this message]
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=457ccb80-d41d-ff95-1edc-751741465416@ovn.org \
    --to=i.maximets@ovn.org \
    --cc=ak@tempesta-tech.com \
    --cc=bcodding@redhat.com \
    --cc=borisp@nvidia.com \
    --cc=chuck.lever@oracle.com \
    --cc=dev@openvswitch.org \
    --cc=hare@suse.de \
    --cc=kuba@kernel.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=netdev@vger.kernel.org \
    --cc=sagi@grimberg.me \
    --cc=simo@redhat.com \
    --subject='Re: [ovs-dev] [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.