FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=main 2026-04-25T02:55:55Z 2026-04-25T02:55:55Z Gleb Smirnoff glebius@FreeBSD.org 2026-04-25T02:55:55Z urn:sha1:4602d45eb3b1d33e0ea0d97c4d18033af95d7fca The RPC client is more of a class rather than an instance. RPCs from different VNETs are served by the same client. This makes the kgss layer fully transparent to VIMAGE and not even required to be aware of it. It is responsibility of the rpcsec_gss module to have curvnet set on the calling thread when doing RPC calls via kgssapi. This change should enable proper operation of an NFS server with gssd(8) in a VIMAGE jail. PR: 294501 Reviewed by: rmacklem Differential Revision: https://reviews.freebsd.org/D56562 2026-04-25T02:55:50Z Gleb Smirnoff glebius@FreeBSD.org 2026-04-25T02:55:50Z urn:sha1:2bd2f267f344c51c66fc18d963df8cec78db34c1 These RPC methods correctly acquire the kgss_gssd_handle later with call to kgss_gssd_client(). Reviewed by: rmacklem Differential Revision: https://reviews.freebsd.org/D56561 2026-04-25T02:55:45Z Gleb Smirnoff glebius@FreeBSD.org 2026-04-25T02:55:45Z urn:sha1:50c5715159f172103f68fa90e5423a45aea2a626 The original idea was that something else than VNET(9) might be used for kgss in jails, but that is very unlikely to happen. Mechanical change done with sed+grep. No functional change. Reviewed by: rmacklem Differential Revision: https://reviews.freebsd.org/D56560 2025-11-28T01:29:55Z Ed Maste emaste@FreeBSD.org 2025-11-27T16:44:08Z urn:sha1:6901376f59b870ddbb0d922e3455a388333cd460 The module panicked at unload with "recursing but non-recursive rw". There is a comment that "Unloading of the kgssapi module is not currently supported" and the MOD_UNLOAD case falls through to returning EOPNOTSUPP anyway. Just #if 0 the code in the unload path, leaving it as a hint in case someone implements unload support later on. PR: 291249 Reviewed by: rmacklem Fixes: ad704a34bc2c ("Use syscall_helper_register(9) rather than syscall_register().") Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D53949 2025-08-07T21:02:32Z Rick Macklem rmacklem@FreeBSD.org 2025-08-07T21:02:32Z urn:sha1:e3ac01e18eb3db571572d819d6b40966d00f80fe 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 2025-08-07T00:03:20Z Rick Macklem rmacklem@FreeBSD.org 2025-08-07T00:03:20Z urn:sha1:4de9547f322bb26f146ddd4139610e927afc5ef0 This broke the build and will have to wait for cy@'s commit. This reverts commit 554651ebf1c1798fa8fb2560cab761ac3d219555. 2025-08-06T22:37:20Z Rick Macklem rmacklem@FreeBSD.org 2025-08-06T22:36:21Z urn:sha1:554651ebf1c1798fa8fb2560cab761ac3d219555 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 2025-05-09T00:29:23Z Mark Johnston markj@FreeBSD.org 2025-05-09T00:23:40Z urn:sha1:2fa185f9bf5948ead9c3920d452ddd6bcad8f569 Previously OCF set CRYPTO_F_DONE prior to invoking the completion callback, even if the request failed. This isn't particularly useful and leads to bugs when consumers retry a failed request, since OCF also asserts that CRYPTO_F_DONE is clear in crypto_dispatch(). (Really, OCF should retry requests that fail with EAGAIN, but that's a larger change.) For now, just stop setting CRYPTO_F_DONE to simplify consumers (and fix those which fail to clear the flag before retrying a request). PR: 286321 Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D50104 2025-05-09T00:29:15Z Mark Johnston markj@FreeBSD.org 2025-05-09T00:16:53Z urn:sha1:04421fda140b92eb0d22bc4c0f81b6de05f21225 - Instead of using CRYPTO_F_DONE to decide whether a request has completed, use a custom protocol of setting crp_opaque = NULL in the callback and checking that instead. CRYPTO_F_DONE is set independent of whether an error occurred, but for transient errors signaled by EAGAIN, we want to simply retry the request. - Clear CRYPTO_F_DONE before retrying the request. - Panic if the request truly failed, as we currently have no way to pass hard errors back up. Reviewed by: jhb MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D50238 2025-02-01T09:00:25Z Gleb Smirnoff glebius@FreeBSD.org 2025-02-01T01:02:08Z urn:sha1:033b4c1bff10925c286537e48cd2858a08cf6e70 Reviewed by: rmacklem Differential Revision: https://reviews.freebsd.org/D48552