- 27 Feb, 2023 1 commit
-
-
Chuck Lever authored
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:
Chuck Lever <chuck.lever@oracle.com>
-
- 20 Feb, 2023 39 commits
-
-
Chuck Lever authored
The pointer dentry is assigned a value that is never read, the assignment is redundant and can be removed. Cleans up clang-scan warning: fs/nfsd/nfsctl.c:1231:2: warning: Value stored to 'dentry' is never read [deadcode.DeadStores] dentry = ERR_PTR(ret); No need to initialize "int ret = -ENOMEM;" either. These are vestiges of nfsd_mkdir(), from whence I copied nfsd_symlink(). Reported-by:Colin Ian King <colin.i.king@gmail.com> Reported-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
Chuck Lever authored
Currently, we're only memcpy'ing the first __be32. Ensure we copy into both words. Fixes: 91d2e9b5 ("NFSD: Clean up the nfsd_net::nfssvc_boot field") Reported-by:
Jeff Layton <jlayton@kernel.org> Signed-off-by:
-
Jeff Layton authored
Most of the time, NFSv4 clients issue a COMMIT before the final CLOSE of an open stateid, so with NFSv4, the fsync in the nfsd_file_free path is usually a no-op and doesn't block. We have a customer running knfsd over very slow storage (XFS over Ceph RBD). They were using the "async" export option because performance was more important than data integrity for this application. That export option turns NFSv4 COMMIT calls into no-ops. Due to the fsync in this codepath however, their final CLOSE calls would still stall (since a CLOSE effectively became a COMMIT). I think this fsync is not strictly necessary. We only use that result to reset the write verifier. Instead of fsync'ing all of the data when we free an nfsd_file, we can just check for writeback errors when one is acquired and when it is freed. If the client never comes back, then it'll never see the error anyway and there is no point in resetting it. If an error occurs after the nfsd_file is removed from the cache but before the inode is evicted, then it will reset the write verifier on the next nfsd_file_acquire, (since there will be an unseen error). The only exception here is if something else opens and fsyncs the file during that window. Given that local applications work with this limitation today, I don't see that as an issue. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2166658 Fixes: ac3a2585 ("nfsd: rework refcounting in filecache") Reported-and-tested-by:
Pierguido Lambri <plambri@redhat.com> Signed-off-by:
-
Chuck Lever authored
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: -
Jeff Layton authored
The nested if statements here make no sense, as you can never reach "else" branch in the nested statement. Fix the error handling for when there is a courtesy client that holds a conflicting deny mode. Fixes: 3d694271 ("NFSD: add support for share reservation conflict to courteous server") Reported-by:
張智諺 <cc85nod@gmail.com> Signed-off-by:
Dai Ngo <dai.ngo@oracle.com> Signed-off-by:
-
Dai Ngo authored
When nfsd4_copy fails to allocate memory for async_copy->cp_src, or nfs4_init_copy_state fails, it calls cleanup_async_copy to do the cleanup for the async_copy which causes page fault since async_copy is not yet initialized. This patche rearranges the order of initializing the fields in async_copy and adds checks in cleanup_async_copy to skip un-initialized fields. Fixes: ce0887ac ("NFSD add nfs4 inter ssc to nfsd4_copy") Fixes: 87689df6 ("NFSD: Shrink size of struct nfsd4_copy") Signed-off-by:
-
Benjamin Coddington authored
Its possible for __break_lease to find the layout's lease before we've added the layout to the owner's ls_layouts list. In that case, setting ls_recalled = true without actually recalling the layout will cause the server to never send a recall callback. Move the check for ls_layouts before setting ls_recalled. Fixes: c5c707f9 ("nfsd: implement pNFS layout recalls") Signed-off-by:
Benjamin Coddington <bcodding@redhat.com> Reviewed-by:
-
Jeff Layton authored
We had a bug report that xfstest generic/355 was failing on NFSv4.0. This test sets various combinations of setuid/setgid modes and tests whether DIO writes will cause them to be stripped. What I found was that the server did properly strip those bits, but the client didn't notice because it held a delegation that was not recalled. The recall didn't occur because the client itself was the one generating the activity and we avoid recalls in that case. Clearing setuid bits is an "implicit" activity. The client didn't specifically request that we do that, so we need the server to issue a CB_RECALL, or avoid the situation entirely by not issuing a delegation. The easiest fix here is to simply not give out a delegation if the file is being opened for write, and the mode has the setuid and/or setgid bit set. Note that there is a potential race between the mode and lease being set, so we test for this condition both before and after setting the lease. This patch fixes generic/355, generic/683 and generic/684 for me. (Note that 355 fails only on v4.0, and 683 and 684 require NFSv4.2 to run and fail). Reported-by:
Boyang Xue <bxue@redhat.com> Signed-off-by:
-
Chuck Lever authored
There's no need for the cost of this extra virtual function call during every RPC transaction: the RQ_SECURE bit can be set properly in ->xpo_recvfrom() instead. Reviewed-by:
-
Chuck Lever authored
Make this macro more conventional: - Use BIT() instead of open-coding " 1UL << " - Don't display the "XPT_" in every flag name Reviewed-by:
-
Jeff Layton authored
This file is no longer built at all. Signed-off-by:
-
Dai Ngo authored
The reference count of nfsd4_ssc_umount_item is not decremented on error conditions. This prevents the laundromat from unmounting the vfsmount of the source file. This patch decrements the reference count of nfsd4_ssc_umount_item on error. Fixes: f4e44b39 ("NFSD: delay unmount source's export after inter-server copy completed.") Signed-off-by:
-
Jeff Layton authored
There are two different flavors of the nfsd4_copy struct. One is embedded in the compound and is used directly in synchronous copies. The other is dynamically allocated, refcounted and tracked in the client struture. For the embedded one, the cleanup just involves releasing any nfsd_files held on its behalf. For the async one, the cleanup is a bit more involved, and we need to dequeue it from lists, unhash it, etc. There is at least one potential refcount leak in this code now. If the kthread_create call fails, then both the src and dst nfsd_files in the original nfsd4_copy object are leaked. The cleanup in this codepath is also sort of weird. In the async copy case, we'll have up to four nfsd_file references (src and dst for both flavors of copy structure). They are both put at the end of nfsd4_do_async_copy, even though the ones held on behalf of the embedded one outlive that structure. Change it so that we always clean up the nfsd_file refs held by the embedded copy structure before nfsd4_copy returns. Rework cleanup_async_copy to handle both inter and intra copies. Eliminate nfsd4_cleanup_intra_ssc since it now becomes a no-op. Signed-off-by:
-
Jeff Layton authored
At first, I thought this might be a source of nfsd_file overputs, but the current callers seem to avoid an extra put when nfsd4_verify_copy returns an error. Still, it's "bad form" to leave the pointers filled out when we don't have a reference to them anymore, and that might lead to bugs later. Zero them out as a defensive coding measure. Signed-off-by:
-
Chuck Lever authored
Signed-off-by: -
Jeff Layton authored
This is wrapper is pointless, and just obscures what's going on. Signed-off-by:
-
Jeff Layton authored
Signed-off-by:
-
Jeff Layton authored
We really don't need an accessor function here. Signed-off-by:
-
Jeff Layton authored
We're not doing any blocking operations for OP_OFFLOAD_STATUS, so taking and putting a reference is a waste of effort. Take the client lock, search for the copy and fetch the wr_bytes_written field and return. Also, make find_async_copy a static function. Signed-off-by:
Olga Kornievskaia <kolga@netapp.com> Signed-off-by:
-
Chuck Lever authored
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 authored
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:
-
Chuck Lever authored
RFC 8009 provides sample checksum results. Add KUnit tests to ensure our implementation derives the expected results for the provided sample input. Tested-by:
-
Chuck Lever authored
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:
-
Chuck Lever authored
Add tests for the new-to-RPCSEC Camellia cipher. Tested-by:
-
Chuck Lever authored
Test the new-to-RPCSEC CMAC digest algorithm. Tested-by:
-
Chuck Lever authored
The Camellia enctypes use a new KDF, so add some tests to ensure it is working properly. Tested-by:
-
Chuck Lever authored
Add Kunit tests for ENCTYPE_AES128_CTS_HMAC_SHA1_96. The test vectors come from RFC 3962 Appendix B. Tested-by:
-
Chuck Lever authored
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:
-
Chuck Lever authored
I plan to add KUnit tests that will need enctype profile information. Export the enctype profile lookup function. Tested-by:
-
Chuck Lever authored
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:
-
Chuck Lever authored
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:
-
Chuck Lever authored
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:
-
Chuck Lever authored
The Camellia enctypes use the KDF_FEEDBACK_CMAC Key Derivation Function defined in RFC 6803 Section 3. Tested-by:
-
Chuck Lever authored
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:
-
Chuck Lever authored
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=400Tested-by:
-
Chuck Lever authored
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:
-
Chuck Lever authored
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:
-
Chuck Lever authored
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:
-
Chuck Lever authored
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:
-
