Lines Matching +full:2 +full:- +full:layered

1 .. SPDX-License-Identifier: GPL-2.0
19 keys directly in low-level I/O requests.  However, most inline encryption
22 low-level I/O request then just contains a keyslot index and data unit number.
30 Inline encryption hardware is also very different from "self-encrypting drives",
31 such as those based on the TCG Opal or ATA Security standards.  Self-encrypting
32 drives don't provide fine-grained control of encryption and provide no way to
34 provides fine-grained control of encryption, including the choice of key and
43 layered devices like device-mapper and loopback (i.e. we want to be able to use
50 - We need a way for upper layers (e.g. filesystems) to specify an encryption
56 - Different inline encryption hardware has different supported algorithms,
61 - Inline encryption hardware usually (but not always) requires that keys be
65   keyslots and reuse an already-programmed keyslot when possible.
67 - Upper layers typically define a specific end-of-life for crypto keys, e.g.
72 - When possible, device-mapper devices must be able to pass through the inline
74   sense for device-mapper devices to have keyslots themselves.
95 encryption-related state for a particular inline encryption device.  The
109 in-flight I/O requests are using it.  When the block layer creates a
112 keyslot (a keyslot that isn't in-use by any I/O), then programs the key into the
113 least-recently-used idle keyslot using the function the device driver provided.
124 retained, since the remaining bios have been verified to be merge-compatible
128 layered devices, when a request is cloned, its encryption context is cloned as
132 blk-crypto-fallback
141 Therefore, we also introduce *blk-crypto-fallback*, which is an implementation
142 of inline encryption using the kernel crypto API.  blk-crypto-fallback is built
146 handle en/decryption of the bio using blk-crypto-fallback.
148 For encryption, the data cannot be encrypted in-place, as callers usually rely
149 on it being unmodified.  Instead, blk-crypto-fallback allocates bounce pages,
152 blk-crypto-fallback completes the original bio.  If the original bio is too
155 For decryption, blk-crypto-fallback "wraps" the bio's completion callback
158 successfully, blk-crypto-fallback restores the bio's original completion
159 callback and private data, then decrypts the bio's data in-place using the
161 Afterwards, blk-crypto-fallback completes the bio.
163 In both cases, the bios that blk-crypto-fallback submits no longer have an
166 blk-crypto-fallback also defines its own blk_crypto_profile and has its own
174 makes sense for blk-crypto-fallback.
177 blk-crypto-fallback is used, the ciphertext written to disk (and hence the
178 on-disk format of data) will be the same (assuming that both the inline
182 blk-crypto-fallback is optional and is controlled by the
190 request_queue -- either via hardware or via blk-crypto-fallback.  This function
193 size, etc.  This function can be useful if blk-crypto-fallback is disabled.
199 was called earlier).  This is needed to initialize blk-crypto-fallback if it
218 2. ``blk_crypto_init_key()``
233 must call ``blk_crypto_profile_init()`` (or its resource-managed variant
254 while the device is runtime-suspended, then the driver must also set the ``dev``
256 resumed before any of the low-level operations are called.
266 Layered Devices
269 Request queue based layered devices like dm-rq that wish to support inline
271 and expose whatever functionality they choose. When a layered device wants to
272 pass a clone of that request to another request_queue, blk-crypto will
290 re-generate the integrity info from the ciphertext data and store that on disk