From patchwork Tue Oct 10 20:40:17 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 13416098 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 68D7ECD8CBF for ; Tue, 10 Oct 2023 20:41:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234410AbjJJUlP (ORCPT ); Tue, 10 Oct 2023 16:41:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55198 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234244AbjJJUlI (ORCPT ); Tue, 10 Oct 2023 16:41:08 -0400 Received: from mail-yw1-x112a.google.com (mail-yw1-x112a.google.com [IPv6:2607:f8b0:4864:20::112a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0E5468E for ; Tue, 10 Oct 2023 13:41:07 -0700 (PDT) Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-5a7c7262d5eso11146907b3.1 for ; Tue, 10 Oct 2023 13:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20230601.gappssmtp.com; s=20230601; t=1696970466; x=1697575266; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:from:to:cc:subject:date:message-id :reply-to; bh=fkPDGYDbzsyT2iviorbG84fmLsSBIDBYGMivDDhcaSA=; b=Fw12OkQzJz1RqOIy5OpR4Cy7l7SIn84viBkp36/p04qC2CLP6ebe34hP9ZoxPltmEd pVn1HTMK3VTJIxIr4J5fT3wVDrLvSBPx7tzV9AKA/aRVRc0qE3X9+RPT3Kt4rBj/SqZy sknmKjtZedi63p56frXZy/tZYILauVt+Ibl96h8Kuw9r+ZjJ1GDVQn7wZpUIlJX+D5qV zBHa9yHrL+uc6wrWDDnsWXrLQvCy7MHfnKhYBPEsPPoOUtShOx2wuZP75hITrWbrRxcu Brs/s7KGnbDCNM5h/IfZL+xzF/FvkCi85wHQZxo17HN2X1OlTmyZIWq4hRqtd0vrKr0d oSOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696970466; x=1697575266; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fkPDGYDbzsyT2iviorbG84fmLsSBIDBYGMivDDhcaSA=; b=wSILDIDPNu1cSxlM7z8kJalkCET5Qv8f3F/77XPcPByTW2ZgtKFnkRqkxLwgOBQoDb d3eN36KnTp39TDB8eeWEXaThorPz1axVck2XVuKjzmVz8XxJaayMS4YYTa6u+teP12fp 8QpvpEkYmIiSMerJHpVRiXCHZqVuCMBc60Tbx4XkvV5KAdsti1hk5w89di61hoa0NbFh nktS1d83tJmdGSVD1ZWJyjhdmyCo7BrjOy61tYlb0OsNGbbPeOlPw/rrz3JCLDQvktyH Htbz4W6QfQxKCenEX/LsL3hlcHDerDJnCHTXO+o6DxVC+JoPRi/zfDaAqRMVZkXWEPsR 9d+Q== X-Gm-Message-State: AOJu0YxzUSyQQPBEBMQLull55jxDOVP9F0XbIMK3ULJTjAHFw8rwbM5f H6+m5JmvwORXWBdxCK/PuFx6JjD4G2HSkArNRE9viQ== X-Google-Smtp-Source: AGHT+IF3+989+mVbsCnTHYZ6gvtzCY6x1ia4u7mwISczqB7A5h4+dXkdgsfoaI3v75hIIbv4o4zN9Q== X-Received: by 2002:a81:6f85:0:b0:569:e7cb:cd4e with SMTP id k127-20020a816f85000000b00569e7cbcd4emr18009889ywc.48.1696970466174; Tue, 10 Oct 2023 13:41:06 -0700 (PDT) Received: from localhost (cpe-76-182-20-124.nc.res.rr.com. [76.182.20.124]) by smtp.gmail.com with ESMTPSA id c65-20020a0df344000000b005925765aa30sm4697589ywf.135.2023.10.10.13.41.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Oct 2023 13:41:05 -0700 (PDT) From: Josef Bacik To: linux-fscrypt@vger.kernel.org, ebiggers@kernel.org, linux-btrfs@vger.kernel.org Subject: [PATCH v2 02/36] fscrypt: don't wipe mk secret until the last active user is gone Date: Tue, 10 Oct 2023 16:40:17 -0400 Message-ID: X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org Previously we were wiping the master key secret when we do FS_IOC_REMOVE_ENCRYPTION_KEY, and then using the fact that it was cleared as the mechanism from keeping new users from being setup. This works with inode based encryption, as the per-inode key is derived at setup time, so the secret disappearing doesn't affect any currently open files from being able to continue working. However for extent based encryption we do our key derivation at page writeout and readpage time, which means we need the master key secret to be available while we still have our file open. Since the master key lifetime is controlled by a flag, move the clearing of the secret to the mk_active_users cleanup stage. This counter represents the actively open files that still exist on the file system, and thus should still be able to operate normally. Once the last user is closed we can clear the secret. Until then no new users are allowed, and this allows currently open files to continue to operate until they're closed. Signed-off-by: Josef Bacik --- fs/crypto/keyring.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/crypto/keyring.c b/fs/crypto/keyring.c index e0e311ed6b88..31ea81d97075 100644 --- a/fs/crypto/keyring.c +++ b/fs/crypto/keyring.c @@ -116,6 +116,7 @@ void fscrypt_put_master_key_activeref(struct super_block *sb, memzero_explicit(&mk->mk_ino_hash_key, sizeof(mk->mk_ino_hash_key)); mk->mk_ino_hash_key_initialized = false; + wipe_master_key_secret(&mk->mk_secret); /* Drop the structural ref associated with the active refs. */ fscrypt_put_master_key(mk); @@ -245,7 +246,6 @@ void fscrypt_destroy_keyring(struct super_block *sb) WARN_ON_ONCE(refcount_read(&mk->mk_active_refs) != 1); WARN_ON_ONCE(refcount_read(&mk->mk_struct_refs) != 1); WARN_ON_ONCE(!is_master_key_secret_present(mk)); - wipe_master_key_secret(&mk->mk_secret); set_bit(FSCRYPT_MK_FLAG_EVICTED, &mk->mk_flags); fscrypt_put_master_key_activeref(sb, mk); } @@ -1064,7 +1064,6 @@ static int do_remove_key(struct file *filp, void __user *_uarg, bool all_users) /* No user claims remaining. Go ahead and wipe the secret. */ err = -ENOKEY; if (!test_and_set_bit(FSCRYPT_MK_FLAG_EVICTED, &mk->mk_flags)) { - wipe_master_key_secret(&mk->mk_secret); fscrypt_put_master_key_activeref(sb, mk); err = 0; }