2019-10-24 15:44:25 -06:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
|
|
|
/*
|
|
|
|
* Copyright 2019 Google LLC
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Refer to Documentation/block/inline-encryption.rst for detailed explanation.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define pr_fmt(fmt) "blk-crypto: " fmt
|
|
|
|
|
|
|
|
#include <linux/blk-crypto.h>
|
2019-12-17 15:26:29 -07:00
|
|
|
#include <linux/blkdev.h>
|
2019-10-24 15:44:25 -06:00
|
|
|
#include <linux/keyslot-manager.h>
|
2019-12-17 15:26:29 -07:00
|
|
|
#include <linux/random.h>
|
|
|
|
#include <linux/siphash.h>
|
|
|
|
|
|
|
|
#include "blk-crypto-internal.h"
|
2019-10-24 15:44:25 -06:00
|
|
|
|
2019-12-17 15:26:29 -07:00
|
|
|
const struct blk_crypto_mode blk_crypto_modes[] = {
|
2019-10-24 15:44:25 -06:00
|
|
|
[BLK_ENCRYPTION_MODE_AES_256_XTS] = {
|
|
|
|
.cipher_str = "xts(aes)",
|
|
|
|
.keysize = 64,
|
2019-12-17 15:26:29 -07:00
|
|
|
.ivsize = 16,
|
|
|
|
},
|
|
|
|
[BLK_ENCRYPTION_MODE_AES_128_CBC_ESSIV] = {
|
|
|
|
.cipher_str = "essiv(cbc(aes),sha256)",
|
|
|
|
.keysize = 16,
|
|
|
|
.ivsize = 16,
|
|
|
|
},
|
|
|
|
[BLK_ENCRYPTION_MODE_ADIANTUM] = {
|
|
|
|
.cipher_str = "adiantum(xchacha12,aes)",
|
|
|
|
.keysize = 32,
|
|
|
|
.ivsize = 32,
|
2019-10-24 15:44:25 -06:00
|
|
|
},
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Check that all I/O segments are data unit aligned */
|
|
|
|
static int bio_crypt_check_alignment(struct bio *bio)
|
|
|
|
{
|
2019-12-17 15:26:29 -07:00
|
|
|
const unsigned int data_unit_size =
|
|
|
|
bio->bi_crypt_context->bc_key->data_unit_size;
|
2019-10-24 15:44:25 -06:00
|
|
|
struct bvec_iter iter;
|
|
|
|
struct bio_vec bv;
|
|
|
|
|
|
|
|
bio_for_each_segment(bv, bio, iter) {
|
|
|
|
if (!IS_ALIGNED(bv.bv_len | bv.bv_offset, data_unit_size))
|
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* blk_crypto_submit_bio - handle submitting bio for inline encryption
|
|
|
|
*
|
|
|
|
* @bio_ptr: pointer to original bio pointer
|
|
|
|
*
|
|
|
|
* If the bio doesn't have inline encryption enabled or the submitter already
|
|
|
|
* specified a keyslot for the target device, do nothing. Else, a raw key must
|
|
|
|
* have been provided, so acquire a device keyslot for it if supported. Else,
|
|
|
|
* use the crypto API fallback.
|
|
|
|
*
|
|
|
|
* When the crypto API fallback is used for encryption, blk-crypto may choose to
|
|
|
|
* split the bio into 2 - the first one that will continue to be processed and
|
|
|
|
* the second one that will be resubmitted via generic_make_request.
|
|
|
|
* A bounce bio will be allocated to encrypt the contents of the aforementioned
|
|
|
|
* "first one", and *bio_ptr will be updated to this bounce bio.
|
|
|
|
*
|
|
|
|
* Return: 0 if bio submission should continue; nonzero if bio_endio() was
|
|
|
|
* already called so bio submission should abort.
|
|
|
|
*/
|
|
|
|
int blk_crypto_submit_bio(struct bio **bio_ptr)
|
|
|
|
{
|
|
|
|
struct bio *bio = *bio_ptr;
|
|
|
|
struct request_queue *q;
|
2019-12-17 15:26:29 -07:00
|
|
|
struct bio_crypt_ctx *bc = bio->bi_crypt_context;
|
2019-10-24 15:44:25 -06:00
|
|
|
int err;
|
|
|
|
|
2019-12-17 15:26:29 -07:00
|
|
|
if (!bc || !bio_has_data(bio))
|
2019-10-24 15:44:25 -06:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
2019-12-17 15:26:29 -07:00
|
|
|
* When a read bio is marked for fallback decryption, its bi_iter is
|
|
|
|
* saved so that when we decrypt the bio later, we know what part of it
|
|
|
|
* was marked for fallback decryption (when the bio is passed down after
|
2019-10-24 15:44:25 -06:00
|
|
|
* blk_crypto_submit bio, it may be split or advanced so we cannot rely
|
|
|
|
* on the bi_iter while decrypting in blk_crypto_endio)
|
|
|
|
*/
|
2019-12-17 15:26:29 -07:00
|
|
|
if (bio_crypt_fallback_crypted(bc))
|
2019-10-24 15:44:25 -06:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
err = bio_crypt_check_alignment(bio);
|
|
|
|
if (err) {
|
|
|
|
bio->bi_status = BLK_STS_IOERR;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
q = bio->bi_disk->queue;
|
|
|
|
|
2019-12-17 15:26:29 -07:00
|
|
|
if (bc->bc_ksm) {
|
2019-10-24 15:44:25 -06:00
|
|
|
/* Key already programmed into device? */
|
2019-12-17 15:26:29 -07:00
|
|
|
if (q->ksm == bc->bc_ksm)
|
2019-10-24 15:44:25 -06:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* Nope, release the existing keyslot. */
|
2019-12-17 15:26:29 -07:00
|
|
|
bio_crypt_ctx_release_keyslot(bc);
|
2019-10-24 15:44:25 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Get device keyslot if supported */
|
2019-12-17 15:26:29 -07:00
|
|
|
if (keyslot_manager_crypto_mode_supported(q->ksm,
|
2020-05-06 15:15:06 -06:00
|
|
|
bc->bc_key->crypto_mode,
|
|
|
|
blk_crypto_key_dun_bytes(bc->bc_key),
|
|
|
|
bc->bc_key->data_unit_size,
|
|
|
|
bc->bc_key->is_hw_wrapped)) {
|
2019-12-17 15:26:29 -07:00
|
|
|
err = bio_crypt_ctx_acquire_keyslot(bc, q->ksm);
|
2019-10-24 15:44:25 -06:00
|
|
|
if (!err)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
pr_warn_once("Failed to acquire keyslot for %s (err=%d). Falling back to crypto API.\n",
|
|
|
|
bio->bi_disk->disk_name, err);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Fallback to crypto API */
|
2019-12-17 15:26:29 -07:00
|
|
|
err = blk_crypto_fallback_submit_bio(bio_ptr);
|
|
|
|
if (err)
|
2019-10-24 15:44:25 -06:00
|
|
|
goto out;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
out:
|
|
|
|
bio_endio(*bio_ptr);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* blk_crypto_endio - clean up bio w.r.t inline encryption during bio_endio
|
|
|
|
*
|
2019-12-17 15:26:29 -07:00
|
|
|
* @bio: the bio to clean up
|
2019-10-24 15:44:25 -06:00
|
|
|
*
|
2019-12-17 15:26:29 -07:00
|
|
|
* If blk_crypto_submit_bio decided to fallback to crypto API for this bio,
|
|
|
|
* we queue the bio for decryption into a workqueue and return false,
|
2019-10-24 15:44:25 -06:00
|
|
|
* and call bio_endio(bio) at a later time (after the bio has been decrypted).
|
|
|
|
*
|
|
|
|
* If the bio is not to be decrypted by the crypto API, this function releases
|
|
|
|
* the reference to the keyslot that blk_crypto_submit_bio got.
|
|
|
|
*
|
|
|
|
* Return: true if bio_endio should continue; false otherwise (bio_endio will
|
|
|
|
* be called again when bio has been decrypted).
|
|
|
|
*/
|
|
|
|
bool blk_crypto_endio(struct bio *bio)
|
|
|
|
{
|
2019-12-17 15:26:29 -07:00
|
|
|
struct bio_crypt_ctx *bc = bio->bi_crypt_context;
|
|
|
|
|
|
|
|
if (!bc)
|
2019-10-24 15:44:25 -06:00
|
|
|
return true;
|
|
|
|
|
2019-12-17 15:26:29 -07:00
|
|
|
if (bio_crypt_fallback_crypted(bc)) {
|
2019-10-24 15:44:25 -06:00
|
|
|
/*
|
2019-12-17 15:26:29 -07:00
|
|
|
* The only bios who's crypto is handled by the blk-crypto
|
|
|
|
* fallback when they reach here are those with
|
|
|
|
* bio_data_dir(bio) == READ, since WRITE bios that are
|
|
|
|
* encrypted by the crypto API fallback are handled by
|
|
|
|
* blk_crypto_encrypt_endio().
|
2019-10-24 15:44:25 -06:00
|
|
|
*/
|
2019-12-17 15:26:29 -07:00
|
|
|
return !blk_crypto_queue_decrypt_bio(bio);
|
2019-10-24 15:44:25 -06:00
|
|
|
}
|
|
|
|
|
2019-12-17 15:26:29 -07:00
|
|
|
if (bc->bc_keyslot >= 0)
|
|
|
|
bio_crypt_ctx_release_keyslot(bc);
|
2019-10-24 15:44:25 -06:00
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2019-12-17 15:26:29 -07:00
|
|
|
* blk_crypto_init_key() - Prepare a key for use with blk-crypto
|
|
|
|
* @blk_key: Pointer to the blk_crypto_key to initialize.
|
2020-01-02 12:57:39 -07:00
|
|
|
* @raw_key: Pointer to the raw key.
|
|
|
|
* @raw_key_size: Size of raw key. Must be at least the required size for the
|
|
|
|
* chosen @crypto_mode; see blk_crypto_modes[]. (It's allowed
|
|
|
|
* to be longer than the mode's actual key size, in order to
|
2020-02-06 19:01:20 -07:00
|
|
|
* support inline encryption hardware that accepts wrapped keys.
|
|
|
|
* @is_hw_wrapped has to be set for such keys)
|
|
|
|
* @is_hw_wrapped: Denotes @raw_key is wrapped.
|
2019-12-17 15:26:29 -07:00
|
|
|
* @crypto_mode: identifier for the encryption algorithm to use
|
2020-05-06 15:15:06 -06:00
|
|
|
* @dun_bytes: number of bytes that will be used to specify the DUN when this
|
|
|
|
* key is used
|
2019-12-17 15:26:29 -07:00
|
|
|
* @data_unit_size: the data unit size to use for en/decryption
|
2019-10-24 15:44:25 -06:00
|
|
|
*
|
2019-12-17 15:26:29 -07:00
|
|
|
* Return: The blk_crypto_key that was prepared, or an ERR_PTR() on error. When
|
|
|
|
* done using the key, it must be freed with blk_crypto_free_key().
|
2019-10-24 15:44:25 -06:00
|
|
|
*/
|
2020-01-02 12:57:39 -07:00
|
|
|
int blk_crypto_init_key(struct blk_crypto_key *blk_key,
|
|
|
|
const u8 *raw_key, unsigned int raw_key_size,
|
2020-02-06 19:01:20 -07:00
|
|
|
bool is_hw_wrapped,
|
2019-12-17 15:26:29 -07:00
|
|
|
enum blk_crypto_mode_num crypto_mode,
|
2020-05-06 15:15:06 -06:00
|
|
|
unsigned int dun_bytes,
|
2019-12-17 15:26:29 -07:00
|
|
|
unsigned int data_unit_size)
|
2019-10-24 15:44:25 -06:00
|
|
|
{
|
2019-12-17 15:26:29 -07:00
|
|
|
const struct blk_crypto_mode *mode;
|
|
|
|
static siphash_key_t hash_key;
|
2020-05-06 15:15:06 -06:00
|
|
|
u32 hash;
|
2019-10-24 15:44:25 -06:00
|
|
|
|
2019-12-17 15:26:29 -07:00
|
|
|
memset(blk_key, 0, sizeof(*blk_key));
|
2019-10-24 15:44:25 -06:00
|
|
|
|
2019-12-17 15:26:29 -07:00
|
|
|
if (crypto_mode >= ARRAY_SIZE(blk_crypto_modes))
|
|
|
|
return -EINVAL;
|
2019-10-24 15:44:25 -06:00
|
|
|
|
2020-01-02 12:57:39 -07:00
|
|
|
BUILD_BUG_ON(BLK_CRYPTO_MAX_WRAPPED_KEY_SIZE < BLK_CRYPTO_MAX_KEY_SIZE);
|
|
|
|
|
2019-12-17 15:26:29 -07:00
|
|
|
mode = &blk_crypto_modes[crypto_mode];
|
2020-02-06 19:01:20 -07:00
|
|
|
if (is_hw_wrapped) {
|
|
|
|
if (raw_key_size < mode->keysize ||
|
|
|
|
raw_key_size > BLK_CRYPTO_MAX_WRAPPED_KEY_SIZE)
|
|
|
|
return -EINVAL;
|
|
|
|
} else {
|
|
|
|
if (raw_key_size != mode->keysize)
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2019-10-24 15:44:25 -06:00
|
|
|
|
2020-05-06 15:15:06 -06:00
|
|
|
if (dun_bytes <= 0 || dun_bytes > BLK_CRYPTO_MAX_IV_SIZE)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2019-12-17 15:26:29 -07:00
|
|
|
if (!is_power_of_2(data_unit_size))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
blk_key->crypto_mode = crypto_mode;
|
|
|
|
blk_key->data_unit_size = data_unit_size;
|
|
|
|
blk_key->data_unit_size_bits = ilog2(data_unit_size);
|
2020-01-02 12:57:39 -07:00
|
|
|
blk_key->size = raw_key_size;
|
2020-02-06 19:01:20 -07:00
|
|
|
blk_key->is_hw_wrapped = is_hw_wrapped;
|
2020-01-02 12:57:39 -07:00
|
|
|
memcpy(blk_key->raw, raw_key, raw_key_size);
|
2019-10-24 15:44:25 -06:00
|
|
|
|
|
|
|
/*
|
2019-12-17 15:26:29 -07:00
|
|
|
* The keyslot manager uses the SipHash of the key to implement O(1) key
|
|
|
|
* lookups while avoiding leaking information about the keys. It's
|
|
|
|
* precomputed here so that it only needs to be computed once per key.
|
2019-10-24 15:44:25 -06:00
|
|
|
*/
|
2019-12-17 15:26:29 -07:00
|
|
|
get_random_once(&hash_key, sizeof(hash_key));
|
2020-05-06 15:15:06 -06:00
|
|
|
hash = (u32)siphash(raw_key, raw_key_size, &hash_key);
|
|
|
|
blk_crypto_key_set_hash_and_dun_bytes(blk_key, hash, dun_bytes);
|
2019-12-17 15:26:29 -07:00
|
|
|
|
|
|
|
return 0;
|
2019-10-24 15:44:25 -06:00
|
|
|
}
|
2020-01-22 13:32:33 -07:00
|
|
|
EXPORT_SYMBOL_GPL(blk_crypto_init_key);
|
2019-10-24 15:44:25 -06:00
|
|
|
|
2020-04-03 13:06:10 -06:00
|
|
|
/**
|
|
|
|
* blk_crypto_start_using_mode() - Start using blk-crypto on a device
|
|
|
|
* @crypto_mode: the crypto mode that will be used
|
2020-05-06 15:15:06 -06:00
|
|
|
* @dun_bytes: number of bytes that will be used to specify the DUN
|
2020-04-03 13:06:10 -06:00
|
|
|
* @data_unit_size: the data unit size that will be used
|
ANDROID: block: require drivers to declare supported crypto key type(s)
We need a way to tell which type of keys the inline crypto hardware
supports (standard, wrapped, or both), so that fallbacks can be used
when needed (either blk-crypto-fallback, or fscrypt fs-layer crypto).
We can't simply assume that
keyslot_mgmt_ll_ops::derive_raw_secret == NULL
means only standard keys are supported and that
keyslot_mgmt_ll_ops::derive_raw_secret != NULL
means that only wrapped keys are supported, because device-mapper
devices always implement this method. Also, hardware might support both
types of keys.
Therefore, add a field keyslot_manager::features which contains a
bitmask of flags which indicate the supported types of keys. Drivers
will need to fill this in. This patch makes the UFS standard crypto
code set BLK_CRYPTO_FEATURE_STANDARD_KEYS, but UFS variant drivers may
need to set BLK_CRYPTO_FEATURE_WRAPPED_KEYS instead.
Then, make keyslot_manager_crypto_mode_supported() take the key type
into account.
Bug: 137270441
Bug: 151100202
Test: 'atest vts_kernel_encryption_test' on Pixel 4 with the
inline crypto patches backported, and also on Cuttlefish.
Change-Id: Ied846c2767c1fd2f438792dcfd3649157e68b005
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-04-03 13:06:11 -06:00
|
|
|
* @is_hw_wrapped_key: whether the key will be hardware-wrapped
|
2020-04-03 13:06:10 -06:00
|
|
|
* @q: the request queue for the device
|
|
|
|
*
|
|
|
|
* Upper layers must call this function to ensure that either the hardware
|
|
|
|
* supports the needed crypto settings, or the crypto API fallback has
|
|
|
|
* transforms for the needed mode allocated and ready to go.
|
|
|
|
*
|
|
|
|
* Return: 0 on success; -ENOPKG if the hardware doesn't support the crypto
|
|
|
|
* settings and blk-crypto-fallback is either disabled or the needed
|
|
|
|
* algorithm is disabled in the crypto API; or another -errno code.
|
|
|
|
*/
|
|
|
|
int blk_crypto_start_using_mode(enum blk_crypto_mode_num crypto_mode,
|
2020-05-06 15:15:06 -06:00
|
|
|
unsigned int dun_bytes,
|
2020-04-03 13:06:10 -06:00
|
|
|
unsigned int data_unit_size,
|
ANDROID: block: require drivers to declare supported crypto key type(s)
We need a way to tell which type of keys the inline crypto hardware
supports (standard, wrapped, or both), so that fallbacks can be used
when needed (either blk-crypto-fallback, or fscrypt fs-layer crypto).
We can't simply assume that
keyslot_mgmt_ll_ops::derive_raw_secret == NULL
means only standard keys are supported and that
keyslot_mgmt_ll_ops::derive_raw_secret != NULL
means that only wrapped keys are supported, because device-mapper
devices always implement this method. Also, hardware might support both
types of keys.
Therefore, add a field keyslot_manager::features which contains a
bitmask of flags which indicate the supported types of keys. Drivers
will need to fill this in. This patch makes the UFS standard crypto
code set BLK_CRYPTO_FEATURE_STANDARD_KEYS, but UFS variant drivers may
need to set BLK_CRYPTO_FEATURE_WRAPPED_KEYS instead.
Then, make keyslot_manager_crypto_mode_supported() take the key type
into account.
Bug: 137270441
Bug: 151100202
Test: 'atest vts_kernel_encryption_test' on Pixel 4 with the
inline crypto patches backported, and also on Cuttlefish.
Change-Id: Ied846c2767c1fd2f438792dcfd3649157e68b005
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-04-03 13:06:11 -06:00
|
|
|
bool is_hw_wrapped_key,
|
2020-04-03 13:06:10 -06:00
|
|
|
struct request_queue *q)
|
|
|
|
{
|
|
|
|
if (keyslot_manager_crypto_mode_supported(q->ksm, crypto_mode,
|
2020-05-06 15:15:06 -06:00
|
|
|
dun_bytes, data_unit_size,
|
ANDROID: block: require drivers to declare supported crypto key type(s)
We need a way to tell which type of keys the inline crypto hardware
supports (standard, wrapped, or both), so that fallbacks can be used
when needed (either blk-crypto-fallback, or fscrypt fs-layer crypto).
We can't simply assume that
keyslot_mgmt_ll_ops::derive_raw_secret == NULL
means only standard keys are supported and that
keyslot_mgmt_ll_ops::derive_raw_secret != NULL
means that only wrapped keys are supported, because device-mapper
devices always implement this method. Also, hardware might support both
types of keys.
Therefore, add a field keyslot_manager::features which contains a
bitmask of flags which indicate the supported types of keys. Drivers
will need to fill this in. This patch makes the UFS standard crypto
code set BLK_CRYPTO_FEATURE_STANDARD_KEYS, but UFS variant drivers may
need to set BLK_CRYPTO_FEATURE_WRAPPED_KEYS instead.
Then, make keyslot_manager_crypto_mode_supported() take the key type
into account.
Bug: 137270441
Bug: 151100202
Test: 'atest vts_kernel_encryption_test' on Pixel 4 with the
inline crypto patches backported, and also on Cuttlefish.
Change-Id: Ied846c2767c1fd2f438792dcfd3649157e68b005
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-04-03 13:06:11 -06:00
|
|
|
is_hw_wrapped_key))
|
2020-04-03 13:06:10 -06:00
|
|
|
return 0;
|
ANDROID: block: require drivers to declare supported crypto key type(s)
We need a way to tell which type of keys the inline crypto hardware
supports (standard, wrapped, or both), so that fallbacks can be used
when needed (either blk-crypto-fallback, or fscrypt fs-layer crypto).
We can't simply assume that
keyslot_mgmt_ll_ops::derive_raw_secret == NULL
means only standard keys are supported and that
keyslot_mgmt_ll_ops::derive_raw_secret != NULL
means that only wrapped keys are supported, because device-mapper
devices always implement this method. Also, hardware might support both
types of keys.
Therefore, add a field keyslot_manager::features which contains a
bitmask of flags which indicate the supported types of keys. Drivers
will need to fill this in. This patch makes the UFS standard crypto
code set BLK_CRYPTO_FEATURE_STANDARD_KEYS, but UFS variant drivers may
need to set BLK_CRYPTO_FEATURE_WRAPPED_KEYS instead.
Then, make keyslot_manager_crypto_mode_supported() take the key type
into account.
Bug: 137270441
Bug: 151100202
Test: 'atest vts_kernel_encryption_test' on Pixel 4 with the
inline crypto patches backported, and also on Cuttlefish.
Change-Id: Ied846c2767c1fd2f438792dcfd3649157e68b005
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-04-03 13:06:11 -06:00
|
|
|
if (is_hw_wrapped_key) {
|
|
|
|
pr_warn_once("hardware doesn't support wrapped keys\n");
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
2020-04-03 13:06:10 -06:00
|
|
|
return blk_crypto_fallback_start_using_mode(crypto_mode);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(blk_crypto_start_using_mode);
|
|
|
|
|
2019-10-24 15:44:25 -06:00
|
|
|
/**
|
|
|
|
* blk_crypto_evict_key() - Evict a key from any inline encryption hardware
|
|
|
|
* it may have been programmed into
|
2019-12-17 15:26:29 -07:00
|
|
|
* @q: The request queue who's keyslot manager this key might have been
|
|
|
|
* programmed into
|
|
|
|
* @key: The key to evict
|
2019-10-24 15:44:25 -06:00
|
|
|
*
|
|
|
|
* Upper layers (filesystems) should call this function to ensure that a key
|
|
|
|
* is evicted from hardware that it might have been programmed into. This
|
|
|
|
* will call keyslot_manager_evict_key on the queue's keyslot manager, if one
|
|
|
|
* exists, and supports the crypto algorithm with the specified data unit size.
|
2019-12-17 15:26:29 -07:00
|
|
|
* Otherwise, it will evict the key from the blk-crypto-fallback's ksm.
|
2019-10-24 15:44:25 -06:00
|
|
|
*
|
|
|
|
* Return: 0 on success, -err on error.
|
|
|
|
*/
|
2019-12-17 15:26:29 -07:00
|
|
|
int blk_crypto_evict_key(struct request_queue *q,
|
|
|
|
const struct blk_crypto_key *key)
|
2019-10-24 15:44:25 -06:00
|
|
|
{
|
2019-12-17 15:26:29 -07:00
|
|
|
if (q->ksm &&
|
|
|
|
keyslot_manager_crypto_mode_supported(q->ksm, key->crypto_mode,
|
2020-05-06 15:15:06 -06:00
|
|
|
blk_crypto_key_dun_bytes(key),
|
ANDROID: block: require drivers to declare supported crypto key type(s)
We need a way to tell which type of keys the inline crypto hardware
supports (standard, wrapped, or both), so that fallbacks can be used
when needed (either blk-crypto-fallback, or fscrypt fs-layer crypto).
We can't simply assume that
keyslot_mgmt_ll_ops::derive_raw_secret == NULL
means only standard keys are supported and that
keyslot_mgmt_ll_ops::derive_raw_secret != NULL
means that only wrapped keys are supported, because device-mapper
devices always implement this method. Also, hardware might support both
types of keys.
Therefore, add a field keyslot_manager::features which contains a
bitmask of flags which indicate the supported types of keys. Drivers
will need to fill this in. This patch makes the UFS standard crypto
code set BLK_CRYPTO_FEATURE_STANDARD_KEYS, but UFS variant drivers may
need to set BLK_CRYPTO_FEATURE_WRAPPED_KEYS instead.
Then, make keyslot_manager_crypto_mode_supported() take the key type
into account.
Bug: 137270441
Bug: 151100202
Test: 'atest vts_kernel_encryption_test' on Pixel 4 with the
inline crypto patches backported, and also on Cuttlefish.
Change-Id: Ied846c2767c1fd2f438792dcfd3649157e68b005
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-04-03 13:06:11 -06:00
|
|
|
key->data_unit_size,
|
|
|
|
key->is_hw_wrapped))
|
2019-12-17 15:26:29 -07:00
|
|
|
return keyslot_manager_evict_key(q->ksm, key);
|
2019-10-24 15:44:25 -06:00
|
|
|
|
2019-12-17 15:26:29 -07:00
|
|
|
return blk_crypto_fallback_evict_key(key);
|
2019-10-24 15:44:25 -06:00
|
|
|
}
|
2020-01-22 13:32:33 -07:00
|
|
|
EXPORT_SYMBOL_GPL(blk_crypto_evict_key);
|