RFC: merging nfs-over-tls changes into head/sys

[Rick Macklem]

John Baldwin wrote:
>On 5/21/20 2:01 PM, Rick Macklem wrote:
>> Hi,
>>
>> I have now completed changes to the code in projects/nfs-over-tls, which
>> implements TLS encryption of NFS RPC messages. (This roughly conforms
>> to the internet draft "Towards Remote Procedure Call Encryption By Default",
>> which should soon become an RFC. For now, TLS1.2 is used instead of TLS1.3,
>> since FreeBSD's KERN_TLS does not yet implement TLS1.3.)
>>
>> I'd like to start merging some of the kernel changes into head/sys.
>>
>> The first of these would be creation of the syscall used by the daemons.
>> (The code in projects/nfs-over-tls cheats and uses the syscall for the gssd,
>>  but it needs to have its own syscall so that the gssd daemon can run concurrently
>>  with it. I didn't want testers to need to build userland just to get a syscall stub
>>  in libc.)
>>
>> After this, there are a bunch of changes to the NFS code to add support for
>> ext_pgs mbufs (these are significant patches, but should not affect the
>> non-ext_pgs mbuf case, since they'll be conditional on ND_EXTPGS/M_EXTPGS).
>>
>> Does this sound ok to do?
>>
>> Please let me know if you see problems with me doing this?
>
>I don't see any problems, per se, but I still need to do some changes on my
>end for software KTLS RX before it's ready to merge (I'm hoping to kill
>the iovecs in the kthreads entirely).
Sure. My plan is to merge bits and pieces, because some of it involves parts
of the system like mount exports or changes to soreceive_generic(),
that will require reviews.

To be honest, most of the changes are not specifically nfs-over-tls (or
krpc-over-tls, although NFS is currently the only consumer).
They are things like generating ext_pgs mbuf lists (which can be used for
non-TLS connections, although I'm not sure they are useful for other cases?)
or a better way of handling the krpc client side receive.

I think it will be quite a while before all the kernel bits are in head, but having
the syscall in head (mainly the syscall stub in libc) will make it easier for
testers to set systems up. They may not be FreeBSD types.

No rush on the TLS changes from my perspective. (It would be nice to get
the kernel bits in FreeBSD13. The userland stuff could probably become a
package/port, I think?

Thanks yet again, for your help with this, rick


--
John Baldwin