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 9C785C77B75 for ; Fri, 5 May 2023 22:40:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233502AbjEEWka (ORCPT ); Fri, 5 May 2023 18:40:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50316 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233400AbjEEWk3 (ORCPT ); Fri, 5 May 2023 18:40:29 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3A59449C5 for ; Fri, 5 May 2023 15:40:28 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C2A32640F7 for ; Fri, 5 May 2023 22:40:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1BB56C433D2; Fri, 5 May 2023 22:40:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1683326427; bh=2kcbvZ3vtrJvQVF2SOpsg65QX8fpckWqOctBUmyn0Rg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=vBFqotkVmMQOvFGOyirD39HUqWhJQHDPFw6+pnik7KJXBJa7aA05+G4qj+dXcdC5f 6u8EJWPgmdIUI8R+ApeSVZE9sjHsCHEDhYovzUj48n2o6qV7rcXH6wvVInAIB2DSsj 8aVcM91Mr74vf46AMyykA1TkA3oV3eseBdfX9sOeEnAZAbNHwC38e68ktQE2P9h7dy dYYVZccozLNaSJOZo9OBH8o8QuYc4ovIrjj+JCLYbutrqCLSfoEG8WeIU4mFqwF0DA gQZ1f8zEhsInDNLWXn4LyEFdhQnJ1UqbP3eZeMIHuaGN4q1JpkEbsQtabSkh4lxAq6 oEW3Ag+7gPPVg== Date: Fri, 5 May 2023 22:40:13 +0000 From: Eric Biggers To: Sweet Tea Dorminy Cc: "Theodore Y. Ts'o" , Jaegeuk Kim , linux-fscrypt@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH v1 0/7] fscrypt: add pooled prepared keys facility Message-ID: References: <20230502034736.GA1131@sol.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org On Fri, May 05, 2023 at 08:15:44AM -0400, Sweet Tea Dorminy wrote: > > > As I mentioned earlier > > (https://lore.kernel.org/r/Y7NQ1CvPyJiGRe00@sol.localdomain), > > blk-crypto-fallback actually already solved the problem of caching > > crypto_skcipher objects for I/O. And, it's possible for a filesystem to *only* > > support blk-crypto, not filesystem-layer contents encryption. You'd just need > > to put btrfs encryption behind a new kconfig option that is automatically > > selected by CONFIG_FS_ENCRYPTION_INLINE_CRYPT && CONFIG_BLK_ENCRYPTION_FALLBACK. > > > > (BTW, I'm thinking of simplifying the kconfig options by removing > > CONFIG_FS_ENCRYPTION_INLINE_CRYPT. Then, the blk-crypto code in fs/crypto/ will > > be built if CONFIG_FS_ENCRYPTION && CONFIG_BLK_INLINE_ENCRYPTION.) > > > > Indeed, filesystem-layer contents encryption is a bit redundant these days now > > that blk-crypto-fallback exists. I'm even tempted to make ext4 and f2fs support > > blk-crypto only someday. That was sort of the original plan, actually... > > > > So, I'm wondering if you've considered going the blk-crypto-fallback route? > > I did, and gave it a shot, but ran into problems because as far as I can > tell it requires having a bio to crypt. For verity data and inline extents, > there's no obvious bio, and even if we tried to construct a bio pointing at > the relevant data, it's not necessarily sector- sized or aligned. I couldn't > figure out a good way to make it work, but maybe it's better to special-case > those or there's something I'm not seeing. ext4 and f2fs just don't use inline data on encrypted files. I.e. when an encrypted file is created, it always uses non-inline data. Is that an option for btrfs? For the verity metadata, how are you thinking of encrypting it, exactly? Verity metadata is immutable once written, so surely it avoids many of the issues you are dealing with for extents? It should just need one key, and that key could be set up at file open time. So I don't think it will need the key pool at all? - Eric