f2fs加密

1. 加密
1.1 文件内容和文件名-fscrypt
(1) 通过文件系统level 的 fscrypt (File-based encryption)进行加密
(2) 为了加密不同的文件
1.2. Metadata 加密 - dm-default-key
(1) metadata 包括 文件系统metadata
(2) 简单来说就是，dm-default-key 针对下发到block层的bio ，若不是encrypted file 的bio , 就给该bio assign 一个加密key, 保证文件内容和文件名-fscrypt加密之外的其他metadata 也是加密的。
(3) dm-default-key 保证磁盘上的所有block 都加密，且对采用fscrypt 对文件内容加密没有性能的影响
(4) 为了方便f2fs 在没有key 的情况下对加密文件的gc，dm-default-key 的原生逻辑修改了，“set a key on the bio if it doesn't have one already”， 改成“set a key on the bio unless the bio has the bi_skip_dm_default_key flag set"。 简言之，就是默认都使用dm-default-key，即针对文件加密的file 需要设置skip.
(5)https://cs.android.com/android//android/kernel/common/+/cb39ec0c1040e89d14ae0852454f8fd64a704118
i. Add a device-mapper target "dm-default-key" which assigns an encryption
key to bios that aren't for the contents of an encrypted file.
ii. This ensures that all blocks on-disk will be encrypted with some key,
without the performance hit of file contents being encrypted twice when
fscrypt (File-Based Encryption) is used.
iii. It is only appropriate to use dm-default-key when key configuration is
tightly controlled, like it is in Android, such that all fscrypt keys
are at least as hard to compromise as the default key.
iiii. Compared to the original version of dm-default-key, this has been
modified to use the new vendor-independent inline encryption framework
(which works even when no inline encryption hardware is present), the
table syntax has been changed to match dm-crypt, and support for
specifying Adiantum encryption has been added. These changes also mean
that dm-default-key now always explicitly specifies the DUN (the IV).
X. Also, to handle f2fs moving blocks of encrypted files around without the
key, and to handle ext4 and f2fs filesystems mounted without
'-o inlinecrypt', the mapping logic is no longer "set a key on the bio
if it doesn't have one already", but rather "set a key on the bio unless
the bio has the bi_skip_dm_default_key flag set". Filesystems set this
flag on all bios for encrypted file contents, regardless of whether
they are encrypting/decrypting the file using inline encryption or the
traditional filesystem-layer encryption, or moving the raw data.
For the bi_skip_dm_default_key flag, a new field in struct bio is used
rather than a bit in bi_opf so that fscrypt_set_bio_crypt_ctx() can set
the flag, minimizing the changes needed to filesystems. (bi_opf is
usually overwritten after fscrypt_set_bio_crypt_ctx() is called.)
(6) android f2fs metadata 加密支持
参考https://lwn.net/Articles/840600/
1.3 superblock 是不加密的
2. 加密数据的GC如何处理
2.1 简言之，就是避免GC过程的加密和解密，也就是gc raw data(秘文）
In cleaning procedure, we must avoid encrypting and decrypting written blocks.
参考：https://cs.android.com/android//android/kernel/common/+/4375a33664de17af9032b5f491a49bd256670927
2.2 GC 加密数据的流程：
1)使用meta inode 和 data block index 读密文到meta page
2)分配new block address
3)写密文到新的block address
https://www.uwsg.indiana.edu/hypermail/linux/kernel/1602.2/04452.html
flow of GCing an encrypted data page:
1)try to grab meta page in meta inode's mapping with index of old block
address of that data page
2)load data of ciphertext into meta page
3)allocate new block address
4)write the meta page into new block address
5)update block address pointer in direct node page.

3. fscrypt 文件原理
   3.1 加密context
   i. 文件内容和文件名加密mode
   ii. IV flags

#define FSCRYPT_POLICY_V1               0
#define FSCRYPT_KEY_DESCRIPTOR_SIZE     8
struct fscrypt_policy_v1 {
        __u8 version;
        __u8 contents_encryption_mode;
        __u8 filenames_encryption_mode;
        __u8 flags;
        __u8 master_key_descriptor[FSCRYPT_KEY_DESCRIPTOR_SIZE];
};
#define fscrypt_policy  fscrypt_policy_v1

#define FSCRYPT_POLICY_V2               2
#define FSCRYPT_KEY_IDENTIFIER_SIZE     16
struct fscrypt_policy_v2 {
        __u8 version;
        __u8 contents_encryption_mode;
        __u8 filenames_encryption_mode;
        __u8 flags;
        __u8 __reserved[4];
        __u8 master_key_identifier[FSCRYPT_KEY_IDENTIFIER_SIZE];
};

3.2 IV policy
根据IV flags，IV 采用不同的加密policy。
(1) 简言之，DIRECT_KEY policies, IV 包含 per-file 随机数 + file logic block number 。
DIRECT_KEY policies, the file's nonce is appended to the IV. Currently this is only allowed with the Adiantum encryption mode.
(2) 简言之，IV_INO_LBLK_64 policies, IV 包含 per-file inode number + file logic block number。
IV_INO_LBLK_64 policies, the logical block number is limited to 32 bits and is placed in bits 0-31 of the IV. The inode number (which is also limited to 32 bits) is placed in bits 32-63.
(3) 简言之，IV_INO_LBLK_32 policies, IV包含 hashed inode number + logical block number
IV_INO_LBLK_32 policies, the logical block number is limited to 32 bits and is placed in bits 0-31 of the IV. The inode number is then hashed and added mod 2^32.

3.3 加密mode
(1) AES-256-XTS for contents and AES-256-CTS-CBC for filenames
(2) AES-128-CBC for contents and AES-128-CTS-CBC for filenames
(3) Adiantum for both contents and filenames

3.4 文件内容加密
根据文件内容加密的context,加密上下文包含per-file inode-number 或 nonce随机数,和 文件内每个block 的logical block number：
per-file per-file inode-number 或 nonce随机数：让不同文件，纵然内容的明文一样，则对应的密文也不一样。
文件内每个block 的logical block number： 让同一个文件，纵然明文一样，位置不一样，则对应的密文也不一样。