From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8951C23A99F; Fri, 15 May 2026 18:41:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778870494; cv=none; b=sUbmqVX3QbrVv4pkzi7FQMwhllA5GCZDvnDUEAmxqI17udwbRZxLe/CLWT32Qb3t9C8X2B+N0bOXp5ZGaIMjbjzj9if9/krQ3Tqv8ask7NgtVcBfxMiWDKD1XZpP+WtIwpPTuN0BN1uNqbsXFrSiYBSam820rUl2zK6PuJah3x0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778870494; c=relaxed/simple; bh=GwivGZO8Wm6h0va9M4mOP/dflJKHX49qqSGVDT/xeJI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ki3iqE867ZUwJOdUD1p5EXhBLTSykrOZdK+pSMIKTqb4MLQoqAfzSBMh5llZSy/RG0URHFO0xaO4oteqFkaWDxBU9QQnRWxqLI3jq7B/SSXU1X4/Cd0FmVhyRYOD1zgsxrRhozd7ahhBb4gMSjBAf85IXTHF4CMR/OnrE2vQK4g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dQAgJ68J; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="dQAgJ68J" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 144C5C2BCB0; Fri, 15 May 2026 18:41:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778870492; bh=GwivGZO8Wm6h0va9M4mOP/dflJKHX49qqSGVDT/xeJI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dQAgJ68JBJiEVYcWN4KUfoFOjI43S8lEmAduuVLNtLsWgJCkCJUESQKxYZzxS4FPG 6r4b0sekFeMfqq6CecYHs/3GGSFY11ojQC5SPUUX48cjQDLvPKcA6RggznQ5UIw378 gkBEh8QdYrxHdqGBC7FENxInFyJNa07gtI5npZhFWAZ+ZOOAHSIh6dsnoK4DRayLb9 xc6guYJ30CVzhDg9jk5AYfWOfo1iH5P4jT21xVAP03kLnMQ64oxvS9KnvsYN2sy7Mi aPVkBTySkovP47fajmYy7NH2X/xnGPIY/wGLqXeRZMK1PNEBcXiPJqO9kmrFkftM7r oY58+9YIUJLlA== Date: Fri, 15 May 2026 11:41:24 -0700 From: Eric Biggers To: LiaoYuanhong-vivo Cc: Jaegeuk Kim , Chao Yu , Jonathan Corbet , Shuah Khan , "Theodore Y. Ts'o" , "open list:F2FS FILE SYSTEM" , open list , "open list:DOCUMENTATION" , "open list:FSCRYPT: FILE SYSTEM LEVEL ENCRYPTION SUPPORT" Subject: Re: [PATCH 0/3] f2fs: support encrypted inline data Message-ID: <20260515184124.GA4903@quark> References: <20260513100431.299904-1-liaoyuanhong@vivo.com> Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260513100431.299904-1-liaoyuanhong@vivo.com> On Wed, May 13, 2026 at 06:04:27PM +0800, LiaoYuanhong-vivo wrote: > From: Liao Yuanhong > > F2FS currently avoids inline data for encrypted regular files. This is > because inline data is stored in the inode block, outside the regular > bio-based data path where fscrypt and blk-crypto normally operate. > As a result, devices that enable blk-crypto for encrypted file contents > cannot use F2FS inline data for encrypted regular files, which wastes > space for small files. > > This series adds support for keeping small encrypted regular-file > contents as inline data. The f2fs side defines a new on-disk feature, > encrypted_inline_data, under which inline payloads of encrypted regular > files are interpreted as ciphertext. The payload is encrypted before > being stored in the inode block and decrypted back into page-cache > plaintext on read. > > The fscrypt side prepares a software contents-key transform even when > normal file contents use blk-crypto, so filesystems can encrypt > filesystem-managed data regions that do not go through bio submission. > The new fscrypt helper operates on fscrypt data units and leaves the > filesystem responsible for deciding which filesystem-managed byte ranges > need this treatment. > > The software crypto operation is limited to the inline payload. Since > these files are small enough to remain inline, the expected read/write > performance difference between hardware and software crypto is small, > while the space saving from keeping the data inline is significant. > > The feature is guarded by CONFIG_F2FS_FS_ENCRYPTED_INLINE_DATA and by the > F2FS encrypted_inline_data on-disk feature bit. Filesystems with this > feature set are rejected if the kernel lacks the config option. > > Hardware-wrapped keys are not supported by this initial version. I would > like to discuss whether this feature should remain disabled for > hardware-wrapped keys, or whether there is an acceptable way to support the > combination in the future. > > The f2fs-tools support for formatting filesystems with this feature will be > submitted separately. > > Basic testing passed. Encrypted small files can be kept as inline data, > and read/write verification succeeded. Honestly, I'm not convinced this is worth the complexity and the additional memory use. First, it works only in the combination: 'f2fs && inlinecrypt && !hw_wrapped_keys'. That really limits how many users would use this. 'f2fs && inlinecrypt' de facto targets it to Android devices rather than "regular" Linux systems. But at the same time, the "best practice" on such devices is to use HW-wrapped keys, which has already been widely adopted. So this would be useful only on devices where the SoC doesn't support HW-wrapped keys. Its usefulness will go away when support for HW-wrapped keys is added. Second, in the per-file key case this makes every file use an additional 1 KiB of memory or so (assuming AES-XTS) to hold the "software key", just in case the file ever has inline data. That seems problematic, and maybe not a great direction to be going in right now, given the ongoing RAM shortage. There also seem to be quite a few bugs/issues. Sashiko found quite a few (https://sashiko.dev/#/message/20260513100431.299904-1-liaoyuanhong%40vivo.com). But just from a quick readthrough, anything that calls fscrypt_is_key_prepared() seems to be broken now, as that function isn't aware that both fields of fscrypt_prepared_key can be needed. I'm also not seeing what differentiates the new fscrypt_{en,decrypt}_data_unit_inplace() from the existing fscrypt_{en,decrypt}_block_inplace(). They seem redundant. There's already a lot of complexity in fscrypt, with the different settings and the different ways the filesystems do en/decryption. With this, plus the concurrent work to add support for extent-based encryption (for btrfs), it's really quite hard to keep track of everything. So I have to wonder if this patchset is really worth it. So, overall, I think this would need a bit more work. But also I'm wondering if it's actually worthwhile. Do you plan to never enable HW-wrapped keys, for example? And you're fine with using more RAM? - Eric 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 6EDE2CD343F for ; Fri, 15 May 2026 18:41:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.sourceforge.net; s=beta; h=Content-Transfer-Encoding:Content-Type:Cc: Reply-To:From:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Subject:In-Reply-To:MIME-Version:References: Message-ID:To:Date:Sender:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=HwAUlAa1Imc5Te/mFwalqIkTsMzHjJoD2yPh1g1lUS0=; b=h1/tpnF4Z/aTeyAMjihLJYLwL3 fWT8GFlryA7k0hQ0nFaARyPUg0ro6hKzABlG2ah3X8xUvGYD8OTUA3qpHTkvGshYHyn2Ns3rVhOPQ MW0GHNAsvOiJXY+KhaS7eM3nlyKyxy9WyoIyertOJ+kyJHKRXIAMOIw9Mspu/bBU0btA=; Received: from [127.0.0.1] (helo=sfs-ml-3.v29.lw.sourceforge.com) by sfs-ml-3.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1wNxTl-0000ED-Vv; Fri, 15 May 2026 18:41:46 +0000 Received: from [172.30.29.66] (helo=mx.sourceforge.net) by sfs-ml-3.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1wNxTk-0000E4-65 for linux-f2fs-devel@lists.sourceforge.net; Fri, 15 May 2026 18:41:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=cP+f2o6kMyOQtDwdZGxSxYvNyEezGmEGO/I+oxNfelk=; b=PTe4evJYUXRStWGecNGhXLPJ3r /Q3WStsIE7dRmSg2LYpfvTE8n9xJVE2bSeKY2H2dlNX96ZW7r2JsifT7vd5Lct9nLCeWZifS+8+cH cFNmEkz9rN7ZD2+xxriVuDidcCqL9WQgv824V5Ui6gCjk4qPVogpRss/wjBO57C5qlh0=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=cP+f2o6kMyOQtDwdZGxSxYvNyEezGmEGO/I+oxNfelk=; b=JmMB+jIfN6smrqD/uz9rkErBfy a5nQYLDri8jR5xhg1oKI77SYkEjdS9GL+GB/3sRpGFtgXq8s2un6Zw6inwmzjjfvvZCYFzsUJMpuG Sz2n70Fb5Eymeq+8x5e0+4rPKzX2UJ7BemjhGV4xmp5N81IgdF6JgQfNvfLmqraWb+VU=; Received: from sea.source.kernel.org ([172.234.252.31]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1wNxTi-0007na-TG for linux-f2fs-devel@lists.sourceforge.net; Fri, 15 May 2026 18:41:44 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id E20C043524; Fri, 15 May 2026 18:41:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 144C5C2BCB0; Fri, 15 May 2026 18:41:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778870492; bh=GwivGZO8Wm6h0va9M4mOP/dflJKHX49qqSGVDT/xeJI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dQAgJ68JBJiEVYcWN4KUfoFOjI43S8lEmAduuVLNtLsWgJCkCJUESQKxYZzxS4FPG 6r4b0sekFeMfqq6CecYHs/3GGSFY11ojQC5SPUUX48cjQDLvPKcA6RggznQ5UIw378 gkBEh8QdYrxHdqGBC7FENxInFyJNa07gtI5npZhFWAZ+ZOOAHSIh6dsnoK4DRayLb9 xc6guYJ30CVzhDg9jk5AYfWOfo1iH5P4jT21xVAP03kLnMQ64oxvS9KnvsYN2sy7Mi aPVkBTySkovP47fajmYy7NH2X/xnGPIY/wGLqXeRZMK1PNEBcXiPJqO9kmrFkftM7r oY58+9YIUJLlA== Date: Fri, 15 May 2026 11:41:24 -0700 To: LiaoYuanhong-vivo Message-ID: <20260515184124.GA4903@quark> References: <20260513100431.299904-1-liaoyuanhong@vivo.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20260513100431.299904-1-liaoyuanhong@vivo.com> X-Headers-End: 1wNxTi-0007na-TG Subject: Re: [f2fs-dev] [PATCH 0/3] f2fs: support encrypted inline data 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: , From: Eric Biggers via Linux-f2fs-devel Reply-To: Eric Biggers Cc: "Theodore Y. Ts'o" , Jonathan Corbet , "open list:DOCUMENTATION" , open list , "open list:F2FS FILE SYSTEM" , "open list:FSCRYPT: FILE SYSTEM LEVEL ENCRYPTION SUPPORT" , Shuah Khan , Jaegeuk Kim Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On Wed, May 13, 2026 at 06:04:27PM +0800, LiaoYuanhong-vivo wrote: > From: Liao Yuanhong > > F2FS currently avoids inline data for encrypted regular files. This is > because inline data is stored in the inode block, outside the regular > bio-based data path where fscrypt and blk-crypto normally operate. > As a result, devices that enable blk-crypto for encrypted file contents > cannot use F2FS inline data for encrypted regular files, which wastes > space for small files. > > This series adds support for keeping small encrypted regular-file > contents as inline data. The f2fs side defines a new on-disk feature, > encrypted_inline_data, under which inline payloads of encrypted regular > files are interpreted as ciphertext. The payload is encrypted before > being stored in the inode block and decrypted back into page-cache > plaintext on read. > > The fscrypt side prepares a software contents-key transform even when > normal file contents use blk-crypto, so filesystems can encrypt > filesystem-managed data regions that do not go through bio submission. > The new fscrypt helper operates on fscrypt data units and leaves the > filesystem responsible for deciding which filesystem-managed byte ranges > need this treatment. > > The software crypto operation is limited to the inline payload. Since > these files are small enough to remain inline, the expected read/write > performance difference between hardware and software crypto is small, > while the space saving from keeping the data inline is significant. > > The feature is guarded by CONFIG_F2FS_FS_ENCRYPTED_INLINE_DATA and by the > F2FS encrypted_inline_data on-disk feature bit. Filesystems with this > feature set are rejected if the kernel lacks the config option. > > Hardware-wrapped keys are not supported by this initial version. I would > like to discuss whether this feature should remain disabled for > hardware-wrapped keys, or whether there is an acceptable way to support the > combination in the future. > > The f2fs-tools support for formatting filesystems with this feature will be > submitted separately. > > Basic testing passed. Encrypted small files can be kept as inline data, > and read/write verification succeeded. Honestly, I'm not convinced this is worth the complexity and the additional memory use. First, it works only in the combination: 'f2fs && inlinecrypt && !hw_wrapped_keys'. That really limits how many users would use this. 'f2fs && inlinecrypt' de facto targets it to Android devices rather than "regular" Linux systems. But at the same time, the "best practice" on such devices is to use HW-wrapped keys, which has already been widely adopted. So this would be useful only on devices where the SoC doesn't support HW-wrapped keys. Its usefulness will go away when support for HW-wrapped keys is added. Second, in the per-file key case this makes every file use an additional 1 KiB of memory or so (assuming AES-XTS) to hold the "software key", just in case the file ever has inline data. That seems problematic, and maybe not a great direction to be going in right now, given the ongoing RAM shortage. There also seem to be quite a few bugs/issues. Sashiko found quite a few (https://sashiko.dev/#/message/20260513100431.299904-1-liaoyuanhong%40vivo.com). But just from a quick readthrough, anything that calls fscrypt_is_key_prepared() seems to be broken now, as that function isn't aware that both fields of fscrypt_prepared_key can be needed. I'm also not seeing what differentiates the new fscrypt_{en,decrypt}_data_unit_inplace() from the existing fscrypt_{en,decrypt}_block_inplace(). They seem redundant. There's already a lot of complexity in fscrypt, with the different settings and the different ways the filesystems do en/decryption. With this, plus the concurrent work to add support for extent-based encryption (for btrfs), it's really quite hard to keep track of everything. So I have to wonder if this patchset is really worth it. So, overall, I think this would need a bit more work. But also I'm wondering if it's actually worthwhile. Do you plan to never enable HW-wrapped keys, for example? And you're fine with using more RAM? - Eric _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel