All of lore.kernel.org
 help / color / mirror / Atom feed
From: Milan Broz <gmazyland@gmail.com>
To: Mike Snitzer <snitzer@redhat.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: 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>,
	dm-devel@redhat.com
Subject: Re: [PATCH v13 6/6] md: dm-crypt: omit parsing of the encapsulated cipher
Date: Wed, 4 Sep 2019 13:01:29 +0200	[thread overview]
Message-ID: <403192f0-d1c4-0c60-5af1-7dee8516d629@gmail.com> (raw)
In-Reply-To: <20190903185827.GD13472@redhat.com>

On 03/09/2019 20:58, Mike Snitzer wrote:
> On Mon, Aug 19 2019 at 10:17am -0400,
> Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> 
>> Only the ESSIV IV generation mode used to use cc->cipher so it could
>> instantiate the bare cipher used to encrypt the IV. However, this is
>> now taken care of by the ESSIV template, and so no users of cc->cipher
>> remain. So remove it altogether.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> 
> Acked-by: Mike Snitzer <snitzer@redhat.com>
> 
> Might be wise to bump the dm-crypt target's version number (from
> {1, 19, 0} to {1, 20, 0}) at the end of this patch too though...

The function should be exactly the same, dependencies on needed modules are set.

In cryptsetup we always report dm target + kernel version,
so we know that since version 5.4 it uses crypto API for ESSIV.
I think version bump here is really not so important.

Just my two cents :)

Anyway, thanks everyone.

Milan

WARNING: multiple messages have this Message-ID (diff)
From: Milan Broz <gmazyland@gmail.com>
To: Mike Snitzer <snitzer@redhat.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	Eric Biggers <ebiggers@google.com>,
	dm-devel@redhat.com, Gilad Ben-Yossef <gilad@benyossef.com>,
	linux-fscrypt@vger.kernel.org, linux-crypto@vger.kernel.org
Subject: Re: [dm-devel] [PATCH v13 6/6] md: dm-crypt: omit parsing of the encapsulated cipher
Date: Wed, 4 Sep 2019 13:01:29 +0200	[thread overview]
Message-ID: <403192f0-d1c4-0c60-5af1-7dee8516d629@gmail.com> (raw)
In-Reply-To: <20190903185827.GD13472@redhat.com>

On 03/09/2019 20:58, Mike Snitzer wrote:
> On Mon, Aug 19 2019 at 10:17am -0400,
> Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> 
>> Only the ESSIV IV generation mode used to use cc->cipher so it could
>> instantiate the bare cipher used to encrypt the IV. However, this is
>> now taken care of by the ESSIV template, and so no users of cc->cipher
>> remain. So remove it altogether.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> 
> Acked-by: Mike Snitzer <snitzer@redhat.com>
> 
> Might be wise to bump the dm-crypt target's version number (from
> {1, 19, 0} to {1, 20, 0}) at the end of this patch too though...

The function should be exactly the same, dependencies on needed modules are set.

In cryptsetup we always report dm target + kernel version,
so we know that since version 5.4 it uses crypto API for ESSIV.
I think version bump here is really not so important.

Just my two cents :)

Anyway, thanks everyone.

Milan

--
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: Milan Broz <gmazyland@gmail.com>
To: Mike Snitzer <snitzer@redhat.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	Eric Biggers <ebiggers@google.com>,
	dm-devel@redhat.com, Gilad Ben-Yossef <gilad@benyossef.com>,
	linux-fscrypt@vger.kernel.org, linux-crypto@vger.kernel.org
Subject: Re: [PATCH v13 6/6] md: dm-crypt: omit parsing of the encapsulated cipher
Date: Wed, 4 Sep 2019 13:01:29 +0200	[thread overview]
Message-ID: <403192f0-d1c4-0c60-5af1-7dee8516d629@gmail.com> (raw)
In-Reply-To: <20190903185827.GD13472@redhat.com>

On 03/09/2019 20:58, Mike Snitzer wrote:
> On Mon, Aug 19 2019 at 10:17am -0400,
> Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> 
>> Only the ESSIV IV generation mode used to use cc->cipher so it could
>> instantiate the bare cipher used to encrypt the IV. However, this is
>> now taken care of by the ESSIV template, and so no users of cc->cipher
>> remain. So remove it altogether.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> 
> Acked-by: Mike Snitzer <snitzer@redhat.com>
> 
> Might be wise to bump the dm-crypt target's version number (from
> {1, 19, 0} to {1, 20, 0}) at the end of this patch too though...

The function should be exactly the same, dependencies on needed modules are set.

In cryptsetup we always report dm target + kernel version,
so we know that since version 5.4 it uses crypto API for ESSIV.
I think version bump here is really not so important.

Just my two cents :)

Anyway, thanks everyone.

Milan

  reply	other threads:[~2019-09-04 11:01 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
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 [this message]
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=403192f0-d1c4-0c60-5af1-7dee8516d629@gmail.com \
    --to=gmazyland@gmail.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=dm-devel@redhat.com \
    --cc=ebiggers@google.com \
    --cc=gilad@benyossef.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.