From: Eric Biggers <ebiggers@kernel.org>
To: LiaoYuanhong-vivo <liaoyuanhong@vivo.com>
Cc: chao@kernel.org, corbet@lwn.net, jaegeuk@kernel.org,
linux-doc@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fscrypt@vger.kernel.org, linux-kernel@vger.kernel.org,
skhan@linuxfoundation.org, tytso@mit.edu
Subject: Re: [PATCH v3 0/3] f2fs: support encrypted inline data
Date: Tue, 16 Jun 2026 16:02:15 -0700 [thread overview]
Message-ID: <20260616230215.GA1873@quark> (raw)
In-Reply-To: <20260616094612.45505-1-liaoyuanhong@vivo.com>
On Tue, Jun 16, 2026 at 05:46:12PM +0800, LiaoYuanhong-vivo wrote:
> Could you share more about the direction you have in mind for simplifying
> f2fs/ext4 contents encryption around blk-crypto?
Currently ext4 and f2fs each have two implementations of file contents
encryption and decryption:
- One where the en/decryption is done in the filesystem layer
- One where the filesystem attaches a bio_crypt_ctx to the bios and the
en/decryption is done either in the block layer by blk-crypto-fallback
or by inline encryption hardware
I'd like to drop the first one, for simplicity and to reduce the burden
on ongoing developments like large folio support.
> For f2fs inline_data, there is still a real space-saving benefit on phones,
> since many encrypted files are smaller than 4K. Is there any acceptable
> future direction to support this kind of inode-resident data with
> blk-crypto or hardware-wrapped keys?
It is incompatible with inline encryption hardware. A CPU-based
solution like Intel Key Locker or RISC-V High Assurance Cryptography
could provide similar security properties. But there's nothing for
arm64 yet. And I should mention that no one has wanted to use Key
Locker anyway because it's really slow.
- Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
To: LiaoYuanhong-vivo <liaoyuanhong@vivo.com>
Cc: corbet@lwn.net, tytso@mit.edu, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fscrypt@vger.kernel.org, skhan@linuxfoundation.org,
jaegeuk@kernel.org, linux-ext4@vger.kernel.org
Subject: Re: [f2fs-dev] [PATCH v3 0/3] f2fs: support encrypted inline data
Date: Tue, 16 Jun 2026 16:02:15 -0700 [thread overview]
Message-ID: <20260616230215.GA1873@quark> (raw)
In-Reply-To: <20260616094612.45505-1-liaoyuanhong@vivo.com>
On Tue, Jun 16, 2026 at 05:46:12PM +0800, LiaoYuanhong-vivo wrote:
> Could you share more about the direction you have in mind for simplifying
> f2fs/ext4 contents encryption around blk-crypto?
Currently ext4 and f2fs each have two implementations of file contents
encryption and decryption:
- One where the en/decryption is done in the filesystem layer
- One where the filesystem attaches a bio_crypt_ctx to the bios and the
en/decryption is done either in the block layer by blk-crypto-fallback
or by inline encryption hardware
I'd like to drop the first one, for simplicity and to reduce the burden
on ongoing developments like large folio support.
> For f2fs inline_data, there is still a real space-saving benefit on phones,
> since many encrypted files are smaller than 4K. Is there any acceptable
> future direction to support this kind of inode-resident data with
> blk-crypto or hardware-wrapped keys?
It is incompatible with inline encryption hardware. A CPU-based
solution like Intel Key Locker or RISC-V High Assurance Cryptography
could provide similar security properties. But there's nothing for
arm64 yet. And I should mention that no one has wanted to use Key
Locker anyway because it's really slow.
- Eric
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2026-06-16 23:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-15 12:55 [PATCH v3 0/3] f2fs: support encrypted inline data LiaoYuanhong-vivo
2026-06-15 12:55 ` [f2fs-dev] " LiaoYuanhong-vivo via Linux-f2fs-devel
2026-06-15 12:55 ` [PATCH v3 1/3] fscrypt: prepare software keys for filesystem-managed data units LiaoYuanhong-vivo
2026-06-15 12:55 ` [PATCH v3 2/3] f2fs: support encrypted inline data LiaoYuanhong-vivo
2026-06-15 12:55 ` [f2fs-dev] " LiaoYuanhong-vivo via Linux-f2fs-devel
2026-06-15 12:55 ` [PATCH v3 3/3] Documentation: f2fs: document " LiaoYuanhong-vivo
2026-06-15 12:55 ` [f2fs-dev] " LiaoYuanhong-vivo via Linux-f2fs-devel
2026-06-15 19:37 ` [PATCH v3 0/3] f2fs: support " Eric Biggers
2026-06-15 19:37 ` [f2fs-dev] " Eric Biggers via Linux-f2fs-devel
2026-06-16 9:46 ` LiaoYuanhong-vivo
2026-06-16 9:46 ` [f2fs-dev] " LiaoYuanhong-vivo via Linux-f2fs-devel
2026-06-16 23:02 ` Eric Biggers [this message]
2026-06-16 23:02 ` Eric Biggers via Linux-f2fs-devel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260616230215.GA1873@quark \
--to=ebiggers@kernel.org \
--cc=chao@kernel.org \
--cc=corbet@lwn.net \
--cc=jaegeuk@kernel.org \
--cc=liaoyuanhong@vivo.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.