Commit 1b262839 authored by Satya Tangirala's avatar Satya Tangirala Committed by Jens Axboe

block: Keyslot Manager for Inline Encryption

Inline Encryption hardware allows software to specify an encryption context
(an encryption key, crypto algorithm, data unit num, data unit size) along
with a data transfer request to a storage device, and the inline encryption
hardware will use that context to en/decrypt the data. The inline
encryption hardware is part of the storage device, and it conceptually sits
on the data path between system memory and the storage device.

Inline Encryption hardware implementations often function around the
concept of "keyslots". These implementations often have a limited number
of "keyslots", each of which can hold a key (we say that a key can be
"programmed" into a keyslot). Requests made to the storage device may have
a keyslot and a data unit number associated with them, and the inline
encryption hardware will en/decrypt the data in the requests using the key
programmed into that associated keyslot and the data unit number specified
with the request.

As keyslots are limited, and programming keys may be expensive in many
implementations, and multiple requests may use exactly the same encryption
contexts, we introduce a Keyslot Manager to efficiently manage keyslots.

We also introduce a blk_crypto_key, which will represent the key that's
programmed into keyslots managed by keyslot managers. The keyslot manager
also functions as the interface that upper layers will use to program keys
into inline encryption hardware. For more information on the Keyslot
Manager, refer to documentation found in block/keyslot-manager.c and
linux/keyslot-manager.h.
Co-developed-by: default avatarEric Biggers <ebiggers@google.com>
Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
Signed-off-by: default avatarSatya Tangirala <satyat@google.com>
Reviewed-by: default avatarEric Biggers <ebiggers@google.com>
Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
parent 54b259f6
......@@ -186,6 +186,13 @@ config BLK_SED_OPAL
Enabling this option enables users to setup/unlock/lock
Locking ranges for SED devices using the Opal protocol.
config BLK_INLINE_ENCRYPTION
bool "Enable inline encryption support in block layer"
help
Build the blk-crypto subsystem. Enabling this lets the
block layer handle encryption, so users can take
advantage of inline encryption hardware if present.
menu "Partition Types"
source "block/partitions/Kconfig"
......
......@@ -36,3 +36,4 @@ obj-$(CONFIG_BLK_DEBUG_FS) += blk-mq-debugfs.o
obj-$(CONFIG_BLK_DEBUG_FS_ZONED)+= blk-mq-debugfs-zoned.o
obj-$(CONFIG_BLK_SED_OPAL) += sed-opal.o
obj-$(CONFIG_BLK_PM) += blk-pm.o
obj-$(CONFIG_BLK_INLINE_ENCRYPTION) += keyslot-manager.o
This diff is collapsed.
/* SPDX-License-Identifier: GPL-2.0 */
/*
* Copyright 2019 Google LLC
*/
#ifndef __LINUX_BLK_CRYPTO_H
#define __LINUX_BLK_CRYPTO_H
enum blk_crypto_mode_num {
BLK_ENCRYPTION_MODE_INVALID,
BLK_ENCRYPTION_MODE_AES_256_XTS,
BLK_ENCRYPTION_MODE_AES_128_CBC_ESSIV,
BLK_ENCRYPTION_MODE_ADIANTUM,
BLK_ENCRYPTION_MODE_MAX,
};
#define BLK_CRYPTO_MAX_KEY_SIZE 64
/**
* struct blk_crypto_config - an inline encryption key's crypto configuration
* @crypto_mode: encryption algorithm this key is for
* @data_unit_size: the data unit size for all encryption/decryptions with this
* key. This is the size in bytes of each individual plaintext and
* ciphertext. This is always a power of 2. It might be e.g. the
* filesystem block size or the disk sector size.
* @dun_bytes: the maximum number of bytes of DUN used when using this key
*/
struct blk_crypto_config {
enum blk_crypto_mode_num crypto_mode;
unsigned int data_unit_size;
unsigned int dun_bytes;
};
/**
* struct blk_crypto_key - an inline encryption key
* @crypto_cfg: the crypto configuration (like crypto_mode, key size) for this
* key
* @data_unit_size_bits: log2 of data_unit_size
* @size: size of this key in bytes (determined by @crypto_cfg.crypto_mode)
* @raw: the raw bytes of this key. Only the first @size bytes are used.
*
* A blk_crypto_key is immutable once created, and many bios can reference it at
* the same time. It must not be freed until all bios using it have completed
* and it has been evicted from all devices on which it may have been used.
*/
struct blk_crypto_key {
struct blk_crypto_config crypto_cfg;
unsigned int data_unit_size_bits;
unsigned int size;
u8 raw[BLK_CRYPTO_MAX_KEY_SIZE];
};
#endif /* __LINUX_BLK_CRYPTO_H */
......@@ -43,6 +43,7 @@ struct pr_ops;
struct rq_qos;
struct blk_queue_stats;
struct blk_stat_callback;
struct blk_keyslot_manager;
#define BLKDEV_MIN_RQ 4
#define BLKDEV_MAX_RQ 128 /* Default maximum */
......@@ -468,6 +469,11 @@ struct request_queue {
unsigned int dma_pad_mask;
unsigned int dma_alignment;
#ifdef CONFIG_BLK_INLINE_ENCRYPTION
/* Inline crypto capabilities */
struct blk_keyslot_manager *ksm;
#endif
unsigned int rq_timeout;
int poll_nsec;
......
/* SPDX-License-Identifier: GPL-2.0 */
/*
* Copyright 2019 Google LLC
*/
#ifndef __LINUX_KEYSLOT_MANAGER_H
#define __LINUX_KEYSLOT_MANAGER_H
#include <linux/bio.h>
#include <linux/blk-crypto.h>
struct blk_keyslot_manager;
/**
* struct blk_ksm_ll_ops - functions to manage keyslots in hardware
* @keyslot_program: Program the specified key into the specified slot in the
* inline encryption hardware.
* @keyslot_evict: Evict key from the specified keyslot in the hardware.
* The key is provided so that e.g. dm layers can evict
* keys from the devices that they map over.
* Returns 0 on success, -errno otherwise.
*
* This structure should be provided by storage device drivers when they set up
* a keyslot manager - this structure holds the function ptrs that the keyslot
* manager will use to manipulate keyslots in the hardware.
*/
struct blk_ksm_ll_ops {
int (*keyslot_program)(struct blk_keyslot_manager *ksm,
const struct blk_crypto_key *key,
unsigned int slot);
int (*keyslot_evict)(struct blk_keyslot_manager *ksm,
const struct blk_crypto_key *key,
unsigned int slot);
};
struct blk_keyslot_manager {
/*
* The struct blk_ksm_ll_ops that this keyslot manager will use
* to perform operations like programming and evicting keys on the
* device
*/
struct blk_ksm_ll_ops ksm_ll_ops;
/*
* The maximum number of bytes supported for specifying the data unit
* number.
*/
unsigned int max_dun_bytes_supported;
/*
* Array of size BLK_ENCRYPTION_MODE_MAX of bitmasks that represents
* whether a crypto mode and data unit size are supported. The i'th
* bit of crypto_mode_supported[crypto_mode] is set iff a data unit
* size of (1 << i) is supported. We only support data unit sizes
* that are powers of 2.
*/
unsigned int crypto_modes_supported[BLK_ENCRYPTION_MODE_MAX];
/* Device for runtime power management (NULL if none) */
struct device *dev;
/* Here onwards are *private* fields for internal keyslot manager use */
unsigned int num_slots;
/* Protects programming and evicting keys from the device */
struct rw_semaphore lock;
/* List of idle slots, with least recently used slot at front */
wait_queue_head_t idle_slots_wait_queue;
struct list_head idle_slots;
spinlock_t idle_slots_lock;
/*
* Hash table which maps struct *blk_crypto_key to keyslots, so that we
* can find a key's keyslot in O(1) time rather than O(num_slots).
* Protected by 'lock'.
*/
struct hlist_head *slot_hashtable;
unsigned int log_slot_ht_size;
/* Per-keyslot data */
struct blk_ksm_keyslot *slots;
};
int blk_ksm_init(struct blk_keyslot_manager *ksm, unsigned int num_slots);
blk_status_t blk_ksm_get_slot_for_key(struct blk_keyslot_manager *ksm,
const struct blk_crypto_key *key,
struct blk_ksm_keyslot **slot_ptr);
unsigned int blk_ksm_get_slot_idx(struct blk_ksm_keyslot *slot);
void blk_ksm_put_slot(struct blk_ksm_keyslot *slot);
bool blk_ksm_crypto_cfg_supported(struct blk_keyslot_manager *ksm,
const struct blk_crypto_config *cfg);
int blk_ksm_evict_key(struct blk_keyslot_manager *ksm,
const struct blk_crypto_key *key);
void blk_ksm_reprogram_all_keys(struct blk_keyslot_manager *ksm);
void blk_ksm_destroy(struct blk_keyslot_manager *ksm);
#endif /* __LINUX_KEYSLOT_MANAGER_H */
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment