On Tue, Oct 22, 2019 at 04:27:12PM +1100, Dave Chinner wrote: > On Mon, Oct 21, 2019 at 04:03:53PM -0700, Eric Biggers wrote: > > From: Eric Biggers <ebigg...@google.com> > > > > Some inline encryption hardware has only a small number of keyslots, > > which would make it inefficient to use the traditional fscrypt per-file > > keys. The existing DIRECT_KEY encryption policy flag doesn't solve this > > because it assumes that file contents and names are encrypted by the > > same algorithm and that IVs are at least 24 bytes. > > > > Therefore, add a new encryption policy flag INLINE_CRYPT_OPTIMIZED which > > causes the encryption to modified as follows: > > > > - The key for file contents encryption is derived from the values > > (master_key, mode_num, filesystem_uuid). The per-file nonce is not > > included, so many files may share the same contents encryption key. > > > > - The IV for encrypting each block of file contents is built as > > (inode_number << 32) | file_logical_block_num. > > > > Including the inode number in the IVs ensures that data in different > > files is encrypted differently, despite per-file keys not being used. > > Limiting the inode and block numbers to 32 bits and putting the block > > number in the low bits is needed to be compatible with inline encryption > > hardware which only supports specifying a 64-bit data unit number which > > is auto-incremented; this is what the UFS and EMMC standards support. > > These 32 bit size limits seem arbitrary and rules out implementing > this on larger filesystems. Why not just hash the 64 bit inode, file > offset and block numbers into a single 64 bit value? It is still > unique enough for the stated use (i.e. unique IV for each file > block) but it doesn't limit what filesystem configurations can > actually make use of this functionality.... >
That won't work because we need consecutive file blocks to have consecutive IVs as often as possible. The crypto support in the UFS and EMMC standards takes only a single 64-bit "data unit number" (DUN) per request, which the hardware uses as the first 64 bits of the IV and automatically increments for each data unit (i.e. for each filesystem block, in this case). If every block had some random DUN, we'd have to submit a separate bio for every single block. And they wouldn't be mergable, so each one would cause a separate disk request. That would be really terrible for performance. Also, a 64 bit hash value isn't sufficiently safe against hash collisions. An alternative which would work nicely on ext4 and xfs (if xfs supported fscrypt) would be to pass the physical block number as the DUN. However, that wouldn't work at all on f2fs because f2fs moves data blocks around. And since most people who want to use this are using f2fs, f2fs support is essential. Also keep in mind that the proposed format can still be used on a specific filesystem instance with fewer than 2^32 inodes and blocks, even if that type of filesystem can support more inodes and blocks in general. - Eric _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
