@@ -141,9 +141,8 @@ However, these ioctls have some limitations:
141141 CONFIG_PAGE_POISONING=y in your kernel config and add page_poison=1
142142 to your kernel command line. However, this has a performance cost.
143143
144- - Secret keys might still exist in CPU registers, in crypto
145- accelerator hardware (if used by the crypto API to implement any of
146- the algorithms), or in other places not explicitly considered here.
144+ - Secret keys might still exist in CPU registers or in other places
145+ not explicitly considered here.
147146
148147Limitations of v1 policies
149148~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -378,9 +377,12 @@ the work is done by XChaCha12, which is much faster than AES when AES
378377acceleration is unavailable. For more information about Adiantum, see
379378`the Adiantum paper <https://eprint.iacr.org/2018/720.pdf >`_.
380379
381- The (AES-128-CBC-ESSIV, AES-128-CBC-CTS) pair exists only to support
382- systems whose only form of AES acceleration is an off-CPU crypto
383- accelerator such as CAAM or CESA that does not support XTS.
380+ The (AES-128-CBC-ESSIV, AES-128-CBC-CTS) pair was added to try to
381+ provide a more efficient option for systems that lack AES instructions
382+ in the CPU but do have a non-inline crypto engine such as CAAM or CESA
383+ that supports AES-CBC (and not AES-XTS). This is deprecated. It has
384+ been shown that just doing AES on the CPU is actually faster.
385+ Moreover, Adiantum is faster still and is recommended on such systems.
384386
385387The remaining mode pairs are the "national pride ciphers":
386388
@@ -1289,22 +1291,13 @@ this by validating all top-level encryption policies prior to access.
12891291Inline encryption support
12901292=========================
12911293
1292- By default, fscrypt uses the kernel crypto API for all cryptographic
1293- operations (other than HKDF, which fscrypt partially implements
1294- itself). The kernel crypto API supports hardware crypto accelerators,
1295- but only ones that work in the traditional way where all inputs and
1296- outputs (e.g. plaintexts and ciphertexts) are in memory. fscrypt can
1297- take advantage of such hardware, but the traditional acceleration
1298- model isn't particularly efficient and fscrypt hasn't been optimized
1299- for it.
1300-
1301- Instead, many newer systems (especially mobile SoCs) have *inline
1302- encryption hardware * that can encrypt/decrypt data while it is on its
1303- way to/from the storage device. Linux supports inline encryption
1304- through a set of extensions to the block layer called *blk-crypto *.
1305- blk-crypto allows filesystems to attach encryption contexts to bios
1306- (I/O requests) to specify how the data will be encrypted or decrypted
1307- in-line. For more information about blk-crypto, see
1294+ Many newer systems (especially mobile SoCs) have *inline encryption
1295+ hardware * that can encrypt/decrypt data while it is on its way to/from
1296+ the storage device. Linux supports inline encryption through a set of
1297+ extensions to the block layer called *blk-crypto *. blk-crypto allows
1298+ filesystems to attach encryption contexts to bios (I/O requests) to
1299+ specify how the data will be encrypted or decrypted in-line. For more
1300+ information about blk-crypto, see
13081301:ref: `Documentation/block/inline-encryption.rst <inline_encryption >`.
13091302
13101303On supported filesystems (currently ext4 and f2fs), fscrypt can use
0 commit comments