aboutsummaryrefslogtreecommitdiff
path: root/sys/rpc
Commit message (Collapse)AuthorAgeFilesLines
* rpc/xdr.h: make xdrproc_t always take two argumentsBrooks Davis13 days1-8/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The type of xdrproc_t is clearly defined in the comments as a function with two arguments, an XDR * and a void * (sometimes spelled caddr_t). It was initialy defined as: typedef bool_t (*xdrproc_t)(); At some point people started giving it a non-empty argument list. Unfortunatly, there has been widespread disagreement about how arguments are passed. There seems to have been a widespread view that it should be allowed to pass three argument function pointer to xdrproc_t. Most notable is xdr_string which takes a maximum length parameter. This lead to all sorts of prototypes (all of which have been present in the FreeBSD source tree): FreeBSD userspace (nominally from tirpc, but seemingly local): typedef bool_t (*xdrproc_t)(XDR *, ...); FreeBSD kernel, glibc: typedef bool_t (*xdrproc_t)(XDR *, void *, ...); rcp/xdr.h with _KERNEL defined (not used?): typedef bool_t (*xdrproc_t)(XDR *, void *, u_int); gssrpc (in krb5) and Linux kernel: typedef bool_t (*xdrproc_t)(XDR *, void *); For two argument functions on current ABIs, these all equivalent as these arguments are passed in registers regardless of decleration and definition, but we end up with two problems: - xdr_free((xdrproc_t)xdr_string, ...) calls xdr_string with no third argument and (at least on FreeBSD) may fail to free memory if the string is shorter than the value lying around in the third argument register. There are no instance of this in tree, but I found some with Debian code search, in particular in OpenAFS. - Under CheriABI, variadic arguments are passed in a separate, bounded array so theses prototypes aren't equilvalent to the non-variadic calling convention of the functions. The reality is that that xdr_string should not be cast to xdrproc_t and xdr_wrapstring should be used instead so we do not need to support this case. Instances of the former behavior are now extremely rare. With this change we bring FreeBSD in line with gssrpc and the Linux Kernel. Warnings about casts should now be correct and should be fixed. Bump __FreeBSD_version as some software required adaptation if it is declaring functions to cast to xdrproc_t. Update OpenZFS's workaround of this historic mess accordingly. Effort: CHERI upstreaming Sponsored by: Innovate UK Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D54824
* rpctls_impl.c: Use a direct cast to uintptr_t instead of __DECONSTJohn Baldwin2026-01-211-1/+1
| | | | | | | | | | | | | | | This fixes the build on CHERI architectures where the compiler warns about a direct cast between uint64_t and const void * inside of __DECONST. However, GCC would also complain about this on 32-bit kernels due to uint64_t not being the same size as a pointer. Also, a direct cast to uintptr_t to right-size the cookie value is more direct than using __DECONST given that there is no "const" pointer involved in the expression. Reviewed by: brooks, glebius Obtained from: CheriBSD Sponsored by: AFRL, DARPA Differential Revision: https://reviews.freebsd.org/D54797
* sys/rpc: UNIX auth: Do not log on bogus AUTH_SYS messagesOlivier Certner2025-10-141-17/+3
| | | | | | | | | | | | | | Remove the printf() stances added in commit d4cc791f3b2e ("sys/rpc: UNIX auth: Fix OOB reads on too short message"). Even if it can be helpful to know why an authentication message is rejected, printing explanatory messages on each request attempt is a remote log filler that could be triggered by accident, and the generic RPC code generally does not do that. These printf() calls should be restored only after some limiting or configuration mechanism is devised. MFC with: d4cc791f3b2e ("sys/rpc: UNIX auth: Fix OOB reads on too short message") Sponsored by: The FreeBSD Foundation
* sys/rpc: UNIX auth: Style: Remove unnecessary headers, minor changesOlivier Certner2025-10-142-10/+4
| | | | | MFC after: 2 days Sponsored by: The FreeBSD Foundation
* sys/rpc: UNIX auth: Support XDR_FREEOlivier Certner2025-10-141-0/+4
| | | | | | | | | | | | | xdr_authunix_parms() does not allocate any auxiliary memory, so we can simply support XDR_FREE by just returning TRUE. Although there are currently no callers passing XDR_FREE, this makes us immune to such a change in a way that doesn't cost more but is more constructive than a mere KASSERT(). Suggested by: rmacklem MFC after: 2 days Sponsored by: The FreeBSD Foundation
* sys/rpc: UNIX auth: Fix OOB reads on too short messageOlivier Certner2025-10-141-39/+60
| | | | | | | | | | | | | | | | | | | | | In the inline version (_svcauth_unix()), fix multiple possible OOB reads when the credentials part of a request is too short to contain mandatory fields or with respect to the hostname length or number of groups it advertises. The previously existing check was arriving too late and relied on possibly wrong data coming from earlier OOB reads. While here, use 'uint32_t' as the length/size type, as it is more than enough and removes the need for conversions, explicit or implicit. While here, factor out setting 'stat' to AUTH_BADCRED and then jumping to 'done' on error, through the new 'badcred' label. While here, through comments, refer to what the non-inline version is doing (xdr_authunix_parms() in 'authunix_prot.c') and the reasons. Reviewed by: rmacklem Fixes: dfdcada31e79 ("Add the new kernel-mode NFS Lock Manager.") MFC after: 2 days Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D52964
* sys/rpc: UNIX auth: Use AUTH_SYS_MAX_{GROUPS,HOSTNAME} as limits (2/2)Olivier Certner2025-10-141-5/+2
| | | | | | | | | | Remove local defines from 'svc_auth_unix.c' and use the new limit macros instead. Reviewed by: rmacklem MFC after: 2 days Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D52963
* sys/rpc: UNIX auth: Use AUTH_SYS_MAX_{GROUPS,HOSTNAME} as limits (1/2)Olivier Certner2025-10-141-10/+23
| | | | | | | | | | | | | | | | | | | Consistently with the XDR_INLINE() variant of xdr_authunix_parms() (_svcauth_unix() in 'svc_auth_unix.c'), reject messages with credentials having a machine name length in excess of AUTH_SYS_MAX_HOSTNAME or more than AUTH_SYS_MAX_GROUPS supplementary groups, which do not conform to RFC 5531. This is done mainly because we cannot store excess groups anyway, even if at odds with the robustness principle ("be liberal in what you accept"). While here, make sure the current code is immune to AUTH_SYS_MAX_GROUPS changing value (in future RFCs?) even if that seems improbable. Reviewed by: rmacklem Fixes: dfdcada31e79 ("Add the new kernel-mode NFS Lock Manager.") MFC after: 2 days Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D52962
* sys/rpc: Define AUTH_SYS_MAX_{GROUPS,HOSTNAME}Olivier Certner2025-10-141-0/+4
| | | | | | | | | | | | | As, respectively, the maximum number of "supplementary" groups and the maximum hostname size allowed in the credentials structure for AUTH_SYS (aka, AUTH_UNIX). Will be used in subsequent commits. Reviewed by: rmacklem MFC after: 2 days Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D52961
* sys/rpc: UNIX auth: Fix OOB accesses, notably writes on decodeOlivier Certner2025-10-141-19/+21
| | | | | | | | | | | | | | | | | When the received authentication message had more than XU_NGROUPS, we would write group IDs beyond the end of cr_groups[] in the 'struct xucred' being filled (as 'ngroups_max' is always greater than XU_NGROUPS). For robustness, prevent various OOB accesses that would result from a change of value of XU_NGROUPS or a 'struct xucred' with an invalid 'cr_ngroups' field, even if these cases are unlikely. Reviewed by: rmacklem Fixes: dfdcada31e79 ("Add the new kernel-mode NFS Lock Manager.") MFC after: 2 days Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D52960
* sys/rpc: UNIX auth: Rename 'ngroups' => 'supp_ngroups' for clarityOlivier Certner2025-10-142-16/+16
| | | | | MFC after: 2 days Sponsored by: The FreeBSD Foundation
* Revert "Remove Secure RPC DES authentication"Lexi Winter2025-08-151-0/+26
| | | | | | This reverts commit 7ac276298b72982189ac1a5b17461936dc00163e. Requested by: kib
* Remove Secure RPC DES authenticationLexi Winter2025-08-101-26/+0
| | | | | | | | | | | | | | | | | | | Following the earlier removal of keyserv, none of this functionality works since it requires keyserv. Remove the relevant symbols from libc's Symbol.map. Leave compatibility symbols for existing applications, but since the functions don't work without keyserv, stub them out to return an error. Remove some private symbols that were only used by keyserv; these don't get compatibility symbols. Remove the documentation for the old functions. Remove rpc.ypupdated since it requires DES authentication. Reviewed by: manu, des, emaste Differential Revision: https://reviews.freebsd.org/D50442
* rpcsec_gss: Rename KRBIMP_HESIOD1 to KRBIMP_HEIMDALV1Rick Macklem2025-08-093-3/+3
| | | | | | | | | | | This was a weird brain fart. Long ago I used a directory service called Hesiod, which was written by MIT. For some inexplicable reason, I used that name instead of Heimdal. This patch replaces the name with a Heimdal one. Suggested by: bjk Fixes: e3ac01e18eb3 ("kgssapi: Fix the kgssapi so that it can use MIT Kerberos")
* kgssapi: Fix the kgssapi so that it can use MIT KerberosRick Macklem2025-08-073-42/+136
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Without this patch, the kgssapi uses detailed knowledge of the internal context structure for Heimdal (up to vers 1.5). It also does four upcalls to the gssd daemon to establish a server side RPCSEC_GSS context. This patch adds support for three new upcalls: gss_init_sec_context_lucid_v1() gss_accept_sec_context_lucid_v1() gss_supports_lucid() These are used to determine if the gssd can do the upcalls and uses them to avoid needing detailed Heimdal knowledge if they are supported. gss_init_sec_context_lucid_v1() and gss_accept_sec_context_lucid_v1() return the information needed to complete the RPCSEC_GSS context. They use gss_krb5_export_lucid_sec_context() to acquire the information from the libraries. (MIT Kerberos supports this and I believe newer versions of Heimdal does, as well). This avoids the need for detailed knowledge about MIT's internals and replaces the 2 or 4 (initiator or acceptor) upcalls with a single upcall to create the RPCSEC_GSS context. The old Heimdal (up to 1.5) support is left intact, but should be removed whenever Heimdal 1.5 is removed from /usr/src. It also modifies the Makefile so that the gssd is only built when MK_KERBEROS_SUPPORT != "no", since it is useless without Kerberos. Reviewed by: cy Differeential Revision: https://reviews.freebsd.org/D51731 Differeential Revision: https://reviews.freebsd.org/D51733
* Revert "kgssapi: Fix the kgssapi so that it can use MIT Kerberos"Rick Macklem2025-08-073-136/+42
| | | | | | This broke the build and will have to wait for cy@'s commit. This reverts commit 554651ebf1c1798fa8fb2560cab761ac3d219555.
* kgssapi: Fix the kgssapi so that it can use MIT KerberosRick Macklem2025-08-063-42/+136
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Without this patch, the kgssapi uses detailed knowledge of the internal context structure for Heimdal (up to vers 1.5). It also does four upcalls to the gssd daemon to establish a server side RPCSEC_GSS context. This patch adds support for three new upcalls: gss_init_sec_context_lucid_v1() gss_accept_sec_context_lucid_v1() gss_supports_lucid() These are used to determine if the gssd can do the upcalls and uses them to avoid needing detailed Heimdal knowledge if they are supported. gss_init_sec_context_lucid_v1() and gss_accept_sec_context_lucid_v1() return the information needed to complete the RPCSEC_GSS context. They use gss_krb5_export_lucid_sec_context() to acquire the information from the libraries. (MIT Kerberos supports this and I believe newer versions of Heimdal does, as well). This avoids the need for detailed knowledge about MIT's internals and replaces the 2 or 4 (initiator or acceptor) upcalls with a single upcall to create the RPCSEC_GSS context. The old Heimdal (up to 1.5) support is left intact, but should be removed whenever Heimdal 1.5 is removed from /usr/src. It also modifies the Makefile so that the gssd is only built when MK_KERBEROS_SUPPORT != "no", since it is useless without Kerberos. Reviewed by: cy Differential Revision: https://reviews.freebsd.org/D51731 Differential Revision: https://reviews.freebsd.org/D51733
* kern: rename crsetgroups_fallback, document it in ucred(9)Kyle Evans2025-08-012-3/+3
| | | | | | | | | | | | | | | | As of FreeBSD 15.0, crsetgroups() *only* sets supplementary groups, while crsetgroups_and_egid() will do both using an array of the same style that previous versions used for crsetgroups() -- i.e., the first element is the egid, and the remainder are supplementary groups. Unlike the previous iteration of crsetgroups(), crsetgroups_and_egid() is less prone to misuse as the caller must provide a default egid to use in case the array is empty. This is particularly useful for groups being set from data provided by userland. Reviewed by: olce Suggested by: olce Differential Revision: https://reviews.freebsd.org/D51647
* kern: start tracking cr_gid outside of cr_groups[]Kyle Evans2025-07-313-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the (mostly) kernel side of de-conflating cr_gid and the supplemental groups. The pre-existing behavior for getgroups() and setgroups() is retained to keep the user <-> kernel boundary functionally the same while we audit use of these syscalls, but we can remove a lot of the internal special-casing just by reorganizing ucred like this. struct xucred has been altered because the cr_gid macro becomes problematic if ucred has a real cr_gid member but xucred does not. Most notably, they both also have cr_groups[] members, so the definition means that we could easily have situations where we end up using the first supplemental group as the egid in some places. We really can't change the ABI of xucred, so instead we alias the first member to the `cr_gid` name and maintain the status quo. This also fixes the Linux setgroups(2)/getgroups(2) implementation to more cleanly preserve the group set, now that we don't need to special case cr_groups[0]. __FreeBSD_version bumped for the `struct ucred` ABI break. For relnotes: downstreams and out-of-tree modules absolutely must fix any references to cr_groups[0] in their code. These are almost exclusively incorrect in the new world, and cr_gid should be used instead. There is a cr_gid macro available in earlier FreeBSD versions that can be used to avoid having version-dependant conditionals to refer to the effective group id. Surrounding code may need adjusted if it peels off the first element of cr_groups and uses the others as the supplemental groups, since the supplemental groups start at cr_groups[0] now if &cr_groups[0] != &cr_gid. Relnotes: yes (see last paragraph) Co-authored-by: olce Differential Revision: https://reviews.freebsd.org/D51489
* kern: adopt the cr_gid macro for cr_groups[0] more widelyKyle Evans2025-07-242-4/+6
| | | | | | | | | | | | | | | | A future change may split cr_gid out of cr_groups[0] so that there's a cleaner separation between the supplemental groups and the effective group. Do the mechanical conversion where we can, and drop some comments where we need further work because some assumptions about cr_gid == cr_groups[0] have been made. This should not be a functional change, but downstreams and other out-of-tree code are advised to investigate their usage of cr_groups sooner rather than later, as a future change will render assumptions about these two being equivalent harmful. Reviewed by: asomers, kib, olce Differential Revision: https://reviews.freebsd.org/D51153
* rpcsec_gss.c: Avoid panics in clnt_nl_call()Rick Macklem2025-07-191-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | When rpc_gss_init() calls gssd upcall functions like gssd_import_name(), clnt_nl_call() gets calls. clnt_nl_call() requires that the currect vnet be set up. The calling sequence looks something like: rpc_gss_init()->gssd_import_name()->gssd_import_name_1()-> clnt_call_private()->clnt_nl_call() (The call to rpc_gss_init() can happen from various places, such as nfs_getauth() and clnt_vc_call().) rpc_gss_init() does not know what socket is being used for NFS client->server RPCs and may be called from various places when any VOP_xxx()->RPC call is made. As such, the calling thread might be running within a jail. However, the gssd upcalls for the NFS client must always be done to the gssd running outside of any jails. This patch sets the CURVNET to vnet0 in rpc_gss_init() to fix the problem, since that is the vnet that always should be used. This must somehow be changed if NFS mounts in vnet jails is enabled. Reviewed by: glebius Differential Revision: https://reviews.freebsd.org/D51086
* clnt_rc.c: Fix the case where a TLS handshake failsRick Macklem2025-07-191-1/+6
| | | | | | | | | | | | | | | | When a TLS handshake fails during a NFS-over-TLS mount attempt, the socket was left around because it needed to be dereferenced. The dereference was not happening in clnt_vc_destroy() because ct_closeit was not set to TRUE. This patch moves the code that sets ct_closeit to TRUE up to before the rpctls_connect() call, so that ct_closeit is set to TRUE if it fails and clnt_vc_destroy() will then dereference the socket. Reviewed by: glebius Differential Revision: https://reviews.freebsd.org/D51084
* rpctls_impl.c: Fix handling of hung rpc tls daemonRick Macklem2025-07-181-0/+8
| | | | | | | | | | | | | | | | | | | | Commit 26ee05939209 replaced soshutdown() with soclose() for the case where the RPC TLS daemon has not removed the socket from the RB tree during an upcall. It turns out that soshutdown() is needed for the "else" case, which is the case that occurs when the daemon is stuck in SSL_accept() or SSL_connect(). This patch adds a soshutdown() call to this else case, which unsticks the daemon when the other end does not do the actual TLS handshake. This can occur if the daemon is not running at the other end. Reviewed by: glebius Differential Revision: https://reviews.freebsd.org/D51083 Fixes: 26ee05939209 ("rpctls_impl.c: Fix handling of socket for daemon failure")
* rpctls_impl.c: Fix handling of socket for daemon failureRick Macklem2025-06-211-6/+10
| | | | | | | | | | | | | | | If the client side rpc.tlsclntd is not running when a NFS-over-TLS connection attempt is made, the socket is left open. This results in the rpc.tlsservd daemon on the NFS server being stuck in SSL_accept() until the daemon is restarted. This patch fixes this by doing soclose() on the socket for the cases where the daemon has not acquired the socket. Reviewed by: glebius Differential Revision: https://reviews.freebsd.org/D50961
* machine/stdarg.h -> sys/stdarg.hBrooks Davis2025-06-111-1/+1
| | | | | | | | | | | | | Switch to using sys/stdarg.h for va_list type and va_* builtins. Make an attempt to insert the include in a sensible place. Where style(9) was followed this is easy, where it was ignored, aim for the first block of sys/*.h headers and don't get too fussy or try to fix other style bugs. Reviewed by: imp Exp-run by: antoine (PR 286274) Pull Request: https://github.com/freebsd/freebsd-src/pull/1595
* krpc/clnt_nl: unregister the netlink group, when client is destroyedGleb Smirnoff2025-02-051-0/+1
|
* netlink: refactor KPI for generic Netlink modulesGleb Smirnoff2025-02-051-3/+2
| | | | | | | | | | | | | | | | Now that the family and group are completely private to netlink_generic.c, provide a simple and robust KPI, that would require very simple guarantees from both KPI and the module: * Strings are used only for family and group registration, that return ID: uint16_t genl_register_family(const char *name, ... uint32_t genl_register_group(uint16_t family, const char *name, ... * Once created families and groups are guaranteed to not disappear and be addressable by their ID. * All subsequent calls, including deregistration shall use ID. Reviewed by: kp Differential Revision: https://reviews.freebsd.org/D48845
* krpc/clnt_nl: filter RPC replies on vnetGleb Smirnoff2025-02-012-2/+16
| | | | | | | | RPC calls are filtered by the Netlink system itself, but the RPC replies are not. With legitimate use the chance of a xid collision is zero, since global clients use global atomically updated 32-bit counter for that. However, a malicious jail may blindly inject replies guessing the xid, where guessing is trivial. Protect against that checking the vnet, too.
* rpcsec_tls: do not create an RPC client per vnetGleb Smirnoff2025-02-011-36/+12
| | | | | | | | | A netlink RPC client should be global. The filtering of RPC calls is done by the nl_send_group() that would distribute the call to all subscribers in the curvnet of clnt_nl_call() context. Fixes: a3a6dc24f34a1b0522bd0dd8fcb6b84c69686251 Fixes: 42eec5201ab936f7227950c2c159c02c9cb342d4
* rpcsec_tls: cleanup the rpctls_syscall()Gleb Smirnoff2025-02-012-52/+50
| | | | | | | | | With all the recent changes we don't need extra argument that specifies what exactly the syscalls does, neither we need a copyout-able pointer, just a pointer sized integer. Reviewed by: rmacklem Differential Revision: https://reviews.freebsd.org/D48649
* rpc.tlsservd: provide parallelism with help of pthread(3)Gleb Smirnoff2025-02-011-3/+0
| | | | | | | | | | | | | | | | | | At normal NFS server runtime there is not much RPC traffic from kernel to rpc.tlsservd. But as Rick rmacklem@ explained, the notion of multiple workers exists to handle a situation when a server reboots and it has several hundred or thousands of TLS/TCP connections from clients. Once it comes back up, all the clients make TCP connections and do TLS handshakes. So cleanup the remnants of the workers, that left after the conversion of RPC over netlink(4) transport and restore desired parallelism with help of pthread(3). We are processing the TLS handshakes in separate threads, one per handshake. Number of concurrent threads is capped by hw.ncpu / 2, but this can be overriden with -N. Differential Revision: https://reviews.freebsd.org/D48570
* rpcsec_tls: merge RPC failure for rpctls_connect() and rpctls_server()Gleb Smirnoff2025-02-011-54/+46
| | | | | Reviewed by: rmacklem Differential Revision: https://reviews.freebsd.org/D48677
* rpcsec_tls/server: API refactoring between kernel and rpc.tlsservd(8)Gleb Smirnoff2025-02-015-57/+23
| | | | | | | | | | | | | | | | | Now that the conversion of rpcsec_tls/client + rpc.tlsclntd(8) to the netlink(4) socket as RPC transport started using kernel socket pointer as a reliable cookie, we can shave off quite a lot of complexity. We will utilize the same kernel-generated cookie in all RPCs. And the need for the daemon generated cookie in the form of timestamp+sequence vanishes. We also stop passing notion of 'process position' from userland to kernel. The TLS handshake parallelism to be reimplemented in the daemon without any awareness about that in the kernel. This time bump the RPC version. Reviewed by: rmacklem Differential Revision: https://reviews.freebsd.org/D48566
* rpcsec_tls/client: API refactoring between kernel and rpc.tlsclntd(8)Gleb Smirnoff2025-02-016-101/+67
| | | | | | | | | | | | | | | | | | | Now that the conversion of rpcsec_tls/client + rpc.tlsclntd(8) to the netlink(4) socket as RPC transport started using kernel socket pointer as a reliable cookie, we can shave off quite a lot of complexity. We will utilize the same kernel-generated cookie in all RPCs. And the need for the daemon generated cookie in the form of timestamp+sequence vanishes. In the clnt_vc.c we no longer need to store the userland cookie, but we still need to observe the TLS life cycle of the client. We observe RPCTLS_INHANDSHAKE state, that lives for a short time when the socket had already been fetched by the daemon with the syscall, but the RPC call is still waiting for the reply from daemon. This time bump the RPC version. Reviewed by: rmacklem Differential Revision: https://reviews.freebsd.org/D48564
* krpc: assert that we don't support kernel RPC over unix(4)Gleb Smirnoff2025-02-011-0/+3
| | | | | Reviewed by: rmacklem Differential Revision: https://reviews.freebsd.org/D48563
* rpcsec_tls/server: use netlink RPC client to talk to rpc.tlsservd(8)Gleb Smirnoff2025-02-013-302/+98
| | | | | | | | | | | | | | | | | The server part just repeats what had been done to the client. We trust the parallelism of clnt_nl and we pass socket cookie to the daemon, which we then expect to see in the rpctls_syscall(RPCTLS_SYSC_SRVSOCKET) to find the corresponding socket+xprt. We reuse the same database that is used for clients. Note 1: this will be optimized further in a separate commit. This one is made intentionally minimal, to ease the review process. Note 2: this change intentionally ignores aspect of multiple workers of rpc.tlsservd(8). This also will be addressed in a future commit. Reviewed by: rmacklem Differential Revision: https://reviews.freebsd.org/D48561
* rpcsec_tls/client: use netlink RPC client to talk to rpc.tlsclntd(8)Gleb Smirnoff2025-02-013-164/+96
| | | | | | | | | | | | | | | | | | | | | | In addition to using netlink(4) socket instead of unix(4) to pass rpctlscd_* RPC commands to rpc.tlsclntd(8), the logic of passing file descriptor is also changed. Since clnt_nl provides us all needed parallelism and waits on individual RPC xids, we don't need to store socket in a global variable and serialize all communication to the daemon. Instead, we will augment rpctlscd_connect arguments with a cookie that is basically a pointer to socket, that we keep for the daemon. While sleeping on the request, we will store a database of all sockets associated with rpctlscd_connect RPCs that we have sent to userland. The daemon then will send us back the cookie in the rpctls_syscall(RPCTLS_SYSC_CLSOCKET) argument and we will find and return the socket for this upcall. This will be optimized further in a separate commit, that will also touch clnt_vc.c and other krpc files. This commit is intentionally made minimal, so that it is easier to understand what changes with netlink(4) transport. Reviewed by: rmacklem Differential Revision: https://reviews.freebsd.org/D48559
* krpc: let the kernel talk to the rpcbind(8) service via netlink(4)Gleb Smirnoff2025-02-011-63/+10
| | | | | | | | | | At the moment the only kernel service that wants to register RPC binding in the rpcbind(8) is kernel NLM. Kernel counterpart of the previous commit. Reviewed by: rmacklem Differential Revision: https://reviews.freebsd.org/D48557
* krpc: add kernel side client over netlink(4)Gleb Smirnoff2025-02-015-1/+567
| | | | | | | | | | | | This shall be the official transport to connect kernel side RPC clients to userland side RPC servers. All current kernel side clients that hijack unix(4) sockets will be converted to it. Some implementation details are available inside new clnt_nl.c. The complementary RPC server over netlink(4) coming in next commit. Reviewed by: rmacklem Differential Revision: https://reviews.freebsd.org/D48549
* xdr: provide x_putmbuf method for kernel XDRGleb Smirnoff2025-02-017-20/+18
| | | | | | | | | Get it implemented for mbuf based XDR. Right now all existing consumers use only mbuf based XDR. However, future changes will require appending data stored in an mbuf to memory buffer based XDR. Reviewed by: rmacklem Differential Revision: https://reviews.freebsd.org/D48547
* krpc/svc_vc: keep the vnet context during calls into rpctlsGleb Smirnoff2025-01-181-2/+2
|
* krpc/clnt_vc: clear vnet context before kthread_exit()Gleb Smirnoff2025-01-181-1/+1
| | | | Fixes: b2ff4cb1931c2e1509a5741f6743322699ad1e00
* krpc/clnt_vc: set vnet(9) context in clnt_vc kthreadGleb Smirnoff2025-01-171-0/+2
| | | | | The per-client kthread to offload TLS stuff was added ab0c29af0512d. Let it run in the vnet(9) that matches associated socket.
* krpc/clnt_vc: in clnt_vc_destroy() use more lapidary logicGleb Smirnoff2025-01-171-8/+3
| | | | on whether to close the socket or leave it.
* krpc/clnt_vc: remove always false checkGleb Smirnoff2025-01-171-10/+2
| | | | We just initialized ct_closeit to false a few lines above.
* rpc: remove svc_create(), it is not usedGleb Smirnoff2025-01-092-83/+0
|
* rpc: clean kernel RPC internal headers of non-kernel declarationsGleb Smirnoff2025-01-092-558/+0
| | | | | | | The files svc.h and clnt.h derive from the same files that live in /usr/include, however there is nothing really shared between the kernel and libc RPC implementations. The kernel side files are not installed and there is no reason to pollute them with the old definititions.
* rpc: delete disabled code from rpcb_clnt.cGleb Smirnoff2025-01-091-1141/+1
| | | | | | | The code was disabled since the initial bulk check-in from Isilon in 2008. Its existence poisoned grep(1) results when one would try to learn what are the actual RPC mechanisms that are used by the modern NFC client and server.
* rpc: svc_tli_create() is always called with NULL socketGleb Smirnoff2024-12-192-58/+35
| | | | Axe dead code that allows to provide a created socket.
* nfs, rpc: Ensure kernel credentials have at least one groupOlivier Certner2024-11-022-3/+7
| | | | | | | | | | | | | | | | | | | | | | This fixes several bugs where some 'struct ucred' in the kernel, constructed from user input (via nmount(2)) or obtained from other servers (e.g., gssd(8)), could have an unfilled 'cr_groups' field and whose 'cr_groups[0]' (or 'cr_gid', which is an alias) was later accessed, causing an uninitialized access giving random access rights. Use crsetgroups_fallback() to enforce a fallback group when possible. For NFS, the chosen fallback group is that of the NFS server in the current VNET (NFSD_VNET(nfsrv_defaultgid)). There does not seem to be any sensible fallback available in rpc code (sys/rpc/svc_auth.c, svc_getcred()) on AUTH_UNIX (TLS or not), so just fail credential retrieval there. Stock NSS sources, rpc.tlsservd(8) or rpc.tlsclntd(8) provide non-empty group lists, so will not be impacted. Discussed with: rmacklem (by mail) Approved by: markj (mentor) MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D46918
generated by cgit v1.2.3 (git 2.25.1) at 2026-02-05 19:40:33 +0000