From owner-freebsd-net@freebsd.org Sat Mar 2 02:25:35 2019 Return-Path: <owner-freebsd-net@freebsd.org> Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85059150C1C3 for <freebsd-net@mailman.ysv.freebsd.org>; Sat, 2 Mar 2019 02:25:35 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (mx-int.allbsd.org [IPv6:2001:2f0:104:e002::7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.allbsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E289F6FFFA; Sat, 2 Mar 2019 02:25:34 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail-d.allbsd.org (p2452109-ipngn10801funabasi.chiba.ocn.ne.jp [180.13.106.109]) (authenticated bits=56) by mail.allbsd.org (8.15.2/8.15.2) with ESMTPSA id x222P39O058414 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) (Client CN "/CN=mail.allbsd.org", Issuer "/C=US/O=Let's+20Encrypt/CN=Let's+20Encrypt+20Authority+20X3"); Sat, 2 Mar 2019 11:25:18 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from alph.d.allbsd.org (alph.allbsd.org [192.168.0.10]) by mail-d.allbsd.org (8.15.2/8.15.2) with ESMTPS id x222P3mT065088 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 2 Mar 2019 11:25:03 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [[UNIX: localhost]]) (authenticated bits=0) by alph.d.allbsd.org (8.15.2/8.15.2) with ESMTPA id x222Ojfa065063; Sat, 2 Mar 2019 11:24:47 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sat, 02 Mar 2019 11:23:07 +0900 (JST) Message-Id: <20190302.112307.506661729975878277.hrs@allbsd.org> To: rmacklem@uoguelph.ca Cc: freebsd-rwg@pdx.rh.CN85.dnsmgr.net, freebsd-net@freebsd.org, bz@FreeBSD.org, rgrimes@freebsd.org Subject: Re: use of #ifdef INET and #ifdef INET6 in the kernel sources From: Hiroki Sato <hrs@FreeBSD.org> In-Reply-To: <QB1PR01MB35375F4B5EC31BBCEBF1C7CCDD770@QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM> References: <201903011219.x21CJkIE061223@pdx.rh.CN85.dnsmgr.net> <QB1PR01MB35377AFB9049AF35F5A3037CDD760@QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM> <QB1PR01MB35375F4B5EC31BBCEBF1C7CCDD770@QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.8 on Emacs 25.3 Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sat_Mar__2_11_23_07_2019_942)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.6.2 (mail.allbsd.org [133.31.130.41]); Sat, 02 Mar 2019 11:25:25 +0900 (JST) X-Spam-Status: No, score=-97.4 required=13.0 tests=CONTENT_TYPE_PRESENT, QENCPTR1,UNPARSEABLE_RELAY,URIBL_SC2_SURBL,URIBL_XS_SURBL, USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mx.allbsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>, <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/> List-Post: <mailto:freebsd-net@freebsd.org> List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>, <mailto:freebsd-net-request@freebsd.org?subject=subscribe> X-List-Received-Date: Sat, 02 Mar 2019 02:25:35 -0000 ----Security_Multipart(Sat_Mar__2_11_23_07_2019_942)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rick Macklem <rmacklem@uoguelph.ca> wrote in <QB1PR01MB35375F4B5EC31BBCEBF1C7CCDD770@QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM>: rm> Rick Macklem wrote: rm> [stuff snipped] rm> >The AF_LOCAL code was in head for a short period of time before a vnode lock panic() rm> >issue was reported and I reverted the patch. rm> > rm> >Here is the commit log message for that reversion: rm> >PR#230752 shows a panic where an nfsd thread tries to do soconnect() on rm> >the AF_LOCAL socket used by the nfsuserd while already holding an rm> >exclusive lock on it. I am not 100% sure how this happens, but since an rm> >AF_LOCAL socket is in the file system namespace it is conceivable that it rm> >could lock it and then attempt an upcall to the nfsuserd. rm> >However, reverting r320757 stops the nfsuserd from using an AF_LOCAL rm> >socket, so it should avoid any such panic(). rm> >r320757 did fix a problem with running the nfsuserd when jails were rm> >enabled, but that can be dealt with less elegantly by allowing the rm> >use of an alternate address instead of 127.0.0.1. rm> >The gssd daemon also uses an AF_LOCAL socket, but it will do upcalls rm> >before the nfsd thread processes the RPC, so I think it should not rm> >be suseptible to this problem. rm> rm> Oops. Duh. I should have read my own commit message more carefully... rm> It was an nfsd thread, so the file system wasn't an NFS mount, it was a file rm> system exported to NFS client(s). rm> rm> It is possible to test to see if a file system is exported, but that can change rm> at any time, so even if it isn't exported when the nfsuserd daemon is started, rm> it could be exported later. rm> rm> So, I don't see any way AF_LOCAL can be safely used here. rm> rm> Oh, and the kernel RPC expects to be able to do a soconnect() using a rm> sockaddr, so socketpair() won't do the trick. Thank you for your clarification. I agree that AF_INET/AF_INET6 loopback address is much easier to avoid file system dependency. For the original question about whether we should use a hard-coded address or not, my suggestion is that we do not need to use the name "localhost" or rely on any Internet domain resolver code such as DNS as long as the hard-coded addresses cover all of supported address families (we have only two in practice). However, an option to specify a loopback address to be used might mitigate multiple loopback address issues in classical jail w/o VNET or multiple supported address families. Is there any problem with using NFSSVC_NFSUSERDPORT to pass a struct sockaddr (i.e. udptransp->xp_ltaddr, not only xp_port) directly? I think checking on kernel side if (sa_family == AF_INET or AF_INET6) and the address is already bound before the newfs_connect() call in nfsrv_nfsuserdport() guarantee that the specified sockaddr is a loopback address. Anyway, we might want to have AF_LOCAL socket with namespace which does not depend on any file system to communicate between kernel and userland. Linux has it for a long time (by putting '\0' at the head of an AF_LOCAL address) while I am still not sure if this is the best way to implement. While a new protocol family (PF_KEY is used in IPsec for example) also works for this purpose, it is probably a sledgehammer to crack a nut. -- Hiroki ----Security_Multipart(Sat_Mar__2_11_23_07_2019_942)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iEYEABECAAYFAlx56QsACgkQTyzT2CeTzy1fowCdH+oucHSs2UMFur6QXg7bTOpU Hy8AnRRGvQLsZtoyVzXM+Hw2BovZkNwB =ZuZC -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Mar__2_11_23_07_2019_942)----