OSDN Git Service
Jeff Layton [Thu, 30 Mar 2023 18:24:27 +0000 (14:24 -0400)]
sunrpc: only free unix grouplist after RCU settles
While the unix_gid object is rcu-freed, the group_info list that it
contains is not. Ensure that we only put the group list reference once
we are really freeing the unix_gid object.
Reported-by: Zhi Li <yieli@redhat.com>
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2183056
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Fixes:
fd5d2f78261b ("SUNRPC: Make server side AUTH_UNIX use lockless lookups")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Jeff Layton [Mon, 27 Mar 2023 10:21:37 +0000 (06:21 -0400)]
nfsd: call op_release, even when op_func returns an error
For ops with "trivial" replies, nfsd4_encode_operation will shortcut
most of the encoding work and skip to just marshalling up the status.
One of the things it skips is calling op_release. This could cause a
memory leak in the layoutget codepath if there is an error at an
inopportune time.
Have the compound processing engine always call op_release, even when
op_func sets an error in op->status. With this change, we also need
nfsd4_block_get_device_info_scsi to set the gd_device pointer to NULL
on error to avoid a double free.
Reported-by: Zhi Li <yieli@redhat.com>
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2181403
Fixes:
34b1744c91cc ("nfsd4: define ->op_release for compound ops")
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Fri, 31 Mar 2023 20:31:19 +0000 (16:31 -0400)]
NFSD: Avoid calling OPDESC() with ops->opnum == OP_ILLEGAL
OPDESC() simply indexes into nfsd4_ops[] by the op's operation
number, without range checking that value. It assumes callers are
careful to avoid calling it with an out-of-bounds opnum value.
nfsd4_decode_compound() is not so careful, and can invoke OPDESC()
with opnum set to OP_ILLEGAL, which is 10044 -- well beyond the end
of nfsd4_ops[].
Reported-by: Jeff Layton <jlayton@kernel.org>
Fixes:
f4f9ef4a1b0a ("nfsd4: opdesc will be useful outside nfs4proc.c")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Wed, 22 Mar 2023 19:01:34 +0000 (15:01 -0400)]
SUNRPC: Fix a crash in gss_krb5_checksum()
Anna says:
> KASAN reports [...] a slab-out-of-bounds in gss_krb5_checksum(),
> and it can cause my client to panic when running cthon basic
> tests with krb5p.
> Running faddr2line gives me:
>
> gss_krb5_checksum+0x4b6/0x630:
> ahash_request_free at
> /home/anna/Programs/linux-nfs.git/./include/crypto/hash.h:619
> (inlined by) gss_krb5_checksum at
> /home/anna/Programs/linux-nfs.git/net/sunrpc/auth_gss/gss_krb5_crypto.c:358
My diagnosis is that the memcpy() at the end of gss_krb5_checksum()
reads past the end of the buffer containing the checksum data
because the callers have ignored gss_krb5_checksum()'s API contract:
* Caller provides the truncation length of the output token (h) in
* cksumout.len.
Instead they provide the fixed length of the hmac buffer. This
length happens to be larger than the value returned by
crypto_ahash_digestsize().
Change these errant callers to work like krb5_etm_{en,de}crypt().
As a defensive measure, bound the length of the byte copy at the
end of gss_krb5_checksum().
Kunit sez:
Testing complete. Ran 68 tests: passed: 68
Elapsed time: 81.680s total, 5.875s configuring, 75.610s building, 0.103s running
Reported-by: Anna Schumaker <schumaker.anna@gmail.com>
Fixes:
8270dbfcebea ("SUNRPC: Obscure Kerberos integrity keys")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Jeff Layton [Fri, 17 Mar 2023 17:13:08 +0000 (13:13 -0400)]
nfsd: don't replace page in rq_pages if it's a continuation of last page
The splice read calls nfsd_splice_actor to put the pages containing file
data into the svc_rqst->rq_pages array. It's possible however to get a
splice result that only has a partial page at the end, if (e.g.) the
filesystem hands back a short read that doesn't cover the whole page.
nfsd_splice_actor will plop the partial page into its rq_pages array and
return. Then later, when nfsd_splice_actor is called again, the
remainder of the page may end up being filled out. At this point,
nfsd_splice_actor will put the page into the array _again_ corrupting
the reply. If this is done enough times, rq_next_page will overrun the
array and corrupt the trailing fields -- the rq_respages and
rq_next_page pointers themselves.
If we've already added the page to the array in the last pass, don't add
it to the array a second time when dealing with a splice continuation.
This was originally handled properly in nfsd_splice_actor, but commit
91e23b1c3982 ("NFSD: Clean up nfsd_splice_actor()") removed the check
for it.
Fixes:
91e23b1c3982 ("NFSD: Clean up nfsd_splice_actor()")
Cc: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: Dario Lesca <d.lesca@solinos.it>
Tested-by: David Critch <dcritch@redhat.com>
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2150630
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Wed, 8 Mar 2023 14:45:09 +0000 (09:45 -0500)]
NFS & NFSD: Update GSS dependencies
Geert reports that:
> On v6.2, "make ARCH=m68k defconfig" gives you
> CONFIG_RPCSEC_GSS_KRB5=m
> On v6.3, it became builtin, due to dropping the dependencies on
> the individual crypto modules.
>
> $ grep -E "CRYPTO_(MD5|DES|CBC|CTS|ECB|HMAC|SHA1|AES)" .config
> CONFIG_CRYPTO_AES=y
> CONFIG_CRYPTO_AES_TI=m
> CONFIG_CRYPTO_DES=m
> CONFIG_CRYPTO_CBC=m
> CONFIG_CRYPTO_CTS=m
> CONFIG_CRYPTO_ECB=m
> CONFIG_CRYPTO_HMAC=m
> CONFIG_CRYPTO_MD5=m
> CONFIG_CRYPTO_SHA1=m
This behavior is triggered by the "default y" in the definition of
RPCSEC_GSS.
The "default y" was added in 2010 by commit
df486a25900f ("NFS: Fix
the selection of security flavours in Kconfig"). However,
svc_gss_principal was removed in 2012 by commit
03a4e1f6ddf2
("nfsd4: move principal name into svc_cred"), so the 2010 fix is
no longer necessary. We can safely change the NFS_V4 and NFSD_V4
dependencies back to RPCSEC_GSS_KRB5 to get the nicer v6.2
behavior back.
Selecting KRB5 symbolically represents the true requirement here:
that all spec-compliant NFSv4 implementations must have Kerberos
available to use.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Fixes:
dfe9a123451a ("SUNRPC: Enable rpcsec_gss_krb5.ko to be built without CRYPTO_DES")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Benjamin Coddington [Fri, 3 Mar 2023 21:08:32 +0000 (16:08 -0500)]
SUNRPC: Fix a server shutdown leak
Fix a race where kthread_stop() may prevent the threadfn from ever getting
called. If that happens the svc_rqst will not be cleaned up.
Fixes:
ed6473ddc704 ("NFSv4: Fix callback server shutdown")
Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Mon, 6 Mar 2023 15:43:47 +0000 (10:43 -0500)]
NFSD: Protect against filesystem freezing
Flole observes this WARNING on occasion:
[
1210423.486503] WARNING: CPU: 8 PID:
1524732 at fs/ext4/ext4_jbd2.c:75 ext4_journal_check_start+0x68/0xb0
Reported-by: <flole@flole.de>
Suggested-by: Jan Kara <jack@suse.cz>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217123
Fixes:
73da852e3831 ("nfsd: use vfs_iter_read/write")
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Mon, 27 Feb 2023 16:52:59 +0000 (11:52 -0500)]
SUNRPC: Properly terminate test case arrays
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>
Chuck Lever [Mon, 27 Feb 2023 15:58:34 +0000 (10:58 -0500)]
SUNRPC: Let Kunit tests run with some enctypes compiled out
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>
Chuck Lever [Tue, 14 Feb 2023 15:19:30 +0000 (10:19 -0500)]
NFSD: Clean up nfsd_symlink()
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 <chuck.lever@oracle.com>
Chuck Lever [Tue, 14 Feb 2023 15:07:59 +0000 (10:07 -0500)]
NFSD: copy the whole verifier in nfsd_copy_write_verifier
Currently, we're only memcpy'ing the first __be32. Ensure we copy into
both words.
Fixes:
91d2e9b56cf5 ("NFSD: Clean up the nfsd_net::nfssvc_boot field")
Reported-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Jeff Layton [Tue, 7 Feb 2023 17:02:46 +0000 (12:02 -0500)]
nfsd: don't fsync nfsd_files on last close
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:
ac3a2585f018 ("nfsd: rework refcounting in filecache")
Reported-and-tested-by: Pierguido Lambri <plambri@redhat.com>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Sun, 5 Feb 2023 16:58:44 +0000 (11:58 -0500)]
SUNRPC: Fix occasional warning when destroying gss_krb5_enctypes
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>
Jeff Layton [Fri, 3 Feb 2023 18:18:34 +0000 (13:18 -0500)]
nfsd: fix courtesy client with deny mode handling in nfs4_upgrade_open
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:
3d6942715180 ("NFSD: add support for share reservation conflict to courteous server")
Reported-by: 張智諺 <cc85nod@gmail.com>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Dai Ngo <dai.ngo@oracle.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Dai Ngo [Tue, 31 Jan 2023 19:12:29 +0000 (11:12 -0800)]
NFSD: fix problems with cleanup on errors in nfsd4_copy
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:
ce0887ac96d3 ("NFSD add nfs4 inter ssc to nfsd4_copy")
Fixes:
87689df69491 ("NFSD: Shrink size of struct nfsd4_copy")
Signed-off-by: Dai Ngo <dai.ngo@oracle.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Benjamin Coddington [Fri, 27 Jan 2023 16:18:56 +0000 (11:18 -0500)]
nfsd: fix race to check ls_layouts
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:
c5c707f96fc9 ("nfsd: implement pNFS layout recalls")
Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Jeff Layton [Fri, 27 Jan 2023 12:09:33 +0000 (07:09 -0500)]
nfsd: don't hand out delegation on setuid files being opened for write
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: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Tue, 24 Jan 2023 20:40:22 +0000 (15:40 -0500)]
SUNRPC: Remove ->xpo_secure_port()
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: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Tue, 24 Jan 2023 20:40:15 +0000 (15:40 -0500)]
SUNRPC: Clean up the svc_xprt_flags() macro
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 <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Jeff Layton [Tue, 24 Jan 2023 16:45:38 +0000 (11:45 -0500)]
nfsd: remove fs/nfsd/fault_inject.c
This file is no longer built at all.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Dai Ngo [Tue, 24 Jan 2023 05:34:13 +0000 (21:34 -0800)]
NFSD: fix leaked reference count of nfsd4_ssc_umount_item
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:
f4e44b393389 ("NFSD: delay unmount source's export after inter-server copy completed.")
Signed-off-by: Dai Ngo <dai.ngo@oracle.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Jeff Layton [Tue, 17 Jan 2023 19:38:31 +0000 (14:38 -0500)]
nfsd: clean up potential nfsd_file refcount leaks in COPY codepath
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 <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Jeff Layton [Tue, 17 Jan 2023 19:38:30 +0000 (14:38 -0500)]
nfsd: zero out pointers after putting nfsd_files on COPY setup error
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: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Wed, 18 Jan 2023 15:45:36 +0000 (10:45 -0500)]
SUNRPC: Fix whitespace damage in svcauth_unix.c
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Jeff Layton [Wed, 18 Jan 2023 17:31:39 +0000 (12:31 -0500)]
nfsd: eliminate __nfs4_get_fd
This is wrapper is pointless, and just obscures what's going on.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Jeff Layton [Wed, 18 Jan 2023 17:31:38 +0000 (12:31 -0500)]
nfsd: add some kerneldoc comments for stateid preprocessing functions
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Jeff Layton [Wed, 18 Jan 2023 17:31:35 +0000 (12:31 -0500)]
nfsd: eliminate find_deleg_file_locked
We really don't need an accessor function here.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Jeff Layton [Wed, 18 Jan 2023 17:31:34 +0000 (12:31 -0500)]
nfsd: don't take nfsd4_copy ref for OP_OFFLOAD_STATUS
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: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Olga Kornievskaia <kolga@netapp.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Sun, 15 Jan 2023 17:24:38 +0000 (12:24 -0500)]
SUNRPC: Add encryption self-tests
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>
Chuck Lever [Sun, 15 Jan 2023 17:24:31 +0000 (12:24 -0500)]
SUNRPC: Add RFC 8009 encryption KUnit tests
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>
Chuck Lever [Sun, 15 Jan 2023 17:24:25 +0000 (12:24 -0500)]
SUNRPC: Add RFC 8009 checksum KUnit tests
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>
Chuck Lever [Sun, 15 Jan 2023 17:24:18 +0000 (12:24 -0500)]
SUNRPC: Add KDF-HMAC-SHA2 Kunit tests
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>
Chuck Lever [Sun, 15 Jan 2023 17:24:12 +0000 (12:24 -0500)]
SUNRPC: Add encryption KUnit tests for the RFC 6803 encryption types
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>
Chuck Lever [Sun, 15 Jan 2023 17:24:06 +0000 (12:24 -0500)]
SUNRPC: Add checksum KUnit tests for the RFC 6803 encryption types
Test the new-to-RPCSEC CMAC digest algorithm.
Tested-by: Scott Mayhew <smayhew@redhat.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Sun, 15 Jan 2023 17:23:59 +0000 (12:23 -0500)]
SUNRPC: Add KDF KUnit tests for the RFC 6803 encryption types
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>
Chuck Lever [Sun, 15 Jan 2023 17:23:53 +0000 (12:23 -0500)]
SUNRPC: Add Kunit tests for RFC 3962-defined encryption/decryption
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>
Chuck Lever [Sun, 15 Jan 2023 17:23:47 +0000 (12:23 -0500)]
SUNRPC: Add KUnit tests RFC 3961 Key Derivation
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>
Chuck Lever [Sun, 15 Jan 2023 17:23:40 +0000 (12:23 -0500)]
SUNRPC: Export get_gss_krb5_enctype()
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>
Chuck Lever [Sun, 15 Jan 2023 17:23:34 +0000 (12:23 -0500)]
SUNRPC: Add KUnit tests for rpcsec_krb5.ko
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>
Chuck Lever [Sun, 15 Jan 2023 17:23:27 +0000 (12:23 -0500)]
SUNRPC: Move remaining internal definitions to gss_krb5_internal.h
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>
Chuck Lever [Sun, 15 Jan 2023 17:23:21 +0000 (12:23 -0500)]
SUNRPC: Advertise support for the Camellia encryption types
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>
Chuck Lever [Sun, 15 Jan 2023 17:23:15 +0000 (12:23 -0500)]
SUNRPC: Add KDF_FEEDBACK_CMAC
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>
Chuck Lever [Sun, 15 Jan 2023 17:23:08 +0000 (12:23 -0500)]
SUNRPC: Support the Camellia enctypes
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>
Chuck Lever [Sun, 15 Jan 2023 17:23:02 +0000 (12:23 -0500)]
SUNRPC: Advertise support for RFC 8009 encryption types
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>
Chuck Lever [Sun, 15 Jan 2023 17:22:56 +0000 (12:22 -0500)]
SUNRPC: Add RFC 8009 encryption and decryption functions
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>
Chuck Lever [Sun, 15 Jan 2023 17:22:49 +0000 (12:22 -0500)]
SUNRPC: Add KDF-HMAC-SHA2
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>
Chuck Lever [Sun, 15 Jan 2023 17:22:43 +0000 (12:22 -0500)]
SUNRPC: Add gk5e definitions for RFC 8009 encryption types
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>
Chuck Lever [Sun, 15 Jan 2023 17:22:36 +0000 (12:22 -0500)]
SUNRPC: Refactor CBC with CTS into helpers
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>
Chuck Lever [Sun, 15 Jan 2023 17:22:30 +0000 (12:22 -0500)]
SUNRPC: Add new subkey length fields
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>
Chuck Lever [Sun, 15 Jan 2023 17:22:24 +0000 (12:22 -0500)]
SUNRPC: Parametrize the key length passed to context_v2_alloc_cipher()
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>
Chuck Lever [Sun, 15 Jan 2023 17:22:17 +0000 (12:22 -0500)]
SUNRPC: Clean up cipher set up for v1 encryption types
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>
Chuck Lever [Sun, 15 Jan 2023 17:22:11 +0000 (12:22 -0500)]
SUNRPC: Hoist KDF into struct gss_krb5_enctype
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>
Chuck Lever [Sun, 15 Jan 2023 17:22:04 +0000 (12:22 -0500)]
SUNRPC: Rename .encrypt_v2 and .decrypt_v2 methods
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>
Chuck Lever [Sun, 15 Jan 2023 17:21:58 +0000 (12:21 -0500)]
SUNRPC: Remove ->encrypt and ->decrypt methods from struct gss_krb5_enctype
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>
Chuck Lever [Sun, 15 Jan 2023 17:21:52 +0000 (12:21 -0500)]
SUNRPC: Enable rpcsec_gss_krb5.ko to be built without CRYPTO_DES
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>
Chuck Lever [Sun, 15 Jan 2023 17:21:45 +0000 (12:21 -0500)]
SUNRPC: Replace KRB5_SUPPORTED_ENCTYPES macro
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>
Chuck Lever [Sun, 15 Jan 2023 17:21:39 +0000 (12:21 -0500)]
NFSD: Replace /proc/fs/nfsd/supported_krb5_enctypes with a symlink
Now that I've added a file under /proc/net/rpc that is managed by
the SunRPC's Kerberos mechanism, replace NFSD's
supported_krb5_enctypes file with a symlink to the new SunRPC proc
file, which contains exactly the same content.
Remarkably, commit
b0b0c0a26e84 ("nfsd: add proc file listing
kernel's gss_krb5 enctypes") added the nfsd_supported_krb5_enctypes
file in 2011, but this file has never been documented in nfsd(7).
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 [Sun, 15 Jan 2023 17:21:33 +0000 (12:21 -0500)]
SUNRPC: Add /proc/net/rpc/gss_krb5_enctypes file
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>
Chuck Lever [Sun, 15 Jan 2023 17:21:26 +0000 (12:21 -0500)]
SUNRPC: Remove another switch on ctx->enctype
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>
Chuck Lever [Sun, 15 Jan 2023 17:21:20 +0000 (12:21 -0500)]
SUNRPC: Refactor the GSS-API Per Message calls in the Kerberos mechanism
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>
Chuck Lever [Sun, 15 Jan 2023 17:21:13 +0000 (12:21 -0500)]
SUNRPC: Obscure Kerberos integrity keys
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>
Chuck Lever [Sun, 15 Jan 2023 17:21:07 +0000 (12:21 -0500)]
SUNRPC: Obscure Kerberos signing keys
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>
Chuck Lever [Sun, 15 Jan 2023 17:21:01 +0000 (12:21 -0500)]
SUNRPC: Obscure Kerberos encryption keys
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>
Chuck Lever [Sun, 15 Jan 2023 17:20:54 +0000 (12:20 -0500)]
SUNRPC: Refactor set-up for aux_cipher
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>
Chuck Lever [Sun, 15 Jan 2023 17:20:48 +0000 (12:20 -0500)]
SUNRPC: Obscure Kerberos session key
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 [Sun, 15 Jan 2023 17:20:41 +0000 (12:20 -0500)]
SUNRPC: Improve Kerberos confounder generation
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>
Chuck Lever [Sun, 15 Jan 2023 17:20:35 +0000 (12:20 -0500)]
SUNRPC: Remove .conflen field from struct gss_krb5_enctype
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>
Chuck Lever [Sun, 15 Jan 2023 17:20:28 +0000 (12:20 -0500)]
SUNRPC: Remove .blocksize field from struct gss_krb5_enctype
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>
Chuck Lever [Sun, 15 Jan 2023 17:20:22 +0000 (12:20 -0500)]
SUNRPC: Add header ifdefs to linux/sunrpc/gss_krb5.h
Standard convention: Ensure the contents of the header are included
only once per source file.
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 [Tue, 10 Jan 2023 15:32:00 +0000 (10:32 -0500)]
SUNRPC: Replace pool stats with per-CPU variables
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 <chuck.lever@oracle.com>
Chuck Lever [Tue, 10 Jan 2023 15:31:54 +0000 (10:31 -0500)]
SUNRPC: Use per-CPU counters to tally server RPC counts
- Improves counting accuracy
- Reduces cross-CPU memory traffic
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Jeff Layton [Wed, 11 Jan 2023 16:19:59 +0000 (11:19 -0500)]
nfsd: move reply cache initialization into nfsd startup
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 <chuck.lever@oracle.com>
Chuck Lever [Sun, 8 Jan 2023 16:31:11 +0000 (11:31 -0500)]
SUNRPC: Go back to using gsd->body_start
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>
Chuck Lever [Sun, 8 Jan 2023 16:31:05 +0000 (11:31 -0500)]
SUNRPC: Set rq_accept_statp inside ->accept methods
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>
Chuck Lever [Sun, 8 Jan 2023 16:30:59 +0000 (11:30 -0500)]
SUNRPC: Refactor RPC server dispatch method
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: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Sun, 8 Jan 2023 16:30:52 +0000 (11:30 -0500)]
SUNRPC: Remove no-longer-used helper functions
The svc_get/put helpers are no longer used.
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Sun, 8 Jan 2023 16:30:46 +0000 (11:30 -0500)]
SUNRPC: Final clean-up of svc_process_common()
The @resv parameter is no longer used.
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Sun, 8 Jan 2023 16:30:40 +0000 (11:30 -0500)]
SUNRPC: Convert RPC Reply header encoding to use xdr_stream
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: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Sun, 8 Jan 2023 16:30:34 +0000 (11:30 -0500)]
SUNRPC: Hoist init_encode out of svc_authenticate()
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>
Chuck Lever [Sun, 8 Jan 2023 16:30:28 +0000 (11:30 -0500)]
SUNRPC: Use xdr_stream for encoding GSS reply verifiers
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>
Chuck Lever [Sun, 8 Jan 2023 16:30:22 +0000 (11:30 -0500)]
SUNRPC: Use xdr_stream to encode replies in server-side GSS upcall helpers
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>
Chuck Lever [Sun, 8 Jan 2023 16:30:15 +0000 (11:30 -0500)]
SUNRPC: Convert unwrap data paths to use xdr_stream for replies
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>
Chuck Lever [Sun, 8 Jan 2023 16:30:09 +0000 (11:30 -0500)]
SUNRPC: Use xdr_stream to encode Reply verifier in svcauth_tls_accept()
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>
Chuck Lever [Sun, 8 Jan 2023 16:30:03 +0000 (11:30 -0500)]
SUNRPC: Use xdr_stream to encode Reply verifier in svcauth_unix_accept()
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>
Chuck Lever [Sun, 8 Jan 2023 16:29:57 +0000 (11:29 -0500)]
SUNRPC: Use xdr_stream to encode Reply verifier in svcauth_null_accept()
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>
Chuck Lever [Sun, 8 Jan 2023 16:29:51 +0000 (11:29 -0500)]
SUNRPC: Move svcxdr_init_encode() into ->accept methods
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>
Chuck Lever [Sun, 8 Jan 2023 16:29:44 +0000 (11:29 -0500)]
SUNRPC: Push svcxdr_init_encode() into svc_process_common()
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: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Sun, 8 Jan 2023 16:29:38 +0000 (11:29 -0500)]
SUNRPC: Add XDR encoding helper for opaque_auth
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: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Sun, 8 Jan 2023 16:29:32 +0000 (11:29 -0500)]
SUNRPC: Remove the rpc_stat variable in svc_process_common()
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: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Sun, 8 Jan 2023 16:29:26 +0000 (11:29 -0500)]
SUNRPC: Check rq_auth_stat when preparing to wrap a response
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>
Chuck Lever [Sun, 8 Jan 2023 16:29:20 +0000 (11:29 -0500)]
SUNRPC: Convert svcauth_gss_wrap_priv() to use xdr_stream()
Actually xdr_stream does not add value here because of how
gss_wrap() works. This is just a clean-up patch.
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Sun, 8 Jan 2023 16:29:14 +0000 (11:29 -0500)]
SUNRPC: Add @head and @tail variables in svcauth_gss_wrap_priv()
Simplify the references to the head and tail iovecs for readability.
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Sun, 8 Jan 2023 16:29:07 +0000 (11:29 -0500)]
SUNRPC: Record gss_wrap() errors in svcauth_gss_wrap_priv()
Match the error reporting in the other unwrap and wrap functions.
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Sun, 8 Jan 2023 16:29:01 +0000 (11:29 -0500)]
SUNRPC: Rename automatic variables in svcauth_gss_wrap_resp_priv()
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: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Sun, 8 Jan 2023 16:28:55 +0000 (11:28 -0500)]
SUNRPC: Convert svcauth_gss_wrap_integ() to use xdr_stream()
Done as part of hardening the server-side RPC header decoding path.
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Sun, 8 Jan 2023 16:28:49 +0000 (11:28 -0500)]
SUNRPC: Replace checksum construction in svcauth_gss_wrap_integ()
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: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Sun, 8 Jan 2023 16:28:42 +0000 (11:28 -0500)]
SUNRPC: Record gss_get_mic() errors in svcauth_gss_wrap_integ()
An error computing the checksum here is an exceptional event.
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Sun, 8 Jan 2023 16:28:36 +0000 (11:28 -0500)]
SUNRPC: Rename automatic variables in svcauth_gss_wrap_resp_integ()
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: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Sun, 8 Jan 2023 16:28:30 +0000 (11:28 -0500)]
SUNRPC: Clean up svcauth_gss_release()
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 <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>