Lines Matching refs:encryption

10 Inline encryption hardware sits logically between memory and the disk, and can
11 en/decrypt data as it goes in/out of the disk. Inline encryption hardware has a
12 fixed number of "keyslots" - slots into which encryption contexts (i.e. the
13 encryption key, encryption algorithm, data unit size) can be programmed by the
15 of a keyslot (and also a data unit number to act as an encryption tweak), and
16 the inline encryption hardware will en/decrypt the data in the request with the
17 encryption context programmed into that keyslot. This is very different from
18 full disk encryption solutions like self encrypting drives/TCG OPAL/ATA
19 Security standards, since with inline encryption, any block on disk could be
20 encrypted with any encryption context the kernel chooses.
26 We want to support inline encryption (IE) in the kernel.
38   with an encryption context (key, algorithm, data unit size, etc.) at any time.
40   device will en/decrypt the data using the encryption context programmed into
42   the same encryption context share the same keyslot.
44 - We need a way for upper layers like filesystems to specify an encryption
46   needs to be able to use that encryption context when it processes the bio.
48 - We need a way for device drivers to expose their inline encryption
56 represent an encryption context, because we need to be able to pass this
57 encryption context from the upper layers (like the fs layer) to the
61 knowledge of keyslots - it simply wants to specify an encryption context to
65 encryption contexts specified by the FS to keyslots on the IE hardware.
70 the device's struct request_queue to translate an encryption context into
75 encryption context programmed, or there are no in-flight struct bios
76 referencing that keyslot). When a new encryption context needs a keyslot, it
78 encryption context, and if there is no such keyslot, it evicts the least
79 recently used idle keyslot and programs the new encryption context into that
94 blissfully unaware of whether or not real inline encryption hardware is present
96 support the encryption context specified with the bio, the block layer will
109 as if it was a regular bio that never had an encryption context specified.
113 Regardless of whether real inline encryption hardware is used or the
118 If a ``request queue``'s inline encryption hardware claimed to support the
119 encryption context specified with a bio, then it will not be handled by the
122 blk-mq tries to program the encryption context into the ``request_queue``'s
134 To make it possible for inline encryption to work with request queue based
153 the block layer wants en/decrypted via inline encryption (or 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).
178 inline encryption hardware that the key might have been programmed into (or the blk-crypto-fallback…
229 to advertise an unlimited number of keyslots, and support for any encryption
235 Interaction between inline encryption and blk integrity
241 when a WRITE bio wants to use inline encryption on a device that supports both
242 features, the bio will have an encryption context specified, after which
244 the encryption will happen while data is being written), and the data and
252 encryption support is present or the kernel crypto API fallback is used (since
259 kernel will pretend that the device does not support hardware inline encryption
262 and encryption context will use the fallback, and IO will complete as usual.
263 When the fallback is disabled, a bio with an encryption context will be failed.