summaryrefslogtreecommitdiff
path: root/net/sunrpc/auth_gss
AgeCommit message (Collapse)Author
2023-02-27SUNRPC: Properly terminate test case arraysChuck Lever
Unable to handle kernel paging request at virtual address 73657420 when execute [73657420] *pgd=00000000 Internal error: Oops: 80000005 [#1] ARM CPU: 0 PID: 1 Comm: swapper Tainted: G N 6.2.0-rc7-00133-g373f26a81164-dirty #9 Hardware name: Generic DT based system PC is at 0x73657420 LR is at kunit_run_tests+0x3e0/0x5f4 On x86 with GCC 12, the missing array terminators did not seem to matter. Other platforms appear to be more picky. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-27SUNRPC: Let Kunit tests run with some enctypes compiled outChuck Lever
Allow the new GSS Kerberos encryption type test suites to run outside of the kunit infrastructure. Replace the assertion that fires when lookup_enctype() so that the case is skipped instead of failing outright. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Fix occasional warning when destroying gss_krb5_enctypesChuck Lever
I'm guessing that the warning fired because there's some code path that is called on module unload where the gss_krb5_enctypes file was never set up. name 'gss_krb5_enctypes' WARNING: CPU: 0 PID: 6187 at fs/proc/generic.c:712 remove_proc_entry+0x38d/0x460 fs/proc/generic.c:712 destroy_krb5_enctypes_proc_entry net/sunrpc/auth_gss/svcauth_gss.c:1543 [inline] gss_svc_shutdown_net+0x7d/0x2b0 net/sunrpc/auth_gss/svcauth_gss.c:2120 ops_exit_list+0xb0/0x170 net/core/net_namespace.c:169 setup_net+0x9bd/0xe60 net/core/net_namespace.c:356 copy_net_ns+0x320/0x6b0 net/core/net_namespace.c:483 create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110 copy_namespaces+0x410/0x500 kernel/nsproxy.c:179 copy_process+0x311d/0x76b0 kernel/fork.c:2272 kernel_clone+0xeb/0x9a0 kernel/fork.c:2684 __do_sys_clone+0xba/0x100 kernel/fork.c:2825 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Reported-by: syzbot+04a8437497bcfb4afa95@syzkaller.appspotmail.com Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Add encryption self-testsChuck Lever
With the KUnit infrastructure recently added, we are free to define other unit tests particular to our implementation. As an example, I've added a self-test that encrypts then decrypts a string, and checks the result. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Add RFC 8009 encryption KUnit testsChuck Lever
RFC 8009 provides sample encryption results. Add KUnit tests to ensure our implementation derives the expected results for the provided sample input. I hate how large this test is, but using non-standard key usage values means rfc8009_encrypt_case() can't simply reuse ->import_ctx to allocate and key its ciphers; and the test provides its own confounders, which means krb5_etm_encrypt() can't be used directly. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Add RFC 8009 checksum KUnit testsChuck Lever
RFC 8009 provides sample checksum results. Add KUnit tests to ensure our implementation derives the expected results for the provided sample input. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Add KDF-HMAC-SHA2 Kunit testsChuck Lever
RFC 8009 provides sample key derivation results, so Kunit tests are added to ensure our implementation derives the expected keys for the provided sample input. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Add encryption KUnit tests for the RFC 6803 encryption typesChuck Lever
Add tests for the new-to-RPCSEC Camellia cipher. Tested-by: Scott Mayhew <smayhew@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Add checksum KUnit tests for the RFC 6803 encryption typesChuck Lever
Test the new-to-RPCSEC CMAC digest algorithm. Tested-by: Scott Mayhew <smayhew@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Add KDF KUnit tests for the RFC 6803 encryption typesChuck Lever
The Camellia enctypes use a new KDF, so add some tests to ensure it is working properly. Tested-by: Scott Mayhew <smayhew@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Add Kunit tests for RFC 3962-defined encryption/decryptionChuck Lever
Add Kunit tests for ENCTYPE_AES128_CTS_HMAC_SHA1_96. The test vectors come from RFC 3962 Appendix B. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Add KUnit tests RFC 3961 Key DerivationChuck Lever
RFC 3961 Appendix A provides tests for the KDF specified in that document as well as other parts of Kerberos. The other three usage scenarios in Section 10 are not implemented by the Linux kernel's RPCSEC GSS Kerberos 5 mechanism, so tests are not added for those. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Export get_gss_krb5_enctype()Chuck Lever
I plan to add KUnit tests that will need enctype profile information. Export the enctype profile lookup function. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Add KUnit tests for rpcsec_krb5.koChuck Lever
The Kerberos RFCs provide test vectors to verify the operation of an implementation. Introduce a KUnit test framework to exercise the Linux kernel's implementation of Kerberos. Start with test cases for the RFC 3961-defined n-fold function. The sample vectors for that are found in RFC 3961 Section 10. Run the GSS Kerberos 5 mechanism's unit tests with this command: $ ./tools/testing/kunit/kunit.py run \ --kunitconfig ./net/sunrpc/.kunitconfig Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Move remaining internal definitions to gss_krb5_internal.hChuck Lever
The goal is to leave only protocol-defined items in gss_krb5.h so that it can be easily replaced by a generic header. Implementation specific items are moved to the new internal header. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Advertise support for the Camellia encryption typesChuck Lever
Add the RFC 6803 encryption types to the string of integers that is reported to gssd during upcalls. This enables gssd to utilize keys with these encryption types when support for them is built into the kernel. Tested-by: Scott Mayhew <smayhew@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Add KDF_FEEDBACK_CMACChuck Lever
The Camellia enctypes use the KDF_FEEDBACK_CMAC Key Derivation Function defined in RFC 6803 Section 3. Tested-by: Scott Mayhew <smayhew@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Support the Camellia enctypesChuck Lever
RFC 6803 defines two encryption types that use Camellia ciphers (RFC 3713) and CMAC digests. Implement support for those in SunRPC's GSS Kerberos 5 mechanism. There has not been an explicit request to support these enctypes. However, this new set of enctypes provides a good alternative to the AES-SHA1 enctypes that are to be deprecated at some point. As this implementation is still a "beta", the default is to not build it automatically. Tested-by: Scott Mayhew <smayhew@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Advertise support for RFC 8009 encryption typesChuck Lever
Add the RFC 8009 encryption types to the string of integers that is reported to gssd during upcalls. This enables gssd to utilize keys with these encryption types when support for them is built into the kernel. Link: https://bugzilla.linux-nfs.org/show_bug.cgi?id=400 Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Add RFC 8009 encryption and decryption functionsChuck Lever
RFC 8009 enctypes use different crypt formulae than previous Kerberos 5 encryption types. Section 1 of RFC 8009 explains the reason for this change: > The new types conform to the framework specified in [RFC3961], > but do not use the simplified profile, as the simplified profile > is not compliant with modern cryptographic best practices such as > calculating Message Authentication Codes (MACs) over ciphertext > rather than plaintext. Add new .encrypt and .decrypt functions to handle this variation. The new approach described above is referred to as Encrypt-then-MAC (or EtM). Hence the names of the new functions added here are prefixed with "krb5_etm_". A critical second difference with previous crypt formulae is that the cipher state is included in the computed HMAC. Note however that for RPCSEC, the initial cipher state is easy to compute on both initiator and acceptor because it is always all zeroes. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Add KDF-HMAC-SHA2Chuck Lever
The RFC 8009 encryption types use a different key derivation function than the RFC 3962 encryption types. The new key derivation function is defined in Section 3 of RFC 8009. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Add gk5e definitions for RFC 8009 encryption typesChuck Lever
Fill in entries in the supported_gss_krb5_enctypes array for the encryption types defined in RFC 8009. These new enctypes use the SHA-256 and SHA-384 message digest algorithms (as defined in FIPS-180) instead of the deprecated SHA-1 algorithm, and are thus more secure. Note that NIST has scheduled SHA-1 for deprecation: https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm Thus these new encryption types are placed under a separate CONFIG option to enable distributors to separately introduce support for the AES-SHA2 enctypes and deprecate support for the current set of AES-SHA1 encryption types as their user space allows. As this implementation is still a "beta", the default is to not build it automatically. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Refactor CBC with CTS into helpersChuck Lever
Cryptosystem profile enctypes all use cipher block chaining with ciphertext steal (CBC-with-CTS). However enctypes that are currently supported in the Linux kernel SunRPC implementation use only the encrypt-&-MAC approach. The RFC 8009 enctypes use encrypt-then-MAC, which performs encryption and checksumming in a different order. Refactor to make it possible to share the CBC with CTS encryption and decryption mechanisms between e&M and etM enctypes. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Add new subkey length fieldsChuck Lever
The aes256-cts-hmac-sha384-192 enctype specifies the length of its checksum and integrity subkeys as 192 bits, but the length of its encryption subkey (Ke) as 256 bits. Add new fields to struct gss_krb5_enctype that specify the key lengths individually, and where needed, use the correct new field instead of ->keylength. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Parametrize the key length passed to context_v2_alloc_cipher()Chuck Lever
Although the Kerberos specs have always listed separate subkey lengths, the Linux kernel's SunRPC GSS Kerberos enctype profiles assume the base key and the derived keys have identical lengths. The aes256-cts-hmac-sha384-192 enctype specifies the length of its checksum and integrity subkeys as 192 bits, but the length of its encryption subkey (Ke) as 256 bits. To support that enctype, parametrize context_v2_alloc_cipher() so that each of its call sites can pass in its desired key length. For now it will be the same length as before (gk5e->keylength), but a subsequent patch will change this. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Clean up cipher set up for v1 encryption typesChuck Lever
De-duplicate some common code. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Hoist KDF into struct gss_krb5_enctypeChuck Lever
Each Kerberos enctype can have a different KDF. Refactor the key derivation path to support different KDFs for the enctypes introduced in subsequent patches. In particular, expose the key derivation function in struct gss_krb5_enctype instead of the enctype's preferred random-to-key function. The latter is usually the identity function and is only ever called during key derivation, so have each KDF call it directly. A couple of extra clean-ups: - Deduplicate the set_cdata() helper - Have ->derive_key return negative errnos, in accordance with usual kernel coding conventions This patch is a little bigger than I'd like, but these are all mechanical changes and they are all to the same areas of code. No behavior change is intended. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Rename .encrypt_v2 and .decrypt_v2 methodsChuck Lever
Clean up: there is now only one encrypt and only one decrypt method, thus there is no longer a need for the v2-suffixed method names. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Remove ->encrypt and ->decrypt methods from struct gss_krb5_enctypeChuck Lever
Clean up: ->encrypt is set to only one value. Replace the two remaining call sites with direct calls to krb5_encrypt(). There have never been any call sites for the ->decrypt() method. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Enable rpcsec_gss_krb5.ko to be built without CRYPTO_DESChuck Lever
Because the DES block cipher has been deprecated by Internet standard, highly secure configurations might require that DES support be blacklisted or not installed. NFS Kerberos should still be able to work correctly with only the AES-based enctypes in that situation. Also note that MIT Kerberos has begun a deprecation process for DES encryption types. Their README for 1.19.3 states: > Beginning with the krb5-1.19 release, a warning will be issued > if initial credentials are acquired using the des3-cbc-sha1 > encryption type. In future releases, this encryption type will > be disabled by default and eventually removed. > > Beginning with the krb5-1.18 release, single-DES encryption > types have been removed. Aside from the CONFIG option name change, there are two important policy changes: 1. The 'insecure enctype' group is now disabled by default. Distributors have to take action to enable support for deprecated enctypes. Implementation of these enctypes will be removed in a future kernel release. 2. des3-cbc-sha1 is now considered part of the 'insecure enctype' group, having been deprecated by RFC 8429, and is thus disabled by default After this patch is applied, SunRPC support can be built with Kerberos 5 support but without CRYPTO_DES enabled in the kernel. And, when these enctypes are disabled, the Linux kernel's SunRPC RPCSEC GSS implementation fully complies with BCP 179 / RFC 6649 and BCP 218 / RFC 8429. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Replace KRB5_SUPPORTED_ENCTYPES macroChuck Lever
Now that all consumers of the KRB5_SUPPORTED_ENCTYPES macro are within the SunRPC layer, the macro can be replaced with something private and more flexible. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Add /proc/net/rpc/gss_krb5_enctypes fileChuck Lever
I would like to replace the KRB5_SUPPORTED_ENCTYPES macro so that there is finer granularity about what enctype support is built in to the kernel and then advertised by it. The /proc/fs/nfsd/supported_krb5_enctypes file is a legacy API that advertises supported enctypes to rpc.svcgssd (I think?). It simply prints the value of the KRB5_SUPPORTED_ENCTYPES macro, so it will need to be replaced with something that can instead display exactly which enctypes are configured and built into the SunRPC layer. Completely decommissioning such APIs is hard. Instead, add a file that is managed by SunRPC's GSS Kerberos mechanism, which is authoritative about enctype support status. A subsequent patch will replace /proc/fs/nfsd/supported_krb5_enctypes with a symlink to this new file. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Remove another switch on ctx->enctypeChuck Lever
Replace another switch on encryption type so that it does not have to be modified when adding or removing support for an enctype. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Refactor the GSS-API Per Message calls in the Kerberos mechanismChuck Lever
Replace a number of switches on encryption type so that all of them don't have to be modified when adding or removing support for an enctype. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Obscure Kerberos integrity keysChuck Lever
There's no need to keep the integrity keys around if we instead allocate and key a pair of ahashes and keep those. This not only enables the subkeys to be destroyed immediately after deriving them, but it makes the Kerberos integrity code path more efficient. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Obscure Kerberos signing keysChuck Lever
There's no need to keep the signing keys around if we instead allocate and key an ahash and keep that. This not only enables the subkeys to be destroyed immediately after deriving them, but it makes the Kerberos signing code path more efficient. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Obscure Kerberos encryption keysChuck Lever
The encryption subkeys are not used after the cipher transforms have been allocated and keyed. There is no need to retain them in struct krb5_ctx. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Refactor set-up for aux_cipherChuck Lever
Hoist the name of the aux_cipher into struct gss_krb5_enctype to prepare for obscuring the encryption keys just after they are derived. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Obscure Kerberos session keyChuck Lever
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>
2023-02-20SUNRPC: Improve Kerberos confounder generationChuck Lever
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: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Remove .conflen field from struct gss_krb5_enctypeChuck Lever
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: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Remove .blocksize field from struct gss_krb5_enctypeChuck Lever
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: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Go back to using gsd->body_startChuck Lever
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: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Set rq_accept_statp inside ->accept methodsChuck Lever
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: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Hoist init_encode out of svc_authenticate()Chuck Lever
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: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Use xdr_stream for encoding GSS reply verifiersChuck Lever
Done as part of hardening the server-side RPC header encoding path. Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Use xdr_stream to encode replies in server-side GSS upcall helpersChuck Lever
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: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Convert unwrap data paths to use xdr_stream for repliesChuck Lever
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: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Move svcxdr_init_encode() into ->accept methodsChuck Lever
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: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2023-02-20SUNRPC: Check rq_auth_stat when preparing to wrap a responseChuck Lever
Commit 5b304bc5bfcc ("[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 438623a06bac ("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: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>