Lines Matching refs:crypto

27 To allow for testing, we also want a crypto API fallback when actual
30 of the underlying devices if present, or else fall back to crypto API
84 blk-mq changes, other block layer changes and blk-crypto-fallback
88 struct request. These will be referred to as the ``crypto fields``
93 We introduce ``block/blk-crypto-fallback.c``, which allows upper layers to remain
97 en/decrypt the bio with the blk-crypto-fallback.
102 concerned). ``blk-crypto-fallback`` sets the bounce bio's ``bi_end_io`` to an
106 is saved and overwritten by ``blk-crypto-fallback`` to
114 blk-crypto-fallback is used, the ciphertext written to disk (and hence the
120 ``blk-crypto-fallback``. We will eventually reach a point in blk-mq when a
135 layered devices, when a request is cloned, its ``crypto fields`` are cloned as
144 ``struct blk_crypto_key`` represents a crypto key (the raw key, size of the
145 key, the crypto algorithm to use, the data unit size to use, and the number of
154 blk-crypto-fallback, if hardware support isn't available for the desired
155 crypto configuration). This function takes the ``blk_crypto_key`` and the
159 an encryption context passed to request queue can be handled by blk-crypto
160 (either by real inline encryption hardware, or by the blk-crypto-fallback).
161 This is useful e.g. when blk-crypto-fallback is disabled, and the upper layer
169 hardware supports the key's crypto settings, or the crypto API fallback has
178 inline encryption hardware that the key might have been programmed into (or the blk-crypto-fallback…
189 IE hardware in the device to do things like programming the crypto key into
195 (e.g. when it wants to program a crypto key into the IE hardware, the device
216 request to another ``request_queue``, blk-crypto will initialize and prepare the
218 ``blk-crypto.c``.
252 encryption support is present or the kernel crypto API fallback is used (since
261 to NULL). When the crypto API fallback is enabled, this means that all bios with