Date: Fri, 22 May 2020 22:16:51 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: John Baldwin <jhb@FreeBSD.org>, "freebsd-current@FreeBSD.org" <freebsd-current@FreeBSD.org> Subject: Re: RFC: merging nfs-over-tls changes into head/sys Message-ID: <QB1PR01MB3649268D28BE4F5CB860F0ADDDB40@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <6387cc78-c483-6271-7108-bf19a935dc01@FreeBSD.org> References: <QB1PR01MB36494A667E54EC90C07F97DBDDB70@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM>, <6387cc78-c483-6271-7108-bf19a935dc01@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote:=0A= >On 5/21/20 2:01 PM, Rick Macklem wrote:=0A= >> Hi,=0A= >>=0A= >> I have now completed changes to the code in projects/nfs-over-tls, which= =0A= >> implements TLS encryption of NFS RPC messages. (This roughly conforms=0A= >> to the internet draft "Towards Remote Procedure Call Encryption By Defau= lt",=0A= >> which should soon become an RFC. For now, TLS1.2 is used instead of TLS1= .3,=0A= >> since FreeBSD's KERN_TLS does not yet implement TLS1.3.)=0A= >>=0A= >> I'd like to start merging some of the kernel changes into head/sys.=0A= >>=0A= >> The first of these would be creation of the syscall used by the daemons.= =0A= >> (The code in projects/nfs-over-tls cheats and uses the syscall for the g= ssd,=0A= >> but it needs to have its own syscall so that the gssd daemon can run co= ncurrently=0A= >> with it. I didn't want testers to need to build userland just to get a = syscall stub=0A= >> in libc.)=0A= >>=0A= >> After this, there are a bunch of changes to the NFS code to add support = for=0A= >> ext_pgs mbufs (these are significant patches, but should not affect the= =0A= >> non-ext_pgs mbuf case, since they'll be conditional on ND_EXTPGS/M_EXTPG= S).=0A= >>=0A= >> Does this sound ok to do?=0A= >>=0A= >> Please let me know if you see problems with me doing this?=0A= >=0A= >I don't see any problems, per se, but I still need to do some changes on m= y=0A= >end for software KTLS RX before it's ready to merge (I'm hoping to kill=0A= >the iovecs in the kthreads entirely).=0A= Sure. My plan is to merge bits and pieces, because some of it involves part= s=0A= of the system like mount exports or changes to soreceive_generic(),=0A= that will require reviews.=0A= =0A= To be honest, most of the changes are not specifically nfs-over-tls (or=0A= krpc-over-tls, although NFS is currently the only consumer).=0A= They are things like generating ext_pgs mbuf lists (which can be used for= =0A= non-TLS connections, although I'm not sure they are useful for other cases?= )=0A= or a better way of handling the krpc client side receive.=0A= =0A= I think it will be quite a while before all the kernel bits are in head, bu= t having=0A= the syscall in head (mainly the syscall stub in libc) will make it easier f= or=0A= testers to set systems up. They may not be FreeBSD types.=0A= =0A= No rush on the TLS changes from my perspective. (It would be nice to get=0A= the kernel bits in FreeBSD13. The userland stuff could probably become a=0A= package/port, I think?=0A= =0A= Thanks yet again, for your help with this, rick=0A= =0A= =0A= --=0A= John Baldwin=0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?QB1PR01MB3649268D28BE4F5CB860F0ADDDB40>