dropping the non-inline mode for fscrypt?

dropping the non-inline mode for fscrypt?

[Christoph Hellwig]

After just having run into another issue with missing testing for one of
the path, I'd like to ask if we should look into dropping the non-inline
mode for block based fscrypt?

I did a few simple fio based benchmarks, and writes are a minimal amount
fast for the inline mode, while the reverse is true for reads.

The big blocker seems to be this comment in fscrypt_select_encryption_impl:

        /*
         * When a page contains multiple logically contiguous filesystem blocks,
         * some filesystem code only calls fscrypt_mergeable_bio() for the first
         * block in the page. This is fine for most of fscrypt's IV generation
         * strategies, where contiguous blocks imply contiguous IVs. But it
         * doesn't work with IV_INO_LBLK_32. For now, simply exclude
         * IV_INO_LBLK_32 with blocksize != PAGE_SIZE from inline encryption.
         */

from touching the file system callers lately, the only obvious place
for this is fscrypt_zeroout_range_inline_crypt helper, or did I miss
anything else?  Does anyone have a good xfstests setup for the
IV_INO_LBLK_32 mode?

Re: dropping the non-inline mode for fscrypt?

[Eric Biggers]

On Mon, Mar 02, 2026 at 03:27:18PM +0100, Christoph Hellwig wrote:
> After just having run into another issue with missing testing for one of
> the path, I'd like to ask if we should look into dropping the non-inline
> mode for block based fscrypt?

Yes, I think that's the way to go now.

I do think the default should continue to be to use the well-tested
CPU-based encryption code (just accessed via blk-crypto-fallback
instead).  Inline encryption hardware should continue to be opt-in via
the inlinecrypt mount option, rather than used unconditionally.  To
allow this, we'll need to add a field 'allow_hardware' or similar to
struct bio_crypt_ctx.  Should be fairly straightforward though.

> I did a few simple fio based benchmarks, and writes are a minimal amount
> fast for the inline mode, while the reverse is true for reads.
> 
> The big blocker seems to be this comment in fscrypt_select_encryption_impl:
> 
>         /*
>          * When a page contains multiple logically contiguous filesystem blocks,
>          * some filesystem code only calls fscrypt_mergeable_bio() for the first
>          * block in the page. This is fine for most of fscrypt's IV generation
>          * strategies, where contiguous blocks imply contiguous IVs. But it
>          * doesn't work with IV_INO_LBLK_32. For now, simply exclude
>          * IV_INO_LBLK_32 with blocksize != PAGE_SIZE from inline encryption.
>          */

I think it would be pretty safe to drop support for IV_INO_LBLK_32 with
blocksize != PAGE_SIZE entirely, given that that case already doesn't
work with inlinecrypt.  The whole point of IV_INO_LBLK_32 is to be able
to use eMMC inline encryption hardware that support only 32-bit IVs.

I should have put in this restriction from the beginning, but I don't
anyone will care if it's added now.

> from touching the file system callers lately, the only obvious place
> for this is fscrypt_zeroout_range_inline_crypt helper, or did I miss
> anything else?

ext4_mpage_readpages() for example seems to call it only once per folio.
It was cited in the original discussion that resulted in this code:
https://lore.kernel.org/linux-fscrypt/20200629182250.GD20492@sol.localdomain/

> Does anyone have a good xfstests setup for the IV_INO_LBLK_32 mode?

Unfortunately not.  generic/369 does use IV_INO_LBLK_32 and verifies
that data is being encrypted correctly, but it's very unlikely to
exercise the DUN wraparound case.

The test_dummy_encryption mount option could be extended to allow
something like "test_dummy_encryption=v2,iv_ino_lblk_32", to cause the
test_dummy_encryption policy to use IV_INO_LBLK_32.

- Eric

Re: dropping the non-inline mode for fscrypt?

[Christoph Hellwig]

On Mon, Mar 02, 2026 at 01:22:36PM -0800, Eric Biggers wrote:
> On Mon, Mar 02, 2026 at 03:27:18PM +0100, Christoph Hellwig wrote:
> > After just having run into another issue with missing testing for one of
> > the path, I'd like to ask if we should look into dropping the non-inline
> > mode for block based fscrypt?
> 
> Yes, I think that's the way to go now.
> 
> I do think the default should continue to be to use the well-tested
> CPU-based encryption code (just accessed via blk-crypto-fallback
> instead).  Inline encryption hardware should continue to be opt-in via
> the inlinecrypt mount option, rather than used unconditionally.  To
> allow this, we'll need to add a field 'allow_hardware' or similar to
> struct bio_crypt_ctx.  Should be fairly straightforward though.

Sounds fine.  Given that you're more familiar with this can I sign
up you to do it?  Otherwise I can add it to my todo list, but chances
are that I'll get some of the subtle interactions wrong.

> I think it would be pretty safe to drop support for IV_INO_LBLK_32 with
> blocksize != PAGE_SIZE entirely, given that that case already doesn't
> work with inlinecrypt.  The whole point of IV_INO_LBLK_32 is to be able
> to use eMMC inline encryption hardware that support only 32-bit IVs.

That sounds even better.

Re: dropping the non-inline mode for fscrypt?

[Eric Biggers]

On Tue, Mar 03, 2026 at 05:55:46PM +0100, Christoph Hellwig wrote:
> On Mon, Mar 02, 2026 at 01:22:36PM -0800, Eric Biggers wrote:
> > On Mon, Mar 02, 2026 at 03:27:18PM +0100, Christoph Hellwig wrote:
> > > After just having run into another issue with missing testing for one of
> > > the path, I'd like to ask if we should look into dropping the non-inline
> > > mode for block based fscrypt?
> > 
> > Yes, I think that's the way to go now.
> > 
> > I do think the default should continue to be to use the well-tested
> > CPU-based encryption code (just accessed via blk-crypto-fallback
> > instead).  Inline encryption hardware should continue to be opt-in via
> > the inlinecrypt mount option, rather than used unconditionally.  To
> > allow this, we'll need to add a field 'allow_hardware' or similar to
> > struct bio_crypt_ctx.  Should be fairly straightforward though.
> 
> Sounds fine.  Given that you're more familiar with this can I sign
> up you to do it?  Otherwise I can add it to my todo list, but chances
> are that I'll get some of the subtle interactions wrong.

Yes, I'll try to find time for this.

- Eric