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
|