- 20 Feb, 2023 40 commits
-
-
Chuck Lever authored
ctx->Ksess is never used after import has completed. Obscure it immediately so it cannot be re-used or copied. Tested-by:
Scott Mayhew <smayhew@redhat.com> Reviewed-by:
Simo Sorce <simo@redhat.com> Signed-off-by:
Chuck Lever <chuck.lever@oracle.com>
-
Chuck Lever authored
Other common Kerberos implementations use a fully random confounder for encryption. The reason for this is explained in the new comment added by this patch. The current get_random_bytes() implementation does not exhaust system entropy. Since confounder generation is part of Kerberos itself rather than the GSS-API Kerberos mechanism, the function is renamed and moved. Note that light top-down analysis shows that the SHA-1 transform is by far the most CPU-intensive part of encryption. Thus we do not expect this change to result in a significant performance impact. However, eventually it might be necessary to generate an independent stream of confounders for each Kerberos context to help improve I/O parallelism. Reviewed-by:
-
Chuck Lever authored
Now that arcfour-hmac is gone, the confounder length is again the same as the cipher blocksize for every implemented enctype. The gss_krb5_enctype::conflen field is no longer necessary. Tested-by:
-
Chuck Lever authored
It is not clear from documenting comments, specifications, or code usage what value the gss_krb5_enctype.blocksize field is supposed to store. The "encryption blocksize" depends only on the cipher being used, so that value can be derived where it's needed instead of stored as a constant. RFC 3961 Section 5.2 says: > cipher block size, c > This is the block size of the block cipher underlying the > encryption and decryption functions indicated above, used for key > derivation and for the size of the message confounder and initial > vector. (If a block cipher is not in use, some comparable > parameter should be determined.) It must be at least 5 octets. > > This is not actually an independent parameter; rather, it is a > property of the functions E and D. It is listed here to clarify > the distinction between it and the message block size, m. In the Linux kernel's implemenation of the SunRPC RPCSEC GSS Kerberos 5 mechanism, the cipher block size, which is dependent on the encryption and decryption transforms, is used only in krb5_derive_key(), so it is straightforward to replace it. Tested-by:
-
Chuck Lever authored
Standard convention: Ensure the contents of the header are included only once per source file. Tested-by:
-
Chuck Lever authored
Eliminate the use of bus-locked operations in svc_xprt_enqueue(), which is a hot path. Replace them with per-cpu variables to reduce cross-CPU memory bus traffic. Signed-off-by: -
Chuck Lever authored
- Improves counting accuracy - Reduces cross-CPU memory traffic Signed-off-by: -
Jeff Layton authored
There's no need to start the reply cache before nfsd is up and running, and doing so means that we register a shrinker for every net namespace instead of just the ones where nfsd is running. Move it to the per-net nfsd startup instead. Reported-by:
Dai Ngo <dai.ngo@oracle.com> Signed-off-by:
Jeff Layton <jlayton@kernel.org> Signed-off-by:
-
Chuck Lever authored
Now that svcauth_gss_prepare_to_wrap() no longer computes the location of RPC header fields in the response buffer, svcauth_gss_accept() can save the location of the databody rather than the location of the verifier. Reviewed-by:
-
Chuck Lever authored
To navigate around the space that svcauth_gss_accept() reserves for the RPC payload body length and sequence number fields, svcauth_gss_release() does a little dance with the reply's accept_stat, moving the accept_stat value in the response buffer down by two words. Instead, let's have the ->accept() methods each set the proper final location of the accept_stat to avoid having to move things. Reviewed-by:
-
Chuck Lever authored
Currently, svcauth_gss_accept() pre-reserves response buffer space for the RPC payload length and GSS sequence number before returning to the dispatcher, which then adds the header's accept_stat field. The problem is the accept_stat field is supposed to go before the length and seq_num fields. So svcauth_gss_release() has to relocate the accept_stat value (see svcauth_gss_prepare_to_wrap()). To enable these fields to be added to the response buffer in the correct (final) order, the pointer to the accept_stat has to be made available to svcauth_gss_accept() so that it can set it before reserving space for the length and seq_num fields. As a first step, move the pointer to the location of the accept_stat field into struct svc_rqst. Reviewed-by:
-
Chuck Lever authored
The svc_get/put helpers are no longer used. Reviewed-by:
-
Chuck Lever authored
The @resv parameter is no longer used. Reviewed-by:
-
Chuck Lever authored
The main part of RPC header encoding and the formation of error responses are now done using the xdr_stream helpers. Bounds checking before each XDR data item is encoded makes the server's encoding path safer against accidental buffer overflows. Reviewed-by:
-
Chuck Lever authored
Now that each ->accept method has been converted, the svcxdr_init_encode() calls can be hoisted back up into the generic RPC server code. Reviewed-by:
-
Chuck Lever authored
Done as part of hardening the server-side RPC header encoding path. Reviewed-by:
-
Chuck Lever authored
This code constructs replies to the decorated NULL procedure calls that establish GSS contexts. Convert this code path to use struct xdr_stream to encode such responses. Done as part of hardening the server-side RPC header encoding path. Reviewed-by:
-
Chuck Lever authored
We're now moving svcxdr_init_encode() to /before/ the flavor's ->accept method has set rq_auth_slack. Add a helper that can set rq_auth_slack /after/ svcxdr_init_encode() has been called. Reviewed-by:
-
Chuck Lever authored
Done as part of hardening the server-side RPC header encoding path. Reviewed-by:
-
Chuck Lever authored
Done as part of hardening the server-side RPC header encoding path. Reviewed-by:
-
Chuck Lever authored
Done as part of hardening the server-side RPC header encoding path. Reviewed-by:
-
Chuck Lever authored
Refactor: So that the overhaul of each ->accept method can be done in separate smaller patches, temporarily move the svcxdr_init_encode() call into those methods. Reviewed-by:
-
Chuck Lever authored
Now that all vs_dispatch functions invoke svcxdr_init_encode(), it is common code and can be pushed down into the generic RPC server. Reviewed-by:
-
Chuck Lever authored
RFC 5531 defines an MSG_ACCEPTED Reply message like this: struct accepted_reply { opaque_auth verf; union switch (accept_stat stat) { case SUCCESS: ... In the current server code, struct opaque_auth encoding is open- coded. Introduce a helper that encodes an opaque_auth data item within the context of a xdr_stream. Done as part of hardening the server-side RPC header decoding and encoding paths. Reviewed-by: -
Chuck Lever authored
There's no RPC header field called rpc_stat; more precisely, the variable appears to be recording an accept_stat value. But it looks like we don't need to preserve this value at all, actually, so simply remove the variable. Reviewed-by:
-
Chuck Lever authored
Commit 5b304bc5 ("[PATCH] knfsd: svcrpc: gss: fix failure on SVC_DENIED in integrity case") added a check to prevent wrapping an RPC response if reply_stat == MSG_DENIED, assuming that the only way to get to svcauth_gss_release() with that reply_stat value was if the reject_stat was AUTH_ERROR (reject_stat == MISMATCH is handled earlier in svc_process_common()). The code there is somewhat confusing. For one thing, rpc_success is an accept_stat value, not a reply_stat value. The correct reply_stat value to look for is RPC_MSG_DENIED. It happens to be the same value as rpc_success, so it all works out, but it's not terribly readable. Since commit 438623a0 ("SUNRPC: Add svc_rqst::rq_auth_stat"), the actual auth_stat value is stored in the svc_rqst, so that value is now available to svcauth_gss_prepare_to_wrap() to make its decision to wrap, based on direct information about the authentication status of the RPC caller. No behavior change is intended, this simply replaces some old code with something that should be more self-documenting. Reviewed-by:
-
Chuck Lever authored
Actually xdr_stream does not add value here because of how gss_wrap() works. This is just a clean-up patch. Reviewed-by:
-
Chuck Lever authored
Simplify the references to the head and tail iovecs for readability. Reviewed-by:
-
Chuck Lever authored
Match the error reporting in the other unwrap and wrap functions. Reviewed-by:
-
Chuck Lever authored
Clean up variable names to match the other unwrap and wrap functions. Additionally, the explicit type cast on @gsd in unnecessary; and @resbuf is renamed to match the variable naming in the unwrap functions. Reviewed-by:
-
Chuck Lever authored
Done as part of hardening the server-side RPC header decoding path. Reviewed-by:
-
Chuck Lever authored
Replace finicky logic: Instead of trying to find scratch space in the response buffer, use the scratch buffer from struct gss_svc_data. Reviewed-by:
-
Chuck Lever authored
An error computing the checksum here is an exceptional event. Reviewed-by:
-
Chuck Lever authored
Clean up: To help orient readers, name the stack variables to match the XDR field names. Additionally, the explicit type cast on @gsd is unnecessary; and @resbuf is renamed to match the variable naming in the unwrap functions. Reviewed-by:
-
Chuck Lever authored
Now that upper layers use an xdr_stream to track the construction of each RPC Reply message, resbuf->len is kept up-to-date automatically. There's no need to recompute it in svc_gss_release(). Reviewed-by:
-
Jeff Layton authored
The WARN_ON_ONCE check is not terribly useful. It also seems possible for nfs4_find_file to race with the destruction of an fi_deleg_file while trying to take a reference to it. Now that it's safe to pass nfs_get_file a NULL pointer, remove the WARN and NULL pointer check. Take the fi_lock when fetching fi_deleg_file. Cc: NeilBrown <neilb@suse.de> Signed-off-by:
-
Jeff Layton authored
...and remove some now-useless NULL pointer checks in its callers. Suggested-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Dai Ngo authored
Currently nfsd4_setup_inter_ssc returns the vfsmount of the source server's export when the mount completes. After the copy is done nfsd4_cleanup_inter_ssc is called with the vfsmount of the source server and it searches nfsd_ssc_mount_list for a matching entry to do the clean up. The problems with this approach are (1) the need to search the nfsd_ssc_mount_list and (2) the code has to handle the case where the matching entry is not found which looks ugly. The enhancement is instead of nfsd4_setup_inter_ssc returning the vfsmount, it returns the nfsd4_ssc_umount_item which has the vfsmount embedded in it. When nfsd4_cleanup_inter_ssc is called it's passed with the nfsd4_ssc_umount_item directly to do the clean up so no searching is needed and there is no need to handle the 'not found' case. Signed-off-by:
Olga Kornievskaia <kolga@netapp.com>
-
Chuck Lever authored
Now the entire RPC Call header parsing path is handled via struct xdr_stream-based decoders. Reviewed-by:
-
Chuck Lever authored
Clean up: With xdr_stream decoding, the @argv parameter is no longer used. Reviewed-by:
-
