Re: [PATCH v5 00/18] btrfs: add fscrypt integration

[Eric Biggers <ebiggers@kernel.org>]

On Sun, Nov 27, 2022 at 11:59:40PM -0800, Christoph Hellwig wrote:
> On Wed, Nov 23, 2022 at 08:22:30PM -0500, Sweet Tea Dorminy wrote:
> > The document has been updated to hopefully reflect the discussion we had;
> > further comments are always appreciated. https://docs.google.com/document/d/1janjxewlewtVPqctkWOjSa7OhCgB8Gdx7iDaCDQQNZA/edit?usp=sharing
> 
> How is this going to work with hardware encryption offload?  I think
> the number of keys for UFS and eMMC inline encryption, but Eric may
> correct me.

First, traditional crypto accelerators via the crypto API will work in any case.
I think your question is specifically about inline encryption
(https://www.kernel.org/doc/html/latest/block/inline-encryption.html).

To use inline encryption hardware, consecutive blocks must use consecutive IVs,
and the nonzero part of the IVs needs to fit within the hardware's DUN size.
That's 64 bits for the UFS standard, and 32 bits for the eMMC standard.

fscrypt's "default" setting of per-file keys satisfies both of those
requirements.  That means the current proposal for btrfs does too, since it's
the same as that "default" setting -- just with extents instead of files.
(For eMMC, extents would have to be limited to 2^32 blocks.)

The other consideration, which seems to be what you're asking about, is a
performance one: how well this performs on hardware where switching keys is very
expensive.  The answer is not very well.  Of course, that's the answer for
per-file keys too.  Note that this is an issue for some inline encryption
hardware (e.g. Qualcomm ICE), but not others (e.g. Exynos FMP, Mediatek UFS).

The way this problem is "solved" in ext4 and f2fs is by also providing the (less
than cryptographically ideal) settings IV_INO_LBLK_64 and IV_INO_LBLK_32.  Those
squeeze the inode number *and* file offset into a 64-bit or 32-bit IV, so that
per-file keys aren't needed.

There's a natural mapping of the IV_INO_LBLK_* settings onto extent-based
encryption.  A 32-bit extent number would just be used instead of an inode
number.  Or, if a 32-bit extent number is infeasible, an extent nonce of any
length hashed with a secret key could be used instead.

So yes, it would be possible to provide settings that optimize for hardware like
Qualcomm ICE, as ext4 and f2fs do with IV_INO_LBLK_*.  However, it makes sense
to leave that for later until if/when someone actually has a use case for it.

- Eric