All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Milan Broz <gmazyland@gmail.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>,
	device-mapper development <dm-devel@redhat.com>,
	linux-fscrypt@vger.kernel.org,
	Gilad Ben-Yossef <gilad@benyossef.com>
Subject: Re: [PATCH v12 0/4] crypto: switch to crypto API for ESSIV generation
Date: Fri, 16 Aug 2019 11:18:42 +0300	[thread overview]
Message-ID: <CAKv+Gu9CtMMAjtjfR=uuB-+x0Lhy8gnme2HhExckW+eVZ8B_Ow@mail.gmail.com> (raw)
In-Reply-To: <1463bca3-77dc-42be-7624-e8eaf5cfbf32@gmail.com>

On Fri, 16 Aug 2019 at 10:29, Milan Broz <gmazyland@gmail.com> wrote:
>
> Hi Ard,
>
> On 15/08/2019 21:28, Ard Biesheuvel wrote:
> > Changes since v10:
> > - Drop patches against fscrypt and dm-crypt - these will be routed via the
> >   respective maintainer trees during the next cycle
>
> I tested the previous dm-crypt patches (I also try to keep them in my kernel.org tree),
> it works and looks fine to me (and I like the final cleanup :)
>
> Once all maintainers are happy with the current state, I think it should go to
> the next release (5.4; IMO both ESSIV API and dm-crypt changes).
> Maybe you could keep sending dm-crypt patches in the end of the series (to help testing it)?
>

OK. But we'll need to coordinate a bit so that the first patch (the
one that introduces the template) is available in both branches,
otherwise ESSIV will be broken in the dm branch until it hits another
branch (-next or mainline) that also contains cryptodev.

As I suggested before, I can easily create a branch based on v5.3-rc1
containing just the first ESSIV patch (once Herbert is happy with it),
and merge that both into cryptodev and dm. That way, both will
continue to work without having too much overlap. Since adding a
template/file that has no users yet is highly unlikely to break
anything, it doesn't even matter which branch gets pulled first.

Any idea about the status of the EBOIV patch?

WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Milan Broz <gmazyland@gmail.com>
Cc: 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>,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>
Subject: Re: [PATCH v12 0/4] crypto: switch to crypto API for ESSIV generation
Date: Fri, 16 Aug 2019 11:18:42 +0300	[thread overview]
Message-ID: <CAKv+Gu9CtMMAjtjfR=uuB-+x0Lhy8gnme2HhExckW+eVZ8B_Ow@mail.gmail.com> (raw)
In-Reply-To: <1463bca3-77dc-42be-7624-e8eaf5cfbf32@gmail.com>

On Fri, 16 Aug 2019 at 10:29, Milan Broz <gmazyland@gmail.com> wrote:
>
> Hi Ard,
>
> On 15/08/2019 21:28, Ard Biesheuvel wrote:
> > Changes since v10:
> > - Drop patches against fscrypt and dm-crypt - these will be routed via the
> >   respective maintainer trees during the next cycle
>
> I tested the previous dm-crypt patches (I also try to keep them in my kernel.org tree),
> it works and looks fine to me (and I like the final cleanup :)
>
> Once all maintainers are happy with the current state, I think it should go to
> the next release (5.4; IMO both ESSIV API and dm-crypt changes).
> Maybe you could keep sending dm-crypt patches in the end of the series (to help testing it)?
>

OK. But we'll need to coordinate a bit so that the first patch (the
one that introduces the template) is available in both branches,
otherwise ESSIV will be broken in the dm branch until it hits another
branch (-next or mainline) that also contains cryptodev.

As I suggested before, I can easily create a branch based on v5.3-rc1
containing just the first ESSIV patch (once Herbert is happy with it),
and merge that both into cryptodev and dm. That way, both will
continue to work without having too much overlap. Since adding a
template/file that has no users yet is highly unlikely to break
anything, it doesn't even matter which branch gets pulled first.

Any idea about the status of the EBOIV patch?

  reply	other threads:[~2019-08-16  8:18 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-15 19:28 [PATCH v12 0/4] crypto: switch to crypto API for ESSIV generation Ard Biesheuvel
2019-08-15 19:28 ` Ard Biesheuvel
2019-08-15 19:28 ` [dm-devel] " Ard Biesheuvel
2019-08-15 19:28 ` [PATCH v12 1/4] crypto: essiv - create wrapper template " Ard Biesheuvel
2019-08-15 19:28   ` Ard Biesheuvel
2019-08-15 19:28   ` [dm-devel] " Ard Biesheuvel
2019-08-19  6:32   ` Herbert Xu
2019-08-19  6:32     ` Herbert Xu
2019-08-19 14:14     ` Ard Biesheuvel
2019-08-19 14:14       ` Ard Biesheuvel
2019-08-19 14:14       ` Ard Biesheuvel
2019-08-19 23:35       ` Herbert Xu
2019-08-19 23:35         ` Herbert Xu
2019-08-19 23:35         ` Herbert Xu
2019-08-15 19:28 ` [PATCH v12 2/4] crypto: essiv - add tests for essiv in cbc(aes)+sha256 mode Ard Biesheuvel
2019-08-15 19:28   ` Ard Biesheuvel
2019-08-15 19:28   ` [dm-devel] " Ard Biesheuvel
2019-08-15 19:28 ` [PATCH v12 3/4] crypto: arm64/aes-cts-cbc - factor out CBC en/decryption of a walk Ard Biesheuvel
2019-08-15 19:28   ` Ard Biesheuvel
2019-08-15 19:28   ` [dm-devel] " Ard Biesheuvel
2019-08-15 19:28 ` [PATCH v12 4/4] crypto: arm64/aes - implement accelerated ESSIV/CBC mode Ard Biesheuvel
2019-08-15 19:28   ` Ard Biesheuvel
2019-08-15 19:28   ` [dm-devel] " Ard Biesheuvel
2019-08-16  7:29 ` [PATCH v12 0/4] crypto: switch to crypto API for ESSIV generation Milan Broz
2019-08-16  7:29   ` Milan Broz
2019-08-16  8:18   ` Ard Biesheuvel [this message]
2019-08-16  8:18     ` Ard Biesheuvel
2019-08-16  8:18     ` Ard Biesheuvel
2019-08-16  8:26     ` Milan Broz
2019-08-16  8:26       ` Milan Broz
2019-08-16  8:26       ` Milan Broz

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+Gu9CtMMAjtjfR=uuB-+x0Lhy8gnme2HhExckW+eVZ8B_Ow@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 \
    /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.