Lines Matching refs:that

17 encryption context programmed into that keyslot. This is very different from
37 - IE hardware has a limited number of "keyslots" that can be programmed
41   that specified keyslot. When possible, we want to make multiple requests with
46   needs to be able to use that encryption context when it processes the bio.
55 We add a struct bio_crypt_ctx to struct bio that can
64 We introduce a keyslot manager (KSM) that handles the translation from
67 upper layers. The generic mode of operation is: each device driver that wants
69 Upper layers that want to use IE on this device can then use this KSM in
72 that the device supports IE.
76 referencing that keyslot). When a new encryption context needs a keyslot, it
77 tries to find a keyslot that has already been programmed with the same
79 recently used idle keyslot and programs the new encryption context into that
91 that this request is being sent to.
95 underneath. When a bio is submitted with a target ``request_queue`` that doesn't
103 internal function that cleans up the bounce bio and ends the original bio.
108 overwritten with ``NULL``, so that to the rest of the stack, the bio looks
109 as if it was a regular bio that never had an encryption context specified.
121 struct request needs to be allocated for that bio. At that point,
130 the request so that it matches the newly merged bio's ``bi_crypt_context``. In particular, the requ…
146 bytes required to represent data unit numbers that will be specified with the
152 ``bio_crypt_set_ctx`` should be called on any bio that a user of
162 wants to use an algorithm that may not supported by hardware - this function
163 lets the upper layer know ahead of time that the algorithm isn't supported,
168 headed for that ``request_queue``. This function ensures that either the
170 transforms for the needed mode allocated and ready to go. Note that this
176 there are no more in-flight requests that use that ``blk_crypto_key``.
177 ``blk_crypto_evict_key`` will ensure that a key is removed from any keyslots in
178 inline encryption hardware that the key might have been programmed into (or the blk-crypto-fallback…
192 struct blk_ksm_ll_ops field in the KSM that the device driver
213 Request queue based layered devices like dm-rq that wish to support IE need to
215 functionality they choose. When a layered device wants to pass a clone of that
228 define a new type of KSM; the "passthrough KSM", that layered devices can use
231 Another use case for the "passthrough KSM" is for IE devices that do not have a
238 At the time of this patch, there is no real hardware that supports both these
241 when a WRITE bio wants to use inline encryption on a device that supports both
247 must not store the integrity info that it received with the plaintext data
248 since that might reveal information about the plaintext data. As such, it must
249 re-generate the integrity info from the ciphertext data and store that on disk
251 that it changes the on disk format depending on whether hardware inline
254 ciphertext, not that of the plaintext).
256 Because there isn't any real hardware yet, it seems prudent to assume that
259 kernel will pretend that the device does not support hardware inline encryption
261 to NULL). When the crypto API fallback is enabled, this means that all bios with