All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Mike Snitzer <snitzer@redhat.com>
Cc: "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
	<linux-crypto@vger.kernel.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Eric Biggers <ebiggers@google.com>,
	linux-fscrypt@vger.kernel.org,
	Gilad Ben-Yossef <gilad@benyossef.com>,
	device-mapper development <dm-devel@redhat.com>,
	Milan Broz <gmazyland@gmail.com>
Subject: Re: [PATCH v13 5/6] md: dm-crypt: switch to ESSIV crypto API template
Date: Tue, 3 Sep 2019 12:16:37 -0700	[thread overview]
Message-ID: <CAKv+Gu8wr3HnP7uVDAOY=o54dWVkPoWm5V43LU_QNVMK_Cc2GA@mail.gmail.com> (raw)
In-Reply-To: <20190903185537.GC13472@redhat.com>

On Tue, 3 Sep 2019 at 11:55, Mike Snitzer <snitzer@redhat.com> wrote:
>
> On Mon, Aug 19 2019 at 10:17am -0400,
> Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
> > Replace the explicit ESSIV handling in the dm-crypt driver with calls
> > into the crypto API, which now possesses the capability to perform
> > this processing within the crypto subsystem.
> >
> > Note that we reorder the AEAD cipher_api string parsing with the TFM
> > instantiation: this is needed because cipher_api is mangled by the
> > ESSIV handling, and throws off the parsing of "authenc(" otherwise.
> >
> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> I really like to see this type of factoring out to the crypto API;
> nicely done.
>
> Acked-by: Mike Snitzer <snitzer@redhat.com>
>
> Herbert, please feel free to pull this, and the next 6/6 patch, into
> your crypto tree for 5.4.  I see no need to complicate matters by me
> having to rebase my dm-5.4 branch ontop of the crypto tree, etc.
>

Thanks Mike.

There is no need to rebase your branch - there is only a single
dependency, which is the essiv template itself, and the patch that
adds that (#1 in this series) was acked by Herbert, specifically so
that it can be taken via another tree. The crypto tree has no
interdependencies with this template, and the other patches in this
series are not required for essiv in dm-crypt.

If you feel it is too late in the cycle, we can defer to v5.5, but in
this case, we should align with Eric, which will depend on the essiv
template for fscrypt as well.

In any case, it is up to you, Eric and Herbert to align on this. For
me, it doesn't really matter whether this lands in v5.4 or v5.5. There
is some followup work based on this, but that is further out still.

Thanks,
Ard.

WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Mike Snitzer <snitzer@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	Eric Biggers <ebiggers@google.com>,
	device-mapper development <dm-devel@redhat.com>,
	Gilad Ben-Yossef <gilad@benyossef.com>,
	linux-fscrypt@vger.kernel.org,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>, Milan Broz <gmazyland@gmail.com>
Subject: Re: [PATCH v13 5/6] md: dm-crypt: switch to ESSIV crypto API template
Date: Tue, 3 Sep 2019 12:16:37 -0700	[thread overview]
Message-ID: <CAKv+Gu8wr3HnP7uVDAOY=o54dWVkPoWm5V43LU_QNVMK_Cc2GA@mail.gmail.com> (raw)
In-Reply-To: <20190903185537.GC13472@redhat.com>

On Tue, 3 Sep 2019 at 11:55, Mike Snitzer <snitzer@redhat.com> wrote:
>
> On Mon, Aug 19 2019 at 10:17am -0400,
> Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
> > Replace the explicit ESSIV handling in the dm-crypt driver with calls
> > into the crypto API, which now possesses the capability to perform
> > this processing within the crypto subsystem.
> >
> > Note that we reorder the AEAD cipher_api string parsing with the TFM
> > instantiation: this is needed because cipher_api is mangled by the
> > ESSIV handling, and throws off the parsing of "authenc(" otherwise.
> >
> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> I really like to see this type of factoring out to the crypto API;
> nicely done.
>
> Acked-by: Mike Snitzer <snitzer@redhat.com>
>
> Herbert, please feel free to pull this, and the next 6/6 patch, into
> your crypto tree for 5.4.  I see no need to complicate matters by me
> having to rebase my dm-5.4 branch ontop of the crypto tree, etc.
>

Thanks Mike.

There is no need to rebase your branch - there is only a single
dependency, which is the essiv template itself, and the patch that
adds that (#1 in this series) was acked by Herbert, specifically so
that it can be taken via another tree. The crypto tree has no
interdependencies with this template, and the other patches in this
series are not required for essiv in dm-crypt.

If you feel it is too late in the cycle, we can defer to v5.5, but in
this case, we should align with Eric, which will depend on the essiv
template for fscrypt as well.

In any case, it is up to you, Eric and Herbert to align on this. For
me, it doesn't really matter whether this lands in v5.4 or v5.5. There
is some followup work based on this, but that is further out still.

Thanks,
Ard.

  reply	other threads:[~2019-09-03 19:16 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-19 14:17 [PATCH v13 0/6] crypto: switch to crypto API for ESSIV generation Ard Biesheuvel
2019-08-19 14:17 ` Ard Biesheuvel
2019-08-19 14:17 ` [dm-devel] " Ard Biesheuvel
2019-08-19 14:17 ` [PATCH v13 1/6] crypto: essiv - create wrapper template " Ard Biesheuvel
2019-08-19 14:17   ` Ard Biesheuvel
2019-08-19 14:17   ` [dm-devel] " Ard Biesheuvel
2019-08-30  4:58   ` Herbert Xu
2019-08-30  4:58     ` Herbert Xu
2019-08-31 16:37     ` Ard Biesheuvel
2019-08-31 16:37       ` Ard Biesheuvel
2019-08-31 16:37       ` Ard Biesheuvel
2019-08-19 14:17 ` [PATCH v13 2/6] crypto: essiv - add tests for essiv in cbc(aes)+sha256 mode Ard Biesheuvel
2019-08-19 14:17   ` Ard Biesheuvel
2019-08-19 14:17 ` [PATCH v13 3/6] crypto: arm64/aes-cts-cbc - factor out CBC en/decryption of a walk Ard Biesheuvel
2019-08-19 14:17   ` Ard Biesheuvel
2019-08-19 14:17 ` [PATCH v13 4/6] crypto: arm64/aes - implement accelerated ESSIV/CBC mode Ard Biesheuvel
2019-08-19 14:17   ` Ard Biesheuvel
2019-08-19 14:17 ` [PATCH v13 5/6] md: dm-crypt: switch to ESSIV crypto API template Ard Biesheuvel
2019-08-19 14:17   ` Ard Biesheuvel
2019-09-03 18:55   ` Mike Snitzer
2019-09-03 18:55     ` Mike Snitzer
2019-09-03 18:55     ` [dm-devel] " Mike Snitzer
2019-09-03 19:16     ` Ard Biesheuvel [this message]
2019-09-03 19:16       ` Ard Biesheuvel
2019-09-03 19:16       ` Ard Biesheuvel
2019-09-03 20:51       ` Mike Snitzer
2019-09-03 20:51         ` Mike Snitzer
2019-09-03 20:51         ` Mike Snitzer
2019-08-19 14:17 ` [PATCH v13 6/6] md: dm-crypt: omit parsing of the encapsulated cipher Ard Biesheuvel
2019-08-19 14:17   ` Ard Biesheuvel
2019-09-03 18:58   ` Mike Snitzer
2019-09-03 18:58     ` Mike Snitzer
2019-09-04 11:01     ` Milan Broz
2019-09-04 11:01       ` Milan Broz
2019-09-04 11:01       ` [dm-devel] " Milan Broz
2019-09-04 13:38       ` Mike Snitzer
2019-09-04 13:38         ` Mike Snitzer
2019-08-20 11:03 ` [PATCH v13 0/6] crypto: switch to crypto API for ESSIV generation Ard Biesheuvel
2019-08-20 11:03   ` Ard Biesheuvel
2019-08-20 11:03   ` [dm-devel] " Ard Biesheuvel
2019-08-30  8:18 ` Herbert Xu
2019-08-30  8:18   ` Herbert Xu

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='CAKv+Gu8wr3HnP7uVDAOY=o54dWVkPoWm5V43LU_QNVMK_Cc2GA@mail.gmail.com' \
    --to=ard.biesheuvel@linaro.org \
    --cc=dm-devel@redhat.com \
    --cc=ebiggers@google.com \
    --cc=gilad@benyossef.com \
    --cc=gmazyland@gmail.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-fscrypt@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.