235 lines · 7.7 KB · C
RawDownload
/* SPDX-License-Identifier: GPL-2.0 *//* * Copyright 2019 Google LLC */ #ifndef __LINUX_BLK_CRYPTO_H#define __LINUX_BLK_CRYPTO_H #include <linux/minmax.h>#include <linux/types.h>#include <uapi/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_SM4_XTS,	BLK_ENCRYPTION_MODE_MAX,}; /* * Supported types of keys.  Must be bitflags due to their use in * blk_crypto_profile::key_types_supported. */enum blk_crypto_key_type {	/*	 * Raw keys (i.e. "software keys").  These keys are simply kept in raw,	 * plaintext form in kernel memory.	 */	BLK_CRYPTO_KEY_TYPE_RAW = 0x1, 	/*	 * Hardware-wrapped keys.  These keys are only present in kernel memory	 * in ephemerally-wrapped form, and they can only be unwrapped by	 * dedicated hardware.  For details, see the "Hardware-wrapped keys"	 * section of Documentation/block/inline-encryption.rst.	 */	BLK_CRYPTO_KEY_TYPE_HW_WRAPPED = 0x2,}; /* * Currently the maximum raw key size is 64 bytes, as that is the key size of * BLK_ENCRYPTION_MODE_AES_256_XTS which takes the longest key. * * The maximum hardware-wrapped key size depends on the hardware's key wrapping * algorithm, which is a hardware implementation detail, so it isn't precisely * specified.  But currently 128 bytes is plenty in practice.  Implementations * are recommended to wrap a 32-byte key for the hardware KDF with AES-256-GCM, * which should result in a size closer to 64 bytes than 128. * * Both of these values can trivially be increased if ever needed. */#define BLK_CRYPTO_MAX_RAW_KEY_SIZE		64#define BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE	128 #define BLK_CRYPTO_MAX_ANY_KEY_SIZE \	MAX(BLK_CRYPTO_MAX_RAW_KEY_SIZE, BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE) /* * Size of the "software secret" which can be derived from a hardware-wrapped * key.  This is currently always 32 bytes.  Note, the choice of 32 bytes * assumes that the software secret is only used directly for algorithms that * don't require more than a 256-bit key to get the desired security strength. * If it were to be used e.g. directly as an AES-256-XTS key, then this would * need to be increased (which is possible if hardware supports it, but care * would need to be taken to avoid breaking users who need exactly 32 bytes). */#define BLK_CRYPTO_SW_SECRET_SIZE	32 /* Flags for blk_crypto_config::flags: */ /* * If set, inline encryption hardware will be used if available. * If unset, CPU-based encryption will always be used (requires * CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK) */#define BLK_CRYPTO_CFG_ALLOW_HW		(1 << 0) /** * 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 * @key_type: the type of this key -- either raw or hardware-wrapped * @flags: BLK_CRYPTO_CFG_* flags */struct blk_crypto_config {	enum blk_crypto_mode_num crypto_mode;	unsigned int data_unit_size;	unsigned int dun_bytes;	enum blk_crypto_key_type key_type;	int flags;}; /** * struct blk_crypto_key - an inline encryption key * @crypto_cfg: the crypto mode, data unit size, key type, and other *		characteristics of this key and how it will be used * @data_unit_size_bits: log2 of data_unit_size * @size: size of this key in bytes.  The size of a raw key is fixed for a given *	  crypto mode, but the size of a hardware-wrapped key can vary. * @bytes: the bytes of this key.  Only the first @size bytes are significant. * * 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 bytes[BLK_CRYPTO_MAX_ANY_KEY_SIZE];}; #define BLK_CRYPTO_MAX_IV_SIZE		32#define BLK_CRYPTO_DUN_ARRAY_SIZE	(BLK_CRYPTO_MAX_IV_SIZE / sizeof(u64)) /** * struct bio_crypt_ctx - an inline encryption context * @bc_key: the key, algorithm, and data unit size to use * @bc_dun: the data unit number (starting IV) to use * * A bio_crypt_ctx specifies that the contents of the bio will be encrypted (for * write requests) or decrypted (for read requests) inline by the storage device * or controller, or by the crypto API fallback. */struct bio_crypt_ctx {	const struct blk_crypto_key	*bc_key;	u64				bc_dun[BLK_CRYPTO_DUN_ARRAY_SIZE];}; #include <linux/blk_types.h>#include <linux/blkdev.h> #ifdef CONFIG_BLK_INLINE_ENCRYPTION static inline bool bio_has_crypt_ctx(struct bio *bio){	return bio->bi_crypt_context;} static inline struct bio_crypt_ctx *bio_crypt_ctx(struct bio *bio){	return bio->bi_crypt_context;} void bio_crypt_set_ctx(struct bio *bio, const struct blk_crypto_key *key,		       const u64 dun[BLK_CRYPTO_DUN_ARRAY_SIZE],		       gfp_t gfp_mask); bool bio_crypt_dun_is_contiguous(const struct bio_crypt_ctx *bc,				 unsigned int bytes,				 const u64 next_dun[BLK_CRYPTO_DUN_ARRAY_SIZE]); int blk_crypto_init_key(struct blk_crypto_key *blk_key,			const u8 *key_bytes, size_t key_size,			enum blk_crypto_key_type key_type,			enum blk_crypto_mode_num crypto_mode,			unsigned int dun_bytes,			unsigned int data_unit_size, int flags); int blk_crypto_start_using_key(struct block_device *bdev,			       const struct blk_crypto_key *key); void blk_crypto_evict_key(struct block_device *bdev,			  const struct blk_crypto_key *key); bool blk_crypto_config_supported_natively(struct block_device *bdev,					  const struct blk_crypto_config *cfg); int blk_crypto_derive_sw_secret(struct block_device *bdev,				const u8 *eph_key, size_t eph_key_size,				u8 sw_secret[BLK_CRYPTO_SW_SECRET_SIZE]); #else /* CONFIG_BLK_INLINE_ENCRYPTION */ static inline bool bio_has_crypt_ctx(struct bio *bio){	return false;} static inline struct bio_crypt_ctx *bio_crypt_ctx(struct bio *bio){	return NULL;} #endif /* CONFIG_BLK_INLINE_ENCRYPTION */ bool __blk_crypto_submit_bio(struct bio *bio); /** * blk_crypto_submit_bio - Submit a bio that may have a crypto context * @bio: bio to submit * * If @bio has no crypto context, or the crypt context attached to @bio is * supported by the underlying device's inline encryption hardware, just submit * @bio. * * Otherwise, try to perform en/decryption for this bio by falling back to the * kernel crypto API. For encryption this means submitting newly allocated * bios for the encrypted payload while keeping back the source bio until they * complete, while for reads the decryption happens in-place by a hooked in * completion handler. */static inline void blk_crypto_submit_bio(struct bio *bio){	if (!bio_has_crypt_ctx(bio) || __blk_crypto_submit_bio(bio))		submit_bio(bio);} int __bio_crypt_clone(struct bio *dst, struct bio *src, gfp_t gfp_mask);/** * bio_crypt_clone - clone bio encryption context * @dst: destination bio * @src: source bio * @gfp_mask: memory allocation flags * * If @src has an encryption context, clone it to @dst. * * Return: 0 on success, -ENOMEM if out of memory.  -ENOMEM is only possible if *	   @gfp_mask doesn't include %__GFP_DIRECT_RECLAIM. */static inline int bio_crypt_clone(struct bio *dst, struct bio *src,				  gfp_t gfp_mask){	if (bio_has_crypt_ctx(src))		return __bio_crypt_clone(dst, src, gfp_mask);	return 0;} #endif /* __LINUX_BLK_CRYPTO_H */

Keyboard shortcuts

General

Show keyboard shortcuts
?
Focus the current search
/

Issues and pull requests

Open filters
f

Issues, pull requests and Inbox

Select next item
j↓
Select previous item
k↑
Open selected item
Enter
Dismiss filters or clear selection
Esc

Repository code

Go to file
t