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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8F866CDB465 for ; Mon, 16 Oct 2023 18:23:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233985AbjJPSXn (ORCPT ); Mon, 16 Oct 2023 14:23:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36742 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232996AbjJPSXm (ORCPT ); Mon, 16 Oct 2023 14:23:42 -0400 Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8B529A7 for ; Mon, 16 Oct 2023 11:23:39 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id d75a77b69052e-41808baf6abso32697371cf.3 for ; Mon, 16 Oct 2023 11:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20230601.gappssmtp.com; s=20230601; t=1697480618; x=1698085418; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=bOYKUfepen27nA77Lut7Ol5Mk35ukAs7DeLDiH//Idc=; b=de4VvUoFvw0Y4PUXnEuVIZ+IG+SfTc6AQFAKa3vRqxWnzVVq5GViJ5p9UbXntj1l/W 35NMXoJ+ZRGKbvOl+6AxNFrhA6drBvfW0b1zyOVgwwZDDEEyrvXUebG9Mb/KQQi3dhLQ raTYW68KKy2TT6p5cJlm5q5U7CzOCeOdVVVrSpZPGP2YpR8CdWf8kkt/Hrs7ii/YDPKS uEIxMWP1JGKCSgq+SwCf7l0y6EkitF58jY3sWshtY04XnZWxXE1a2N07OXHzWN+ljOwi RQybvEJgXEPIJoZ1A64IOWhTpJt/BHN/srXvcLEjrvC5udPA7v3yLtMiOGknMMYS7lly 2Xag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697480618; x=1698085418; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=bOYKUfepen27nA77Lut7Ol5Mk35ukAs7DeLDiH//Idc=; b=LfY8W9w8+z7mX9FHrk77MfkyggoVHYLyMljS922+zYIe0cqEJevdjPZKsV2KR857qx xOIP/IfKXkVRgHmlUTMNrlWCI5oTDhM1MSJTxLZXDnB21P2mEwdstR8PUgP1NT9WH191 mWqMqeYD+rKS1bdiIcp/Eu1OTcgs2Z8O8vTt8gNEpRbegaHDJwD9vhICnR6crr0VGuGv udpTqe6vaKGCc8XwW1u8kYvoZRsLmMxIbggbhIHSiMP5lPEAoVpf/edN3dwH9FhscGvw P0nfmGiTBDfqP7JMjQZJxRhuB0zftO+gOfhzUHAUiLbXHsAUGybLDAotwhT++cL5PHVW QZKQ== X-Gm-Message-State: AOJu0YwMSeaBfyHvDr9v8AA17zHgr2Dd9T8rxdTU/nF6LWZDujwIFZ6c YCPjHmwa/7x3KQtAlTnHQMmwjGjdWdUAzGzzn1LELA== X-Google-Smtp-Source: AGHT+IEQpPBSiUxhEN9mRav2a+h1a/IHbGlSqbmA8O4xF4Kfhllw0H35Ry808yTYySipDi6RpVt9NA== X-Received: by 2002:a05:622a:5c7:b0:410:9b45:d7ed with SMTP id d7-20020a05622a05c700b004109b45d7edmr132204qtb.56.1697480618693; Mon, 16 Oct 2023 11:23:38 -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 h4-20020ac87444000000b004179e79069asm3204261qtr.21.2023.10.16.11.23.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Oct 2023 11:23:38 -0700 (PDT) Date: Mon, 16 Oct 2023 14:23:37 -0400 From: Josef Bacik To: Eric Biggers Cc: linux-fscrypt@vger.kernel.org, linux-btrfs@vger.kernel.org Subject: Re: [PATCH] fscrypt: track master key presence separately from secret Message-ID: <20231016182337.GA2339326@perftesting> References: <20231015061055.62673-1-ebiggers@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231015061055.62673-1-ebiggers@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Sat, Oct 14, 2023 at 11:10:55PM -0700, Eric Biggers wrote: > From: Eric Biggers > > Master keys can be in one of three states: present, incompletely > removed, and absent (as per FSCRYPT_KEY_STATUS_* used in the UAPI). > Currently, the way that "present" is distinguished from "incompletely > removed" internally is by whether ->mk_secret exists or not. > > With extent-based encryption, it will be necessary to allow per-extent > keys to be derived while the master key is incompletely removed, so that > I/O on open files will reliably continue working after removal of the > key has been initiated. (We could allow I/O to sometimes fail in that > case, but that seems problematic for reasons such as writes getting > silently thrown away and diverging from the existing fscrypt semantics.) > Therefore, when the filesystem is using extent-based encryption, > ->mk_secret can't be wiped when the key becomes incompletely removed. > > As a prerequisite for doing that, this patch makes the "present" state > be tracked using a new field, ->mk_present. No behavior is changed yet. > > The basic idea here is borrowed from Josef Bacik's patch > "fscrypt: use a flag to indicate that the master key is being evicted" > (https://lore.kernel.org/r/e86c16dddc049ff065f877d793ad773e4c6bfad9.1696970227.git.josef@toxicpanda.com). > I reimplemented it using a "present" bool instead of an "evicted" flag, > fixed a couple bugs, and tried to update everything to be consistent. > > Note: I considered adding a ->mk_status field instead, holding one of > FSCRYPT_KEY_STATUS_*. At first that seemed nice, but it ended up being > more complex (despite simplifying FS_IOC_GET_ENCRYPTION_KEY_STATUS), > since it would have introduced redundancy and had weird locking rules. > > Signed-off-by: Eric Biggers Based my fscrypt patches ontop of this one, ran tests with both btrfs and ext4 with it applied, in addition to my normal review stuff. You can add Reviewed-by: Josef Bacik Thanks, Josef