blk-crypto: show crypto capabilities in sysfs
Add sysfs files that expose the inline encryption capabilities of
request queues:
/sys/block/$disk/queue/crypto/max_dun_bits
/sys/block/$disk/queue/crypto/modes/$mode
/sys/block/$disk/queue/crypto/num_keyslots
Userspace can use these new files to decide what encryption settings to
use, or whether to use inline encryption at all. This also brings the
crypto capabilities in line with the other queue properties, which are
already discoverable via the queue directory in sysfs.
Design notes:
- Place the new files in a new subdirectory "crypto" to group them
together and to avoid complicating the main "queue" directory. This
also makes it possible to replace "crypto" with a symlink later if
we ever make the blk_crypto_profiles into real kobjects (see below).
- It was necessary to define a new kobject that corresponds to the
crypto subdirectory. For now, this kobject just contains a pointer
to the blk_crypto_profile. Note that multiple queues (and hence
multiple such kobjects) may refer to the same blk_crypto_profile.
An alternative design would more closely match the current kernel
data structures: the blk_crypto_profile could be a kobject itself,
located directly under the host controller device's kobject, while
/sys/block/$disk/queue/crypto would be a symlink to it.
I decided not to do that for now because it would require a lot more
changes, such as no longer embedding blk_crypto_profile in other
structures, and also because I'm not sure we can rule out moving the
crypto capabilities into 'struct queue_limits' in the future. (Even
if multiple queues share the same crypto engine, maybe the supported
data unit sizes could differ due to other queue properties.) It
would also still be possible to switch to that design later without
breaking userspace, by replacing the directory with a symlink.
- Use "max_dun_bits" instead of "max_dun_bytes". Currently, the
kernel internally stores this value in bytes, but that's an
implementation detail. It probably makes more sense to talk about
this value in bits, and choosing bits is more future-proof.
- "modes" is a sub-subdirectory, since there may be multiple supported
crypto modes, sysfs is supposed to have one value per file, and it
makes sense to group all the mode files together.
- Each mode had to be named. The crypto API names like "xts(aes)" are
not appropriate because they don't specify the key size. Therefore,
I assigned new names. The exact names chosen are arbitrary, but
they happen to match the names used in log messages in fs/crypto/.
- The "num_keyslots" file is a bit different from the others in that
it is only useful to know for performance reasons. However, it's
included as it can still be useful. For example, a user might not
want to use inline encryption if there aren't very many keyslots.
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20220124215938.2769-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-01-24 14:59:38 -07:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
|
|
|
/*
|
|
|
|
* Copyright 2021 Google LLC
|
|
|
|
*
|
|
|
|
* sysfs support for blk-crypto. This file contains the code which exports the
|
|
|
|
* crypto capabilities of devices via /sys/block/$disk/queue/crypto/.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/blk-crypto-profile.h>
|
|
|
|
|
|
|
|
#include "blk-crypto-internal.h"
|
|
|
|
|
|
|
|
struct blk_crypto_kobj {
|
|
|
|
struct kobject kobj;
|
|
|
|
struct blk_crypto_profile *profile;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct blk_crypto_attr {
|
|
|
|
struct attribute attr;
|
|
|
|
ssize_t (*show)(struct blk_crypto_profile *profile,
|
|
|
|
struct blk_crypto_attr *attr, char *page);
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct blk_crypto_profile *kobj_to_crypto_profile(struct kobject *kobj)
|
|
|
|
{
|
|
|
|
return container_of(kobj, struct blk_crypto_kobj, kobj)->profile;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct blk_crypto_attr *attr_to_crypto_attr(struct attribute *attr)
|
|
|
|
{
|
|
|
|
return container_of(attr, struct blk_crypto_attr, attr);
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t max_dun_bits_show(struct blk_crypto_profile *profile,
|
|
|
|
struct blk_crypto_attr *attr, char *page)
|
|
|
|
{
|
|
|
|
return sysfs_emit(page, "%u\n", 8 * profile->max_dun_bytes_supported);
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t num_keyslots_show(struct blk_crypto_profile *profile,
|
|
|
|
struct blk_crypto_attr *attr, char *page)
|
|
|
|
{
|
|
|
|
return sysfs_emit(page, "%u\n", profile->num_slots);
|
|
|
|
}
|
|
|
|
|
|
|
|
#define BLK_CRYPTO_RO_ATTR(_name) \
|
|
|
|
static struct blk_crypto_attr _name##_attr = __ATTR_RO(_name)
|
|
|
|
|
|
|
|
BLK_CRYPTO_RO_ATTR(max_dun_bits);
|
|
|
|
BLK_CRYPTO_RO_ATTR(num_keyslots);
|
|
|
|
|
|
|
|
static struct attribute *blk_crypto_attrs[] = {
|
|
|
|
&max_dun_bits_attr.attr,
|
|
|
|
&num_keyslots_attr.attr,
|
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct attribute_group blk_crypto_attr_group = {
|
|
|
|
.attrs = blk_crypto_attrs,
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The encryption mode attributes. To avoid hard-coding the list of encryption
|
|
|
|
* modes, these are initialized at boot time by blk_crypto_sysfs_init().
|
|
|
|
*/
|
|
|
|
static struct blk_crypto_attr __blk_crypto_mode_attrs[BLK_ENCRYPTION_MODE_MAX];
|
|
|
|
static struct attribute *blk_crypto_mode_attrs[BLK_ENCRYPTION_MODE_MAX + 1];
|
|
|
|
|
|
|
|
static umode_t blk_crypto_mode_is_visible(struct kobject *kobj,
|
|
|
|
struct attribute *attr, int n)
|
|
|
|
{
|
|
|
|
struct blk_crypto_profile *profile = kobj_to_crypto_profile(kobj);
|
|
|
|
struct blk_crypto_attr *a = attr_to_crypto_attr(attr);
|
|
|
|
int mode_num = a - __blk_crypto_mode_attrs;
|
|
|
|
|
|
|
|
if (profile->modes_supported[mode_num])
|
|
|
|
return 0444;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t blk_crypto_mode_show(struct blk_crypto_profile *profile,
|
|
|
|
struct blk_crypto_attr *attr, char *page)
|
|
|
|
{
|
|
|
|
int mode_num = attr - __blk_crypto_mode_attrs;
|
|
|
|
|
|
|
|
return sysfs_emit(page, "0x%x\n", profile->modes_supported[mode_num]);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct attribute_group blk_crypto_modes_attr_group = {
|
|
|
|
.name = "modes",
|
|
|
|
.attrs = blk_crypto_mode_attrs,
|
|
|
|
.is_visible = blk_crypto_mode_is_visible,
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct attribute_group *blk_crypto_attr_groups[] = {
|
|
|
|
&blk_crypto_attr_group,
|
|
|
|
&blk_crypto_modes_attr_group,
|
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
|
|
|
static ssize_t blk_crypto_attr_show(struct kobject *kobj,
|
|
|
|
struct attribute *attr, char *page)
|
|
|
|
{
|
|
|
|
struct blk_crypto_profile *profile = kobj_to_crypto_profile(kobj);
|
|
|
|
struct blk_crypto_attr *a = attr_to_crypto_attr(attr);
|
|
|
|
|
|
|
|
return a->show(profile, a, page);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct sysfs_ops blk_crypto_attr_ops = {
|
|
|
|
.show = blk_crypto_attr_show,
|
|
|
|
};
|
|
|
|
|
|
|
|
static void blk_crypto_release(struct kobject *kobj)
|
|
|
|
{
|
|
|
|
kfree(container_of(kobj, struct blk_crypto_kobj, kobj));
|
|
|
|
}
|
|
|
|
|
2023-02-07 21:01:22 -07:00
|
|
|
static const struct kobj_type blk_crypto_ktype = {
|
blk-crypto: show crypto capabilities in sysfs
Add sysfs files that expose the inline encryption capabilities of
request queues:
/sys/block/$disk/queue/crypto/max_dun_bits
/sys/block/$disk/queue/crypto/modes/$mode
/sys/block/$disk/queue/crypto/num_keyslots
Userspace can use these new files to decide what encryption settings to
use, or whether to use inline encryption at all. This also brings the
crypto capabilities in line with the other queue properties, which are
already discoverable via the queue directory in sysfs.
Design notes:
- Place the new files in a new subdirectory "crypto" to group them
together and to avoid complicating the main "queue" directory. This
also makes it possible to replace "crypto" with a symlink later if
we ever make the blk_crypto_profiles into real kobjects (see below).
- It was necessary to define a new kobject that corresponds to the
crypto subdirectory. For now, this kobject just contains a pointer
to the blk_crypto_profile. Note that multiple queues (and hence
multiple such kobjects) may refer to the same blk_crypto_profile.
An alternative design would more closely match the current kernel
data structures: the blk_crypto_profile could be a kobject itself,
located directly under the host controller device's kobject, while
/sys/block/$disk/queue/crypto would be a symlink to it.
I decided not to do that for now because it would require a lot more
changes, such as no longer embedding blk_crypto_profile in other
structures, and also because I'm not sure we can rule out moving the
crypto capabilities into 'struct queue_limits' in the future. (Even
if multiple queues share the same crypto engine, maybe the supported
data unit sizes could differ due to other queue properties.) It
would also still be possible to switch to that design later without
breaking userspace, by replacing the directory with a symlink.
- Use "max_dun_bits" instead of "max_dun_bytes". Currently, the
kernel internally stores this value in bytes, but that's an
implementation detail. It probably makes more sense to talk about
this value in bits, and choosing bits is more future-proof.
- "modes" is a sub-subdirectory, since there may be multiple supported
crypto modes, sysfs is supposed to have one value per file, and it
makes sense to group all the mode files together.
- Each mode had to be named. The crypto API names like "xts(aes)" are
not appropriate because they don't specify the key size. Therefore,
I assigned new names. The exact names chosen are arbitrary, but
they happen to match the names used in log messages in fs/crypto/.
- The "num_keyslots" file is a bit different from the others in that
it is only useful to know for performance reasons. However, it's
included as it can still be useful. For example, a user might not
want to use inline encryption if there aren't very many keyslots.
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20220124215938.2769-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-01-24 14:59:38 -07:00
|
|
|
.default_groups = blk_crypto_attr_groups,
|
|
|
|
.sysfs_ops = &blk_crypto_attr_ops,
|
|
|
|
.release = blk_crypto_release,
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the request_queue has a blk_crypto_profile, create the "crypto"
|
|
|
|
* subdirectory in sysfs (/sys/block/$disk/queue/crypto/).
|
|
|
|
*/
|
2022-11-13 21:26:33 -07:00
|
|
|
int blk_crypto_sysfs_register(struct gendisk *disk)
|
blk-crypto: show crypto capabilities in sysfs
Add sysfs files that expose the inline encryption capabilities of
request queues:
/sys/block/$disk/queue/crypto/max_dun_bits
/sys/block/$disk/queue/crypto/modes/$mode
/sys/block/$disk/queue/crypto/num_keyslots
Userspace can use these new files to decide what encryption settings to
use, or whether to use inline encryption at all. This also brings the
crypto capabilities in line with the other queue properties, which are
already discoverable via the queue directory in sysfs.
Design notes:
- Place the new files in a new subdirectory "crypto" to group them
together and to avoid complicating the main "queue" directory. This
also makes it possible to replace "crypto" with a symlink later if
we ever make the blk_crypto_profiles into real kobjects (see below).
- It was necessary to define a new kobject that corresponds to the
crypto subdirectory. For now, this kobject just contains a pointer
to the blk_crypto_profile. Note that multiple queues (and hence
multiple such kobjects) may refer to the same blk_crypto_profile.
An alternative design would more closely match the current kernel
data structures: the blk_crypto_profile could be a kobject itself,
located directly under the host controller device's kobject, while
/sys/block/$disk/queue/crypto would be a symlink to it.
I decided not to do that for now because it would require a lot more
changes, such as no longer embedding blk_crypto_profile in other
structures, and also because I'm not sure we can rule out moving the
crypto capabilities into 'struct queue_limits' in the future. (Even
if multiple queues share the same crypto engine, maybe the supported
data unit sizes could differ due to other queue properties.) It
would also still be possible to switch to that design later without
breaking userspace, by replacing the directory with a symlink.
- Use "max_dun_bits" instead of "max_dun_bytes". Currently, the
kernel internally stores this value in bytes, but that's an
implementation detail. It probably makes more sense to talk about
this value in bits, and choosing bits is more future-proof.
- "modes" is a sub-subdirectory, since there may be multiple supported
crypto modes, sysfs is supposed to have one value per file, and it
makes sense to group all the mode files together.
- Each mode had to be named. The crypto API names like "xts(aes)" are
not appropriate because they don't specify the key size. Therefore,
I assigned new names. The exact names chosen are arbitrary, but
they happen to match the names used in log messages in fs/crypto/.
- The "num_keyslots" file is a bit different from the others in that
it is only useful to know for performance reasons. However, it's
included as it can still be useful. For example, a user might not
want to use inline encryption if there aren't very many keyslots.
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20220124215938.2769-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-01-24 14:59:38 -07:00
|
|
|
{
|
2022-11-13 21:26:33 -07:00
|
|
|
struct request_queue *q = disk->queue;
|
blk-crypto: show crypto capabilities in sysfs
Add sysfs files that expose the inline encryption capabilities of
request queues:
/sys/block/$disk/queue/crypto/max_dun_bits
/sys/block/$disk/queue/crypto/modes/$mode
/sys/block/$disk/queue/crypto/num_keyslots
Userspace can use these new files to decide what encryption settings to
use, or whether to use inline encryption at all. This also brings the
crypto capabilities in line with the other queue properties, which are
already discoverable via the queue directory in sysfs.
Design notes:
- Place the new files in a new subdirectory "crypto" to group them
together and to avoid complicating the main "queue" directory. This
also makes it possible to replace "crypto" with a symlink later if
we ever make the blk_crypto_profiles into real kobjects (see below).
- It was necessary to define a new kobject that corresponds to the
crypto subdirectory. For now, this kobject just contains a pointer
to the blk_crypto_profile. Note that multiple queues (and hence
multiple such kobjects) may refer to the same blk_crypto_profile.
An alternative design would more closely match the current kernel
data structures: the blk_crypto_profile could be a kobject itself,
located directly under the host controller device's kobject, while
/sys/block/$disk/queue/crypto would be a symlink to it.
I decided not to do that for now because it would require a lot more
changes, such as no longer embedding blk_crypto_profile in other
structures, and also because I'm not sure we can rule out moving the
crypto capabilities into 'struct queue_limits' in the future. (Even
if multiple queues share the same crypto engine, maybe the supported
data unit sizes could differ due to other queue properties.) It
would also still be possible to switch to that design later without
breaking userspace, by replacing the directory with a symlink.
- Use "max_dun_bits" instead of "max_dun_bytes". Currently, the
kernel internally stores this value in bytes, but that's an
implementation detail. It probably makes more sense to talk about
this value in bits, and choosing bits is more future-proof.
- "modes" is a sub-subdirectory, since there may be multiple supported
crypto modes, sysfs is supposed to have one value per file, and it
makes sense to group all the mode files together.
- Each mode had to be named. The crypto API names like "xts(aes)" are
not appropriate because they don't specify the key size. Therefore,
I assigned new names. The exact names chosen are arbitrary, but
they happen to match the names used in log messages in fs/crypto/.
- The "num_keyslots" file is a bit different from the others in that
it is only useful to know for performance reasons. However, it's
included as it can still be useful. For example, a user might not
want to use inline encryption if there aren't very many keyslots.
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20220124215938.2769-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-01-24 14:59:38 -07:00
|
|
|
struct blk_crypto_kobj *obj;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
if (!q->crypto_profile)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
obj = kzalloc(sizeof(*obj), GFP_KERNEL);
|
|
|
|
if (!obj)
|
|
|
|
return -ENOMEM;
|
|
|
|
obj->profile = q->crypto_profile;
|
|
|
|
|
2022-11-13 21:26:36 -07:00
|
|
|
err = kobject_init_and_add(&obj->kobj, &blk_crypto_ktype,
|
|
|
|
&disk->queue_kobj, "crypto");
|
blk-crypto: show crypto capabilities in sysfs
Add sysfs files that expose the inline encryption capabilities of
request queues:
/sys/block/$disk/queue/crypto/max_dun_bits
/sys/block/$disk/queue/crypto/modes/$mode
/sys/block/$disk/queue/crypto/num_keyslots
Userspace can use these new files to decide what encryption settings to
use, or whether to use inline encryption at all. This also brings the
crypto capabilities in line with the other queue properties, which are
already discoverable via the queue directory in sysfs.
Design notes:
- Place the new files in a new subdirectory "crypto" to group them
together and to avoid complicating the main "queue" directory. This
also makes it possible to replace "crypto" with a symlink later if
we ever make the blk_crypto_profiles into real kobjects (see below).
- It was necessary to define a new kobject that corresponds to the
crypto subdirectory. For now, this kobject just contains a pointer
to the blk_crypto_profile. Note that multiple queues (and hence
multiple such kobjects) may refer to the same blk_crypto_profile.
An alternative design would more closely match the current kernel
data structures: the blk_crypto_profile could be a kobject itself,
located directly under the host controller device's kobject, while
/sys/block/$disk/queue/crypto would be a symlink to it.
I decided not to do that for now because it would require a lot more
changes, such as no longer embedding blk_crypto_profile in other
structures, and also because I'm not sure we can rule out moving the
crypto capabilities into 'struct queue_limits' in the future. (Even
if multiple queues share the same crypto engine, maybe the supported
data unit sizes could differ due to other queue properties.) It
would also still be possible to switch to that design later without
breaking userspace, by replacing the directory with a symlink.
- Use "max_dun_bits" instead of "max_dun_bytes". Currently, the
kernel internally stores this value in bytes, but that's an
implementation detail. It probably makes more sense to talk about
this value in bits, and choosing bits is more future-proof.
- "modes" is a sub-subdirectory, since there may be multiple supported
crypto modes, sysfs is supposed to have one value per file, and it
makes sense to group all the mode files together.
- Each mode had to be named. The crypto API names like "xts(aes)" are
not appropriate because they don't specify the key size. Therefore,
I assigned new names. The exact names chosen are arbitrary, but
they happen to match the names used in log messages in fs/crypto/.
- The "num_keyslots" file is a bit different from the others in that
it is only useful to know for performance reasons. However, it's
included as it can still be useful. For example, a user might not
want to use inline encryption if there aren't very many keyslots.
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20220124215938.2769-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-01-24 14:59:38 -07:00
|
|
|
if (err) {
|
|
|
|
kobject_put(&obj->kobj);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
q->crypto_kobject = &obj->kobj;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2022-11-13 21:26:33 -07:00
|
|
|
void blk_crypto_sysfs_unregister(struct gendisk *disk)
|
blk-crypto: show crypto capabilities in sysfs
Add sysfs files that expose the inline encryption capabilities of
request queues:
/sys/block/$disk/queue/crypto/max_dun_bits
/sys/block/$disk/queue/crypto/modes/$mode
/sys/block/$disk/queue/crypto/num_keyslots
Userspace can use these new files to decide what encryption settings to
use, or whether to use inline encryption at all. This also brings the
crypto capabilities in line with the other queue properties, which are
already discoverable via the queue directory in sysfs.
Design notes:
- Place the new files in a new subdirectory "crypto" to group them
together and to avoid complicating the main "queue" directory. This
also makes it possible to replace "crypto" with a symlink later if
we ever make the blk_crypto_profiles into real kobjects (see below).
- It was necessary to define a new kobject that corresponds to the
crypto subdirectory. For now, this kobject just contains a pointer
to the blk_crypto_profile. Note that multiple queues (and hence
multiple such kobjects) may refer to the same blk_crypto_profile.
An alternative design would more closely match the current kernel
data structures: the blk_crypto_profile could be a kobject itself,
located directly under the host controller device's kobject, while
/sys/block/$disk/queue/crypto would be a symlink to it.
I decided not to do that for now because it would require a lot more
changes, such as no longer embedding blk_crypto_profile in other
structures, and also because I'm not sure we can rule out moving the
crypto capabilities into 'struct queue_limits' in the future. (Even
if multiple queues share the same crypto engine, maybe the supported
data unit sizes could differ due to other queue properties.) It
would also still be possible to switch to that design later without
breaking userspace, by replacing the directory with a symlink.
- Use "max_dun_bits" instead of "max_dun_bytes". Currently, the
kernel internally stores this value in bytes, but that's an
implementation detail. It probably makes more sense to talk about
this value in bits, and choosing bits is more future-proof.
- "modes" is a sub-subdirectory, since there may be multiple supported
crypto modes, sysfs is supposed to have one value per file, and it
makes sense to group all the mode files together.
- Each mode had to be named. The crypto API names like "xts(aes)" are
not appropriate because they don't specify the key size. Therefore,
I assigned new names. The exact names chosen are arbitrary, but
they happen to match the names used in log messages in fs/crypto/.
- The "num_keyslots" file is a bit different from the others in that
it is only useful to know for performance reasons. However, it's
included as it can still be useful. For example, a user might not
want to use inline encryption if there aren't very many keyslots.
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20220124215938.2769-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-01-24 14:59:38 -07:00
|
|
|
{
|
2022-11-13 21:26:33 -07:00
|
|
|
kobject_put(disk->queue->crypto_kobject);
|
blk-crypto: show crypto capabilities in sysfs
Add sysfs files that expose the inline encryption capabilities of
request queues:
/sys/block/$disk/queue/crypto/max_dun_bits
/sys/block/$disk/queue/crypto/modes/$mode
/sys/block/$disk/queue/crypto/num_keyslots
Userspace can use these new files to decide what encryption settings to
use, or whether to use inline encryption at all. This also brings the
crypto capabilities in line with the other queue properties, which are
already discoverable via the queue directory in sysfs.
Design notes:
- Place the new files in a new subdirectory "crypto" to group them
together and to avoid complicating the main "queue" directory. This
also makes it possible to replace "crypto" with a symlink later if
we ever make the blk_crypto_profiles into real kobjects (see below).
- It was necessary to define a new kobject that corresponds to the
crypto subdirectory. For now, this kobject just contains a pointer
to the blk_crypto_profile. Note that multiple queues (and hence
multiple such kobjects) may refer to the same blk_crypto_profile.
An alternative design would more closely match the current kernel
data structures: the blk_crypto_profile could be a kobject itself,
located directly under the host controller device's kobject, while
/sys/block/$disk/queue/crypto would be a symlink to it.
I decided not to do that for now because it would require a lot more
changes, such as no longer embedding blk_crypto_profile in other
structures, and also because I'm not sure we can rule out moving the
crypto capabilities into 'struct queue_limits' in the future. (Even
if multiple queues share the same crypto engine, maybe the supported
data unit sizes could differ due to other queue properties.) It
would also still be possible to switch to that design later without
breaking userspace, by replacing the directory with a symlink.
- Use "max_dun_bits" instead of "max_dun_bytes". Currently, the
kernel internally stores this value in bytes, but that's an
implementation detail. It probably makes more sense to talk about
this value in bits, and choosing bits is more future-proof.
- "modes" is a sub-subdirectory, since there may be multiple supported
crypto modes, sysfs is supposed to have one value per file, and it
makes sense to group all the mode files together.
- Each mode had to be named. The crypto API names like "xts(aes)" are
not appropriate because they don't specify the key size. Therefore,
I assigned new names. The exact names chosen are arbitrary, but
they happen to match the names used in log messages in fs/crypto/.
- The "num_keyslots" file is a bit different from the others in that
it is only useful to know for performance reasons. However, it's
included as it can still be useful. For example, a user might not
want to use inline encryption if there aren't very many keyslots.
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20220124215938.2769-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-01-24 14:59:38 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static int __init blk_crypto_sysfs_init(void)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
BUILD_BUG_ON(BLK_ENCRYPTION_MODE_INVALID != 0);
|
|
|
|
for (i = 1; i < BLK_ENCRYPTION_MODE_MAX; i++) {
|
|
|
|
struct blk_crypto_attr *attr = &__blk_crypto_mode_attrs[i];
|
|
|
|
|
|
|
|
attr->attr.name = blk_crypto_modes[i].name;
|
|
|
|
attr->attr.mode = 0444;
|
|
|
|
attr->show = blk_crypto_mode_show;
|
|
|
|
blk_crypto_mode_attrs[i - 1] = &attr->attr;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
subsys_initcall(blk_crypto_sysfs_init);
|