mbox series

[0/1,RFC] block: Add ioctl for setting default inline crypto key

Message ID 1658316391-13472-1-git-send-email-israelr@nvidia.com (mailing list archive)
Headers show
Series block: Add ioctl for setting default inline crypto key | expand

Message

Israel Rukshin July 20, 2022, 11:26 a.m. UTC 
Hi Jens/Christoph/Eric

I am working to add support for inline encryption/decryption
at storage protocols like nvmf over RDMA. Right now, the only
way to use the inline crypto feature is via fs-crypt. This patch
allows to use this feature also directly on a block device.
This patch comes after my former dm-crypt patch for inline encryption
was rejected ("[PATCH 1/1] dm crypt: Add inline encryption support")
by the maintainers. This alternative solution of a new block ioctl
was suggested by Christoph Hellwig and Eric Biggers.

I tested this patch with modified nvme-rdma as the block device.
I would like to collect some comments on this approach and I'll send the
entire patch set including NVMe/RDMA changes for inline encryption/decryption.

Israel Rukshin (1):
  block: Add support for setting inline encryption key per block device

 block/blk-core.c                |   4 +
 block/blk-crypto-internal.h     |  19 +++-
 block/blk-crypto-profile.c      |   1 +
 block/blk-crypto.c              | 156 ++++++++++++++++++++++++++++++++
 block/blk-sysfs.c               |   7 ++
 block/ioctl.c                   |   3 +
 include/linux/blk-crypto.h      |  11 +--
 include/linux/blkdev.h          |   2 +
 include/uapi/linux/blk-crypto.h |  14 +++
 include/uapi/linux/fs.h         |   9 ++
 10 files changed, 217 insertions(+), 9 deletions(-)
 create mode 100644 include/uapi/linux/blk-crypto.h

Comments

Christoph Hellwig July 21, 2022, 12:44 p.m. UTC | #1 
On Wed, Jul 20, 2022 at 02:26:30PM +0300, Israel Rukshin wrote:
> Hi Jens/Christoph/Eric
> 
> I am working to add support for inline encryption/decryption
> at storage protocols like nvmf over RDMA.

What would that be? nvmf over RDMA suggest on-the-wire transport
encryption, which really is a different think that what fscrypt
and blk-crypto deal with.  NVMe has a Key per I/O TP, which is
still waiting for the messy TCG counter part, but as far as I
can tell it is in many ways designed to more or less intentionally
not fit the fscrypt model.