gsskrb5: pool per-message krb5_crypto instances in CFX - #1
Draft
MoonRei wants to merge 1 commit into
Draft
Conversation
A krb5_crypto is not safe for concurrent use: its derived-key cache and the EVP cipher contexts embedded in each derived key are mutated by every encrypt and checksum call, so the shared ctx->crypto serialized all per-message operations (wrap, unwrap, get_mic, verify_mic) on one established context. Give each CFX per-message operation a private krb5_crypto checked out of a small per-context pool, created from the token key on demand and returned after the call. Concurrent per-message calls then never share cipher state, and the pool preserves each instance's derived-key cache across messages, so steady-state traffic pays no per-message key derivation. The pool is guarded by ctx_id_mutex and flushed wherever the token key can change (_gsskrb5i_is_cfx, set_sec_context_option) and at context teardown. ctx->crypto remains the source of enctype metadata (lengths, checksum type), which is immutable after creation. The non-CFX paths already build a krb5_crypto per call from the token key and are unchanged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A krb5_crypto is not safe for concurrent use: its derived-key cache and the EVP cipher
contexts embedded in each derived key are mutated by every encrypt and checksum call, so the
shared ctx->crypto serialized all per-message operations (wrap, unwrap, get_mic, verify_mic)
on one established context. NFSv4 krb5i/krb5p throughput in QFSD is bounded by that
serialization (QFS-147864).
Each CFX per-message operation now checks a private krb5_crypto out of a small per-context
pool, created from the token key on demand and returned after the call. Concurrent
per-message calls never share cipher state, and the pool preserves each instance's
derived-key cache across messages, so steady-state traffic pays no per-message key
derivation. The pool is guarded by ctx_id_mutex and flushed wherever the token key can
change (_gsskrb5i_is_cfx, set_sec_context_option) and at context teardown.
ctx->crypto remains the source of enctype metadata (lengths, checksum type), which is
immutable after creation. The non-CFX paths already build a krb5_crypto per call from the
token key and are unchanged.
This is the change vendored into the QFSD toolchain as
nix/pkgs/heimdal/patches/0001-gsskrb5-pool-per-message-krb5_crypto-in-CFX.patch
(qfsd reviews D362288/D362289); the qfsd side relaxes its per-context lock to a rwlock taken
shared for per-message operations and adds a concurrent seal/verify test over all four entry
points.
Validated by building the toolchain heimdal package with the patch applied (heimdal's own
suite stays disabled in the nix sandbox); the concurrency behavior is exercised by
auth/kerberos/auth_context_test.c in the qfsd tree.
🤖 Generated with Claude Code