From: Satya Tangirala <satyat@google.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>, Mike Snitzer <snitzer@redhat.com>,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
dm-devel@redhat.com, Alasdair Kergon <agk@redhat.com>
Subject: Re: [dm-devel] [PATCH v4 3/5] dm: add support for passing through inline crypto support
Date: Thu, 11 Feb 2021 22:58:37 +0000 [thread overview]
Message-ID: <YCW2nWmHCunU1DwV@google.com> (raw)
In-Reply-To: <YCQ/WjAsVA2gdb7d@gmail.com>
On Wed, Feb 10, 2021 at 12:17:30PM -0800, Eric Biggers wrote:
> On Mon, Feb 01, 2021 at 05:10:17AM +0000, Satya Tangirala wrote:
> > Update the device-mapper core to support exposing the inline crypto
> > support of the underlying device(s) through the device-mapper device.
> >
> > This works by creating a "passthrough keyslot manager" for the dm
> > device, which declares support for encryption settings which all
> > underlying devices support. When a supported setting is used, the bio
> > cloning code handles cloning the crypto context to the bios for all the
> > underlying devices. When an unsupported setting is used, the blk-crypto
> > fallback is used as usual.
> >
> > Crypto support on each underlying device is ignored unless the
> > corresponding dm target opts into exposing it. This is needed because
> > for inline crypto to semantically operate on the original bio, the data
> > must not be transformed by the dm target. Thus, targets like dm-linear
> > can expose crypto support of the underlying device, but targets like
> > dm-crypt can't. (dm-crypt could use inline crypto itself, though.)
> >
> > A DM device's table can only be changed if the "new" inline encryption
> > capabilities are a (*not* necessarily strict) superset of the "old" inline
> > encryption capabilities. Attempts to make changes to the table that result
> > in some inline encryption capability becoming no longer supported will be
> > rejected.
> >
> > For the sake of clarity, key eviction from underlying devices will be
> > handled in a future patch.
> >
> > Co-developed-by: Eric Biggers <ebiggers@google.com>
> > Signed-off-by: Eric Biggers <ebiggers@google.com>
> > Signed-off-by: Satya Tangirala <satyat@google.com>
>
> I don't see any obvious issues with this latest version. I assume you've tested
> it on real hardware?
>
> If it's needed despite my Co-developed-by, feel free to add:
>
> Reviewed-by: Eric Biggers <ebiggers@google.com>
>
> A few nits about comments, in case you resend:
>
Thanks! I addressed the nits, added acked/reviewed-bys and resent v5.
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
WARNING: multiple messages have this Message-ID (diff)
From: Satya Tangirala <satyat@google.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
dm-devel@redhat.com, Jens Axboe <axboe@kernel.dk>,
Mike Snitzer <snitzer@redhat.com>,
Alasdair Kergon <agk@redhat.com>
Subject: Re: [PATCH v4 3/5] dm: add support for passing through inline crypto support
Date: Thu, 11 Feb 2021 22:58:37 +0000 [thread overview]
Message-ID: <YCW2nWmHCunU1DwV@google.com> (raw)
In-Reply-To: <YCQ/WjAsVA2gdb7d@gmail.com>
On Wed, Feb 10, 2021 at 12:17:30PM -0800, Eric Biggers wrote:
> On Mon, Feb 01, 2021 at 05:10:17AM +0000, Satya Tangirala wrote:
> > Update the device-mapper core to support exposing the inline crypto
> > support of the underlying device(s) through the device-mapper device.
> >
> > This works by creating a "passthrough keyslot manager" for the dm
> > device, which declares support for encryption settings which all
> > underlying devices support. When a supported setting is used, the bio
> > cloning code handles cloning the crypto context to the bios for all the
> > underlying devices. When an unsupported setting is used, the blk-crypto
> > fallback is used as usual.
> >
> > Crypto support on each underlying device is ignored unless the
> > corresponding dm target opts into exposing it. This is needed because
> > for inline crypto to semantically operate on the original bio, the data
> > must not be transformed by the dm target. Thus, targets like dm-linear
> > can expose crypto support of the underlying device, but targets like
> > dm-crypt can't. (dm-crypt could use inline crypto itself, though.)
> >
> > A DM device's table can only be changed if the "new" inline encryption
> > capabilities are a (*not* necessarily strict) superset of the "old" inline
> > encryption capabilities. Attempts to make changes to the table that result
> > in some inline encryption capability becoming no longer supported will be
> > rejected.
> >
> > For the sake of clarity, key eviction from underlying devices will be
> > handled in a future patch.
> >
> > Co-developed-by: Eric Biggers <ebiggers@google.com>
> > Signed-off-by: Eric Biggers <ebiggers@google.com>
> > Signed-off-by: Satya Tangirala <satyat@google.com>
>
> I don't see any obvious issues with this latest version. I assume you've tested
> it on real hardware?
>
> If it's needed despite my Co-developed-by, feel free to add:
>
> Reviewed-by: Eric Biggers <ebiggers@google.com>
>
> A few nits about comments, in case you resend:
>
Thanks! I addressed the nits, added acked/reviewed-bys and resent v5.
next prev parent reply other threads:[~2021-02-11 23:01 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-01 5:10 [dm-devel] [PATCH v4 0/5] add support for inline encryption to device mapper Satya Tangirala
2021-02-01 5:10 ` Satya Tangirala
2021-02-01 5:10 ` [dm-devel] [PATCH v4 1/5] block: keyslot-manager: Introduce passthrough keyslot manager Satya Tangirala
2021-02-01 5:10 ` Satya Tangirala
2021-02-01 5:10 ` [dm-devel] [PATCH v4 2/5] block: keyslot-manager: Introduce functions for device mapper support Satya Tangirala
2021-02-01 5:10 ` Satya Tangirala
2021-02-10 19:55 ` [dm-devel] " Eric Biggers
2021-02-10 19:55 ` Eric Biggers
2021-02-01 5:10 ` [dm-devel] [PATCH v4 3/5] dm: add support for passing through inline crypto support Satya Tangirala
2021-02-01 5:10 ` Satya Tangirala
2021-02-10 20:17 ` [dm-devel] " Eric Biggers
2021-02-10 20:17 ` Eric Biggers
2021-02-11 22:58 ` Satya Tangirala [this message]
2021-02-11 22:58 ` Satya Tangirala
2021-02-01 5:10 ` [dm-devel] [PATCH v4 4/5] dm: support key eviction from keyslot managers of underlying devices Satya Tangirala
2021-02-01 5:10 ` Satya Tangirala
2021-02-10 20:19 ` [dm-devel] " Eric Biggers
2021-02-10 20:19 ` Eric Biggers
2021-02-01 5:10 ` [dm-devel] [PATCH v4 5/5] dm: set DM_TARGET_PASSES_CRYPTO feature for some targets Satya Tangirala
2021-02-01 5:10 ` Satya Tangirala
2021-02-10 20:24 ` [dm-devel] " Eric Biggers
2021-02-10 20:24 ` Eric Biggers
2021-02-10 19:33 ` [dm-devel] [PATCH v4 0/5] add support for inline encryption to device mapper Mike Snitzer
2021-02-10 19:33 ` Mike Snitzer
2021-02-10 19:59 ` [dm-devel] " Jens Axboe
2021-02-10 19:59 ` Jens Axboe
2021-02-11 23:01 ` [dm-devel] " Satya Tangirala
2021-02-11 23:01 ` Satya Tangirala
2021-02-11 23:04 ` [dm-devel] " Mike Snitzer
2021-02-11 23:04 ` Mike Snitzer
2021-02-12 0:47 ` [dm-devel] " Satya Tangirala
2021-02-12 0:47 ` Satya Tangirala
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=YCW2nWmHCunU1DwV@google.com \
--to=satyat@google.com \
--cc=agk@redhat.com \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=ebiggers@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=snitzer@redhat.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.