netdev - Re: [PATCH v5 3/3] NFSD: convert write

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: Thu, 30 Nov 2023 13:34:40 -0500
From: Chuck Lever <chuck.lever@...cle.com>
To: Jeff Layton <jlayton@...nel.org>
Cc: Lorenzo Bianconi <lorenzo@...nel.org>, linux-nfs@...r.kernel.org,
        lorenzo.bianconi@...hat.com, neilb@...e.de, netdev@...r.kernel.org,
        kuba@...nel.org
Subject: Re: [PATCH v5 3/3] NFSD: convert write_ports to netlink command

On Thu, Nov 30, 2023 at 01:01:14PM -0500, Jeff Layton wrote:
> On Thu, 2023-11-30 at 12:39 -0500, Chuck Lever wrote:
> > On Thu, Nov 30, 2023 at 11:55:29AM -0500, Jeff Layton wrote:
> > > On Thu, 2023-11-30 at 11:22 -0500, Jeff Layton wrote:
> > > > On Thu, 2023-11-30 at 10:57 +0100, Lorenzo Bianconi wrote:
> > > > > > > 
> > > > > > > +/* ============== NFSD_CMD_LISTENER_START ============== */
> > > > > > > +/* NFSD_CMD_LISTENER_START - do */
> > > > > > > +struct nfsd_listener_start_req {
> > > > > > > +	struct {
> > > > > > > +		__u32 transport_name_len;
> > > > > > > +		__u32 port:1;
> > > > > > > +	} _present;
> > > > > > > +
> > > > > > > +	char *transport_name;
> > > > > > > +	__u32 port;
> > > > > > > +};
> > > > > > 
> > > > > > How do you deconfigure a listener with this interface? i.e. suppose I
> > > > > > want to stop nfsd from listening on a particular port? I think this too
> > > > > > is a place where a declarative interface would be better:
> > > > > 
> > > > > Is it possible with current APIs? as for 2/3 so far I have just added netlink
> > > > > counter for current implementation but I am fine to change the logic here to
> > > > > better APIs.
> > > > > 
> > > > > > 
> > > > 
> > > > No, I don't think you can do this with the current API at all. I
> > > > consider it a major deficiency. I don't think we want to repeat that
> > > > mistake in the new interface.
> > > > 
> > > > > > Have userland send down a list of the ports that we should currently be
> > > > > > listening on, and let the kernel do the work to match the request. Again
> > > > > > too, an empty list could mean "close everything".
> > > 
> > > Another thought: should this interface also report and allow you to
> > > specify the address to listen on?
> > > 
> > > When the write_ports interface was first created, it lacked a field for
> > > the address to listen on. Later we added a way to just hand off a socket
> > > to the kernel to pass that info.
> > > 
> > > I think it's possible today to send down a socket that only listens on a
> > > particular address, and you have no real way to tell that with the
> > > current "ports" file.
> > 
> > All agreed, but listening on a particular address isn't something we
> > need today. (Or is it?)
> 
> It is for TCP/UDP -- see the -H option to rpc.nfsd.
> 
> > Does the socket-passing thing work for non socket-based transports
> > like RDMA? I would think that mechanism is legacy.
> 
> To the contrary actually. rpc.nfsd almost always does this today unless
> you're configuring rdma. But, that was just a convenient way to do this
> with a fd based interface.
> 
> I think with netlink, we just want to send down a list of
> (transport_name, sockaddr) pairs and let the kernel open and close the
> appropriate sockets. For RDMA, we can just fill out the sa_port field
> and ignore the rest.

Agreed, it would be cleaner to handle all transport classes the same
way and eventually deprecate the fd-passing mechanism.


> > > Should we instead plumb a complete struct sockaddr_storage (or some
> > > other suitable address structure) into this interface?
> > 
> > How difficult would it be to add this later, when we actually have a
> > specific use case?
> 
> I think we have one now. rpc.nfsd passes down sockets to the kernel for
> TCP and UDP listeners, so we need a way to send down a complete sockaddr
> for the listeners.

If we have a usage scenario, then it makes sense to try it now.


-- 
Chuck Lever