FDE (Full disk encryption) 的发展经历了几个阶段：
- 基于软件/硬件实现的 dm-crypt
- 基于硬件 GPCE 实现的 request-dm-crypt
- 基于硬件 ICE 实现的 dm-req-crypt
1. 术语解释
dm-crypt / request-dm-crypt / dm-req-crypt
它们都是位于 linux kernel block 层， 用于加解密数据的 Device Mapper 驱动模块，下文统称 dm crypt 驱动。Device Mapper 可以将整个 block 设备或 block 设备的部分映射到单个设备。
这些 dm crypt 驱动模块使用这个特性将整个用户数据分区，即用户数据分区中的所有扇区映射到另一个设备，例如/dev/dm-N。此时用户数据分区上的任何操作都由设备映射层处理，dm crypt 驱动模块加密所有写操作，并解密所有的读操作。最终整个加密和解密数据的过程对于用户来说是透明的。
至于这些 dm crypt 驱动模块的区别则是拥有更好的 I/O 性能，主要表现在 I/O 吞吐量和 I/O 延时，下文详细介绍。
GPCE
general-purpose crypto engine，ARM 体系结构提供的通用加密引擎。
ICE
inline crypto engine，一般由 SOC 厂商实现，内嵌到存储器控制器的加密引擎。
2. 基于软件/硬件实现的 dm-crypt
该方案已经被废弃，这里只做简单介绍，架构如下所示：
使用 dm-crypt 加密磁盘：
- dm-crypt 是在基于 BIO 的设备映射器之上提供的磁盘加密机制，它在物理块设备之上提供虚拟块层。
- dm 层将接收到的块 I/O (BIO) 克隆并映射到底层物理设备。
- Android系统中的 VOLD 使用 dm-crypt 将用户数据分区映射到 cryptfs 文件系统。所有对 cryptfs 文件系统的写入都被加密，读取被解密。
- Android 使用 128 位 AES-CBC 模式以及 ESSIV:SHA256 来加密和解密数据。所有加密材料，例如加密密钥和加密类型，都存储在用户数据分区的底部 16 K 中。
- dm-crypt 使用 512 字节的数据包大小来加密和解密数据。这意味着必须为每个扇区创建一个新的密码上下文。除此之外，每次为每个扇区生成 IV，即使用 SHA-256 的 512 字节，这是一个昂贵的机制。
- VOLD 管理所有加密材料并在启动时将其提供给设备映射设备。
基于软件的实现
从安全的角度来看，如果加密操作是在软件中完成的，那么密钥必须存在于软件中，这是不可取的。基于软件的磁盘加密有几个缺点：
- 它很慢。
- 所有加密操作都发生在软件中，因此非常耗电且消耗大量电力。
- 将密钥存储在 RAM 中，可以被转储和搜索，所以并不安全。
基于硬件的实现
由于通用硬件加密引擎不能很好地处理较小的数据包大小，因此仍然存在性能问题。
3. 基于硬件 GPCE 实现的 request-dm-crypt
该方案已经被废弃，这里只做简单介绍，架构如下所示：
相比基于 BIO 的映射器的 dm-crypt， request-dm-crypt 是基于请求的设备映射器，不同之处在于：
- request-dm-crypt 设备映射器不是克隆和映射 BIO，而是移动到软件架构 stack 中的较低位置，它克隆和映射 I/O 请求。
- 不需要和 dm-crypt 一样，使用 512 字节的数据包大小来加密和解密数据，大大释放了 GPCE 的性能。
3.1 写操作流程
- dm 层调用已注册插件 (request-dm-crypt) 的 map API；
- map 函数还会遍历请求中的所有 BIO，并创建所有数据的 SGL（scatter gather list）；
- 然后 map 函数调用 Kernel Crypto API，该 API 最终调用 GPCE 加密驱动程序以执行加密操作；
- 加密完成后，克隆的请求被添加到 I/O 调度程序队列；
3.2 读操作流程
- 当块驱动完成读请求时，请求被传递到通用块层（blk_end_bidi_request）以完成请求；
- 通用块层通过调用请求的end_io函数来完成请求；
- end_io 函数然后调用 request-dm-crypt 的 end_io 函数；
- request-dmcrypt end_io 函数遍历请求中的 BIO 并创建一个 SGL。然后该函数使用此列表调用内核加密 API；
- Kernel Crypto API 最终调用 GPCE 加密驱动程序来执行解密操作；
- 最终将数据返回到文件系统。
使用通用加密引擎 (GPCE) 提供了可以接受的性能量，但由于存储速度不断提高，它还不够。因为 I/O 请求需要通过 request-dm-crypt 处理来执行数据加密和解密，从架构图中可以看出，在原来的 I/O 流程中增加了一个环节增加了延时。因此 FDE 又进化到下文介绍的基于 ICE 实现的 dm-req-crypt。
4. 基于硬件 ICE 实现的 dm-req-crypt
为了克服性能下降，较新的芯片将内联加密引擎 (ICE) 嵌入到存储设备中。基于 ICE 的 FDE 在 ICE 硬件中执行所有加密操作，而无需返回软件。该解决方案提供几乎线速的吞吐量，即加密设备上的 I/O 吞吐量不会降低。
