Something went wrong. Try again.
Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Something went wrong. Try again.
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227/* 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
/** * 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 */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;};
/** * 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 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);bool blk_crypto_config_supported(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 */