• Eric Biggers's avatar
    fscrypt: add support for IV_INO_LBLK_64 policies · b103fb76
    Eric Biggers authored
    Inline encryption hardware compliant with the UFS v2.1 standard or with
    the upcoming version of the eMMC standard has the following properties:
    
    (1) Per I/O request, the encryption key is specified by a previously
        loaded keyslot.  There might be only a small number of keyslots.
    
    (2) Per I/O request, the starting IV is specified by a 64-bit "data unit
        number" (DUN).  IV bits 64-127 are assumed to be 0.  The hardware
        automatically increments the DUN for each "data unit" of
        configurable size in the request, e.g. for each filesystem block.
    
    Property (1) makes it inefficient to use the traditional fscrypt
    per-file keys.  Property (2) precludes the use of the existing
    DIRECT_KEY fscrypt policy flag, which needs at least 192 IV bits.
    
    Therefore, add a new fscrypt policy flag IV_INO_LBLK_64 which causes the
    encryption to modified as follows:
    
    - The encryption keys are derived from the master key, encryption mode
      number, and filesystem UUID.
    
    - The IVs are chosen as (inode_number << 32) | file_logical_block_num.
      For filenames encryption, file_logical_block_num is 0.
    
    Since the file nonces aren't used in the key derivation, many files may
    share the same encryption key.  This is much more efficient on the
    target hardware.  Including the inode number in the IVs and mixing the
    filesystem UUID into the keys ensures that data in different files is
    nevertheless still encrypted differently.
    
    Additionally, limiting the inode and block numbers to 32 bits and
    placing the block number in the low bits maintains compatibility with
    the 64-bit DUN convention (property (2) above).
    
    Since this scheme assumes that inode numbers are stable (which may
    preclude filesystem shrinking) and that inode and file logical block
    numbers are at most 32-bit, IV_INO_LBLK_64 will only be allowed on
    filesystems that meet these constraints.  These are acceptable
    limitations for the cases where this format would actually be used.
    
    Note that IV_INO_LBLK_64 is an on-disk format, not an implementation.
    This patch just adds support for it using the existing filesystem layer
    encryption.  A later patch will add support for inline encryption.
    Reviewed-by: default avatarPaul Crowley <paulcrowley@google.com>
    Co-developed-by: default avatarSatya Tangirala <satyat@google.com>
    Signed-off-by: default avatarSatya Tangirala <satyat@google.com>
    Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
    b103fb76
policy.c 15.7 KB