From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 079E0C2D0A3 for ; Sun, 1 Nov 2020 10:38:53 +0000 (UTC) Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 939DF2072C; Sun, 1 Nov 2020 10:38:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sourceforge.net header.i=@sourceforge.net header.b="cB9+hGEY"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sf.net header.i=@sf.net header.b="Zw97YLw7"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="kPR8/IsR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 939DF2072C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-f2fs-devel-bounces@lists.sourceforge.net Received: from [127.0.0.1] (helo=sfs-ml-2.v29.lw.sourceforge.com) by sfs-ml-2.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1kZAlA-0000cT-4L; Sun, 01 Nov 2020 10:38:52 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-2.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZAl5-0000c2-TG for linux-f2fs-devel@lists.sourceforge.net; Sun, 01 Nov 2020 10:38:47 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version :Message-ID:In-Reply-To:Date:From:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=5vV/MzwUqfYzvPEnGT2rWnTYNY03TKOcxKp5gpBZd6U=; b=cB9+hGEY0i6cKXu04nwkB8tdam rEbC63vLzim3SZ9KccEYrypYtnQwerVHkNBfuEZZl/9nSC0hqZ6fXGS0RAuaMFy4+xlkYHKR6X1g6 jjM7jHqlbCq0BfmZdJSjA9PKi5+WKV/RWyfzcZ9R+0mAJ8dauzVWk1Xf3hot3DGzbZoc=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:From:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=5vV/MzwUqfYzvPEnGT2rWnTYNY03TKOcxKp5gpBZd6U=; b=Zw97YLw7CzeEqW0WQJcYLoWlQn V/ZdOHoTmkysDyBaS298ocYMgmMG7uC70sty1CyXj43sSFew04LGXMC+6/6uzrYOQG6kXCjAFooit RoBAthLDyLBbRjEZo5+MyieNU8Ehsbmp6uFowJ6F3Yb9GvP8ti6ORzdrI6iAh5gyCDHA=; Received: from mail.kernel.org ([198.145.29.99]) by sfi-mx-3.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) id 1kZAkz-00FAYH-0p for linux-f2fs-devel@lists.sourceforge.net; Sun, 01 Nov 2020 10:38:47 +0000 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2A0342072C; Sun, 1 Nov 2020 10:38:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604227102; bh=S2B1OU5saTu5WgIQoA1aP/CQTnc+dvCPHLM2+ciLpcQ=; h=Subject:To:Cc:From:Date:In-Reply-To:From; b=kPR8/IsRJt/u2NJehNzs5zseRCIxGlHSq7mAfH5mN+kQPqxJV1Ge+VjgkDWQjIwL4 H2xJ4jM44u9iznH3L4UtwSpKrx9eBUDpftHMUoqZX44CiY+UezpvkxSlv01RnLqSIk ga7EXFd0ByzH+EaXTSGAas7ZC7OhcCc5xxzG7EoA= To: ebiggers@google.com, ebiggers@kernel.org, gregkh@linuxfoundation.org, linux-f2fs-devel@lists.sourceforge.net, linux-mtd@lists.infradead.org, tytso@mit.edu From: Date: Sun, 01 Nov 2020 11:39:02 +0100 In-Reply-To: <20201031220553.1085782-2-ebiggers@kernel.org> Message-ID: <1604227142207110@kroah.com> MIME-Version: 1.0 X-stable: commit X-Patchwork-Hint: ignore X-Headers-End: 1kZAkz-00FAYH-0p Subject: [f2fs-dev] Patch "fscrypt: clean up and improve dentry revalidation" has been added to the 4.19-stable tree X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: stable-commits@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net This is a note to let you know that I've just added the patch titled fscrypt: clean up and improve dentry revalidation to the 4.19-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: fscrypt-clean-up-and-improve-dentry-revalidation.patch and it can be found in the queue-4.19 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >From foo@baz Sun Nov 1 11:35:18 AM CET 2020 From: Eric Biggers Date: Sat, 31 Oct 2020 15:05:49 -0700 Subject: fscrypt: clean up and improve dentry revalidation To: stable@vger.kernel.org Cc: linux-fscrypt@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-mtd@lists.infradead.org, Theodore Ts'o Message-ID: <20201031220553.1085782-2-ebiggers@kernel.org> From: Eric Biggers commit 6cc248684d3d23bbd073ae2fa73d3416c0558909 upstream. Make various improvements to fscrypt dentry revalidation: - Don't try to handle the case where the per-directory key is removed, as this can't happen without the inode (and dentries) being evicted. - Flag ciphertext dentries rather than plaintext dentries, since it's ciphertext dentries that need the special handling. - Avoid doing unnecessary work for non-ciphertext dentries. - When revalidating ciphertext dentries, try to set up the directory's i_crypt_info to make sure the key is really still absent, rather than invalidating all negative dentries as the previous code did. An old comment suggested we can't do this for locking reasons, but AFAICT this comment was outdated and it actually works fine. Signed-off-by: Eric Biggers Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman --- fs/crypto/crypto.c | 58 ++++++++++++++++++++++++------------------------ fs/crypto/hooks.c | 4 +-- include/linux/dcache.h | 2 - include/linux/fscrypt.h | 6 +--- 4 files changed, 35 insertions(+), 35 deletions(-) --- a/fs/crypto/crypto.c +++ b/fs/crypto/crypto.c @@ -314,45 +314,47 @@ int fscrypt_decrypt_page(const struct in EXPORT_SYMBOL(fscrypt_decrypt_page); /* - * Validate dentries for encrypted directories to make sure we aren't - * potentially caching stale data after a key has been added or - * removed. + * Validate dentries in encrypted directories to make sure we aren't potentially + * caching stale dentries after a key has been added. */ static int fscrypt_d_revalidate(struct dentry *dentry, unsigned int flags) { struct dentry *dir; - int dir_has_key, cached_with_key; + int err; + int valid; + + /* + * Plaintext names are always valid, since fscrypt doesn't support + * reverting to ciphertext names without evicting the directory's inode + * -- which implies eviction of the dentries in the directory. + */ + if (!(dentry->d_flags & DCACHE_ENCRYPTED_NAME)) + return 1; + + /* + * Ciphertext name; valid if the directory's key is still unavailable. + * + * Although fscrypt forbids rename() on ciphertext names, we still must + * use dget_parent() here rather than use ->d_parent directly. That's + * because a corrupted fs image may contain directory hard links, which + * the VFS handles by moving the directory's dentry tree in the dcache + * each time ->lookup() finds the directory and it already has a dentry + * elsewhere. Thus ->d_parent can be changing, and we must safely grab + * a reference to some ->d_parent to prevent it from being freed. + */ if (flags & LOOKUP_RCU) return -ECHILD; dir = dget_parent(dentry); - if (!IS_ENCRYPTED(d_inode(dir))) { - dput(dir); - return 0; - } - - spin_lock(&dentry->d_lock); - cached_with_key = dentry->d_flags & DCACHE_ENCRYPTED_WITH_KEY; - spin_unlock(&dentry->d_lock); - dir_has_key = (d_inode(dir)->i_crypt_info != NULL); + err = fscrypt_get_encryption_info(d_inode(dir)); + valid = !fscrypt_has_encryption_key(d_inode(dir)); dput(dir); - /* - * If the dentry was cached without the key, and it is a - * negative dentry, it might be a valid name. We can't check - * if the key has since been made available due to locking - * reasons, so we fail the validation so ext4_lookup() can do - * this check. - * - * We also fail the validation if the dentry was created with - * the key present, but we no longer have the key, or vice versa. - */ - if ((!cached_with_key && d_is_negative(dentry)) || - (!cached_with_key && dir_has_key) || - (cached_with_key && !dir_has_key)) - return 0; - return 1; + if (err < 0) + return err; + + return valid; } const struct dentry_operations fscrypt_d_ops = { --- a/fs/crypto/hooks.c +++ b/fs/crypto/hooks.c @@ -101,9 +101,9 @@ int __fscrypt_prepare_lookup(struct inod if (err) return err; - if (fscrypt_has_encryption_key(dir)) { + if (!fscrypt_has_encryption_key(dir)) { spin_lock(&dentry->d_lock); - dentry->d_flags |= DCACHE_ENCRYPTED_WITH_KEY; + dentry->d_flags |= DCACHE_ENCRYPTED_NAME; spin_unlock(&dentry->d_lock); } --- a/include/linux/dcache.h +++ b/include/linux/dcache.h @@ -210,7 +210,7 @@ struct dentry_operations { #define DCACHE_MAY_FREE 0x00800000 #define DCACHE_FALLTHRU 0x01000000 /* Fall through to lower layer */ -#define DCACHE_ENCRYPTED_WITH_KEY 0x02000000 /* dir is encrypted with a valid key */ +#define DCACHE_ENCRYPTED_NAME 0x02000000 /* Encrypted name (dir key was unavailable) */ #define DCACHE_OP_REAL 0x04000000 #define DCACHE_PAR_LOOKUP 0x10000000 /* being looked up (with parent locked shared) */ --- a/include/linux/fscrypt.h +++ b/include/linux/fscrypt.h @@ -145,10 +145,8 @@ static inline int fscrypt_prepare_rename * filenames are presented in encrypted form. Therefore, we'll try to set up * the directory's encryption key, but even without it the lookup can continue. * - * To allow invalidating stale dentries if the directory's encryption key is - * added later, we also install a custom ->d_revalidate() method and use the - * DCACHE_ENCRYPTED_WITH_KEY flag to indicate whether a given dentry is a - * plaintext name (flag set) or a ciphertext name (flag cleared). + * This also installs a custom ->d_revalidate() method which will invalidate the + * dentry if it was created without the key and the key is later added. * * Return: 0 on success, -errno if a problem occurred while setting up the * encryption key Patches currently in stable-queue which might be from ebiggers@kernel.org are queue-4.19/fscrypt-only-set-dentry_operations-on-ciphertext-dentries.patch queue-4.19/fscrypt-clean-up-and-improve-dentry-revalidation.patch queue-4.19/fscrypt-fix-race-allowing-rename-and-link-of-ciphertext-dentries.patch queue-4.19/fs-fscrypt-clear-dcache_encrypted_name-when-unaliasing-directory.patch queue-4.19/fscrypt-fix-race-where-lookup-marks-plaintext-dentry-as-ciphertext.patch _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel