All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@redhat.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Satya Tangirala <satyat@google.com>, Jens Axboe <axboe@kernel.dk>,
	linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
	dm-devel@redhat.com, Alasdair Kergon <agk@redhat.com>
Subject: Re: [PATCH 2/3] dm: add support for passing through inline crypto support
Date: Wed, 23 Sep 2020 21:14:39 -0400	[thread overview]
Message-ID: <20200924011438.GD10500@redhat.com> (raw)
In-Reply-To: <20200922003255.GC32959@sol.localdomain>

On Mon, Sep 21 2020 at  8:32pm -0400,
Eric Biggers <ebiggers@kernel.org> wrote:

> On Wed, Sep 09, 2020 at 11:44:21PM +0000, Satya Tangirala wrote:
> > From: Eric Biggers <ebiggers@google.com>
> > 
> > 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.)
> > 
> > When a key is evicted from the dm device, it is evicted from all
> > underlying devices.
> > 
> > Signed-off-by: Eric Biggers <ebiggers@google.com>
> > Co-developed-by: Satya Tangirala <satyat@google.com>
> > Signed-off-by: Satya Tangirala <satyat@google.com>
> 
> Looks good as far as Satya's changes from my original patch are concerned.
> 
> Can the device-mapper maintainers take a look at this?

In general it looks like these changes were implemented very carefully
and are reasonable if we _really_ want to enable passing through inline
crypto.

I do have concerns about the inability to handle changes at runtime (due
to a table reload that introduces new devices without the encryption
settings the existing devices in the table are using).  But the fallback
mechanism saves it from being a complete non-starter.

Can you help me better understand the expected consumer of this code?
If you have something _real_ please be explicit.  It makes justifying
supporting niche code like this more tolerable.

Thanks,
Mike


  reply	other threads:[~2020-09-24  1:14 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-09 23:44 [PATCH 0/3] add support for inline encryption to device mapper Satya Tangirala
2020-09-09 23:44 ` [PATCH 1/3] block: keyslot-manager: Introduce passthrough keyslot manager Satya Tangirala
2020-09-22  0:27   ` Eric Biggers
2020-09-09 23:44 ` [PATCH 2/3] dm: add support for passing through inline crypto support Satya Tangirala
2020-09-22  0:32   ` Eric Biggers
2020-09-24  1:14     ` Mike Snitzer [this message]
2020-09-24  7:17       ` Satya Tangirala
2020-09-24 13:46         ` Mike Snitzer
2020-09-24 15:45           ` Eric Biggers
2020-09-24 16:16             ` Mike Snitzer
2020-09-24 16:57               ` Eric Biggers
2020-09-24  1:21   ` Mike Snitzer
2020-09-24  1:21     ` Mike Snitzer
2020-09-24  7:38     ` Satya Tangirala
2020-09-24 14:23       ` Mike Snitzer
2020-10-15 22:05         ` Satya Tangirala
2020-10-15 22:05           ` [dm-devel] " Satya Tangirala
2020-09-24  7:48     ` Satya Tangirala
2020-09-24 13:40       ` Mike Snitzer
2020-10-15 21:55         ` Satya Tangirala
2020-10-15 21:55           ` [dm-devel] " Satya Tangirala
2020-09-09 23:44 ` [PATCH 3/3] dm: enable may_passthrough_inline_crypto on some targets Satya Tangirala
2020-09-22  0:49   ` Eric Biggers

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=20200924011438.GD10500@redhat.com \
    --to=snitzer@redhat.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=satyat@google.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.