From: Eric Biggers <ebiggers@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Israel Rukshin <israelr@nvidia.com>,
Max Gurtovoy <mgurtovoy@nvidia.com>,
dm-devel <dm-devel@redhat.com>, Nitzan Carmi <nitzanc@nvidia.com>,
Milan Broz <gmazyland@gmail.com>
Subject: Re: [dm-devel] [RFC PATCH 0/1] Add inline encryption support for dm-crypt
Date: Tue, 18 Jan 2022 12:27:33 -0800 [thread overview]
Message-ID: <Yecitbf4lJtQA69O@sol.localdomain> (raw)
In-Reply-To: <YebupSYksz2gV8vn@infradead.org>
On Tue, Jan 18, 2022 at 08:45:25AM -0800, Christoph Hellwig wrote:
> On Mon, Jan 17, 2022 at 04:00:59PM +0200, Israel Rukshin wrote:
> > DM extension gives us several capabilities:
> >
> > 1. Use the Linux keyring and other key management tools.
> >
> > - I used "keyctl padd user test-key @u < /tmp/wrapped_dek" at my tests
>
> Well, and kernel consumer can do that.
>
> > 2. Split a single block device into several DMs. Allow us to use a different
> > encryption key and encryption mode per DM.
>
> If we allow setting a default key for every block device you can still
> do that using normal dm-linear.
>
> >
> > 3. Replace a key during I/O by using "dmsetup suspend /dev/dm-0" and
> > "dmsetup resume /dev/dm-0".
>
> With a block layer ioctl that also works easily.
>
A while ago, I had looked into adding an ioctl to set a default key for a block
device. There were a few things that led me to choose a dm target instead. I'm
not sure how many of these are still relevant, but these are what I considered:
* The block device for a partition doesn't have its own request_queue or
queue_limits; those are properties of the disk, not the partition. But,
setting an encryption key may require changes to the queue_limits. For
example, discard_zeroes_data will no longer work, and the logical_block_size
will need to become the crypto data unit size which may be larger than the
original logical_block_size.
* The block_device for a given partition didn't stay around while no one has it
opened or mounted. This may have been addressed by Christoph's changes last
year that merged block_device and hd_struct, but this used to be an issue.
* There was some issue caused by the way the block layer maps partitions to
disks; the knowledge of the original block device (and thus the key) was lost
at this point. I'm not sure whether this is still an issue or not.
* A block device ioctl to set a key would need to handle cases where the block
device is already open (fail with EBUSY?), or already has pages cached in the
pagecache (invalidate them?). A dm target avoids these concerns since a key
would only be set up when the disk and block device are originally created.
Finally, there's also the fact that this would really be more than "setting a
default key". To precisely specify the encryption format, you also have to
specify the algorithm, the key type, and the data unit size. (Also potentially
more details about IV generation, if blk-crypto ever starts to support more IV
generation methods, which I'd like to avoid but it might eventually happen.)
These could all be passed in an ioctl, but dm-crypt already has a syntax defined
for specifying encryption formats. So it could make sense to reuse it.
Also as Israel indicated, people will want support for Linux keyring keys as an
alternative to raw keys. A new ioctl could support this, though dm-crypt
already has a defined way to specify such keys.
If all these issues can be solved, then I'd be fine with the block device ioctl.
- Eric
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2022-01-18 20:27 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-13 18:09 [dm-devel] [RFC PATCH 0/1] Add inline encryption support for dm-crypt Israel Rukshin
2022-01-13 18:09 ` [dm-devel] [PATCH 1/1] dm crypt: Add inline encryption support Israel Rukshin
2022-01-14 8:06 ` Damien Le Moal
2022-01-14 8:14 ` Damien Le Moal
2022-01-16 10:29 ` Israel Rukshin
2022-01-13 21:22 ` [dm-devel] [RFC PATCH 0/1] Add inline encryption support for dm-crypt Bart Van Assche
2022-01-14 20:51 ` Milan Broz
2022-01-14 22:27 ` Eric Biggers
2022-01-15 9:22 ` Milan Broz
2022-01-18 19:38 ` Eric Biggers
2022-01-19 5:18 ` Christoph Hellwig
2022-01-17 7:52 ` Christoph Hellwig
2022-01-17 10:50 ` Milan Broz
2022-01-17 14:00 ` Israel Rukshin
2022-01-18 16:45 ` Christoph Hellwig
2022-01-18 20:27 ` Eric Biggers [this message]
2022-01-19 5:15 ` Christoph Hellwig
2022-01-14 22:49 ` Eric Biggers
2022-01-16 10:15 ` Israel Rukshin
2022-01-18 20:02 ` Eric Biggers
2022-01-19 15:45 ` Israel Rukshin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yecitbf4lJtQA69O@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=dm-devel@redhat.com \
--cc=gmazyland@gmail.com \
--cc=hch@infradead.org \
--cc=israelr@nvidia.com \
--cc=mgurtovoy@nvidia.com \
--cc=nitzanc@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.