#
1a878807 |
|
02-Nov-2023 |
Rick Macklem <rmacklem@FreeBSD.org> |
krpc: Display stats of TLS usage This patch adds some sysctls: kern.rpc.unenc.tx_msgcnt kern.rpc.unenc.tx_msgbytes kern.rpc.unenc.rx_msgcnt kern.rpc.unenc.rx_msgbytes kern.rpc.tls.tx_msgcnt kern.rpc.tls.tx_msgbytes kern.rpc.tls.rx_msgcnt kern.rpc.tls.rx_msgbytes kern.rpc.tls.handshake_success kern.rpc.tls.handshake_failed kern.rpc.tls.alerts which allow a NFS server sysadmin to determine how much NFS-over-TLS is being used. A large number of failed handshakes might also indicate an NFS confirguration problem. This patch moves the definition of "kern.rpc" from the kgssapi module to the krpc module. As such, both modules need to be rebuilt from sources. Since __FreeBSD_version was bumped yesterday, I will not bump it again. Suggested by: gwollman Discussed on: freebsd-current MFC after: 1 month
|
#
685dc743 |
|
16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .c pattern Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
#
4d846d26 |
|
10-May-2023 |
Warner Losh <imp@FreeBSD.org> |
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause. Discussed with: pfg MFC After: 3 days Sponsored by: Netflix
|
#
ef6fcc5e |
|
20-Feb-2023 |
Rick Macklem <rmacklem@FreeBSD.org> |
nfsd: Add VNET_SYSUNINIT() macros for vnet cleanup Commit ed03776ca7f4 enabled the vnet front end macros. As such, for kernels built with the VIMAGE option will malloc data and initialize locks on a per-vnet basis, typically via a VNET_SYSINIT(). This patch adds VNET_SYSUNINIT() macros to do the frees of the per-vnet malloc'd data and destroys of per-vnet locks. It also removes the mtx_lock/mtx_unlock calls from nfsrvd_cleancache(), since they are not needed. Discussed with: bz, jamie MFC after: 3 months
|
#
ed03776c |
|
18-Feb-2023 |
Rick Macklem <rmacklem@FreeBSD.org> |
nfsd: Enable the NFSD_VNET vnet front end macros Several commits have added front end macros for the vnet macros to the NFS server, krpc and kgssapi. These macros are now null, but this patch changes them to front end the vnet macros. With this commit, many global variables in the code become vnet'd, so that nfsd(8), nfsuserd(8), rpc.tlsservd(8) and gssd(8) can run in a vnet prison, once enabled. To run the NFS server in a vnet prison still requires a couple of patches (in D37741 and D38371) that allow mountd(8) to export file systems from within a vnet prison. Once these are committed to main, a small patch to kern_jail.c allowing "allow.nfsd" without VNET_NFSD defined will allow the NFS server to run in a vnet prison. One area that still needs to be settled is cleanup when a prison is removed. Without this, everything should work except there will be a leak of malloc'd data and mutex locks when a vnet prison is removed. MFC after: 3 months
|
#
6444662a |
|
15-Feb-2023 |
Rick Macklem <rmacklem@FreeBSD.org> |
krpc: Add macros so that rpc.tlsservd can run in vnet prison Commit 7344856e3a6d added a lot of macros that will front end vnet macros so that nfsd(8) can run in vnet prison. This patch adds similar macros named KRPC_VNETxxx so that the rpc.tlsservd(8) daemon can run in a vnet prison, once the macros front end the vnet ones. For now, they are null macros. MFC after: 3 months
|
#
564ed8e8 |
|
22-Aug-2022 |
Rick Macklem <rmacklem@FreeBSD.org> |
nfsd: Allow multiple instances of rpc.tlsservd During a discussion with someone working on NFS-over-TLS for a non-FreeBSD platform, we agreed that a single server daemon for TLS handshakes could become a bottleneck when an NFS server first boots, if many concurrent NFS-over-TLS connections are attempted. This patch modifies the kernel RPC code so that it can handle multiple rpc.tlsservd daemons. A separate commit currently under review as D35886 for the rpc.tlsservd daemon.
|
#
fcaa890c |
|
16-Nov-2021 |
Mark Johnston <markj@FreeBSD.org> |
mbuf: Only allow extpg mbufs if the system has a direct map Some upcoming changes will modify software checksum routines like in_cksum() to operate using m_apply(), which uses the direct map to access packet data for unmapped mbufs. This approach of course does not work on platforms without a direct map, so we have to disallow the use of unmapped mbufs on such platforms. I believe this is the right tradeoff: we only configure KTLS on amd64 and arm64 today (and one KTLS consumer, NFS TLS, requires a direct map already), and the use of unmapped mbufs with plain sendfile is a recent optimization. If need be, m_apply() could be modified to create CPU-private mappings of extpg mbuf pages as a fallback. So, change mb_use_ext_pgs to be hard-wired to zero on systems without a direct map. Note that PMAP_HAS_DMAP is not a compile-time constant on some systems, so the default value of mb_use_ext_pgs has to be determined during boot. Reviewed by: jhb Discussed with: gallatin MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D32940
|
#
f6dc363f |
|
12-Jan-2021 |
Rick Macklem <rmacklem@FreeBSD.org> |
nfs-over-tls: handle res.gid.gid_val correctly for memory allocation When the server side nfs-over-tls does an upcall to rpc.tlsservd(8) for the handshake and the rpc.tlsservd "-u" command line option has been specified, a list of gids may be returned. The list will be returned in malloc'd memory pointed to by res.gid.gid_val. To ensure the malloc occurs, res.gid.gid_val must be NULL before the call. Then, the malloc'd memory needs to be free'd. mem_free() just calls free(9), so a NULL pointer argument is fine and a length argument == 0 is ok, since the "len" argument is not used. This bug would have only affected nfs-over-tls and only when rpc.tlsservd(8) is running with the "-u" command line option.
|
#
665b1365 |
|
21-Dec-2020 |
Rick Macklem <rmacklem@FreeBSD.org> |
Add a new "tlscertname" NFS mount option. When using NFS-over-TLS, an NFS client can optionally provide an X.509 certificate to the server during the TLS handshake. For some situations, such as different NFS servers or different certificates being mapped to different user credentials on the NFS server, there may be a need for different mounts to provide different certificates. This new mount option called "tlscertname" may be used to specify a non-default certificate be provided. This alernate certificate will be stored in /etc/rpc.tlsclntd in a file with a name based on what is provided by this mount option.
|
#
51bb2fcc |
|
03-Sep-2020 |
Mitchell Horne <mhorne@FreeBSD.org> |
Remove a duplicate declaration This is already declared in sys/file.h, which is included directly. Compiling with GCC9 emits an error. Discussed with: rmacklem
|
#
ab0c29af |
|
21-Aug-2020 |
Rick Macklem <rmacklem@FreeBSD.org> |
Add TLS support to the kernel RPC. An internet draft titled "Towards Remote Procedure Call Encryption By Default" describes how TLS is to be used for Sun RPC, with NFS as an intended use case. This patch adds client and server support for this to the kernel RPC, using KERN_TLS and upcalls to daemons for the handshake, peer reset and other non-application data record cases. The upcalls to the daemons use three fields to uniquely identify the TCP connection. They are the time.tv_sec, time.tv_usec of the connection establshment, plus a 64bit sequence number. The time fields avoid problems with re-use of the sequence number after a daemon restart. For the server side, once a Null RPC with AUTH_TLS is received, kernel reception on the socket is blocked and an upcall to the rpctlssd(8) daemon is done to perform the TLS handshake. Upon completion, the completion status of the handshake is stored in xp_tls as flag bits and the reply to the Null RPC is sent. For the client, if CLSET_TLS has been set, a new TCP connection will send the Null RPC with AUTH_TLS to initiate the handshake. The client kernel RPC code will then block kernel I/O on the socket and do an upcall to the rpctlscd(8) daemon to perform the handshake. If the upcall is successful, ct_rcvstate will be maintained to indicate if/when an upcall is being done. If non-application data records are received, the code does an upcall to the appropriate daemon, which will do a SSL_read() of 0 length to handle the record(s). When the socket is being shut down, upcalls are done to the daemons, so that they can perform SSL_shutdown() calls to perform the "peer reset". The rpctlssd(8) and rpctlscd(8) daemons require a patched version of the openssl library and, as such, will not be committed to head at this time. Although the changes done by this patch are fairly numerous, there should be no semantics change to the kernel RPC at this time. A future commit to the NFS code will optionally enable use of TLS for NFS.
|