| Message ID | 20190819141738.1231-7-ard.biesheuvel@linaro.org |
|---|---|
| State | Accepted |
| Commit | b1d1e29639dff5290945e45262e172aaa9e89cbe |
| Headers | show |
| Series | crypto: switch to crypto API for ESSIV generation | expand |
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... But again, Herbert please feel free to pull this into your 5.4 branch. Thanks, Mike
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
On Wed, Sep 04 2019 at 7:01am -0400, Milan Broz <gmazyland@gmail.com> wrote: > 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 :) Yes, that's fine.. I staged it for 5.4 yesterday without the version bump. Thanks, Mike
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c index e3e6e111edfc..0dd1fb027ac0 100644 --- a/drivers/md/dm-crypt.c +++ b/drivers/md/dm-crypt.c @@ -147,7 +147,6 @@ struct crypt_config { struct task_struct *write_thread; struct rb_root write_tree; - char *cipher; char *cipher_string; char *cipher_auth; char *key_string; @@ -2166,7 +2165,6 @@ static void crypt_dtr(struct dm_target *ti) if (cc->dev) dm_put_device(ti, cc->dev); - kzfree(cc->cipher); kzfree(cc->cipher_string); kzfree(cc->key_string); kzfree(cc->cipher_auth); @@ -2247,52 +2245,6 @@ static int crypt_ctr_ivmode(struct dm_target *ti, const char *ivmode) return 0; } -/* - * Workaround to parse cipher algorithm from crypto API spec. - * The cc->cipher is currently used only in ESSIV. - * This should be probably done by crypto-api calls (once available...) - */ -static int crypt_ctr_blkdev_cipher(struct crypt_config *cc) -{ - const char *alg_name = NULL; - char *start, *end; - - if (crypt_integrity_aead(cc)) { - alg_name = crypto_tfm_alg_name(crypto_aead_tfm(any_tfm_aead(cc))); - if (!alg_name) - return -EINVAL; - if (crypt_integrity_hmac(cc)) { - alg_name = strchr(alg_name, ','); - if (!alg_name) - return -EINVAL; - } - alg_name++; - } else { - alg_name = crypto_tfm_alg_name(crypto_skcipher_tfm(any_tfm(cc))); - if (!alg_name) - return -EINVAL; - } - - start = strchr(alg_name, '('); - end = strchr(alg_name, ')'); - - if (!start && !end) { - cc->cipher = kstrdup(alg_name, GFP_KERNEL); - return cc->cipher ? 0 : -ENOMEM; - } - - if (!start || !end || ++start >= end) - return -EINVAL; - - cc->cipher = kzalloc(end - start + 1, GFP_KERNEL); - if (!cc->cipher) - return -ENOMEM; - - strncpy(cc->cipher, start, end - start); - - return 0; -} - /* * Workaround to parse HMAC algorithm from AEAD crypto API spec. * The HMAC is needed to calculate tag size (HMAC digest size). @@ -2402,12 +2354,6 @@ static int crypt_ctr_cipher_new(struct dm_target *ti, char *cipher_in, char *key else cc->iv_size = crypto_skcipher_ivsize(any_tfm(cc)); - ret = crypt_ctr_blkdev_cipher(cc); - if (ret < 0) { - ti->error = "Cannot allocate cipher string"; - return -ENOMEM; - } - return 0; } @@ -2442,10 +2388,6 @@ static int crypt_ctr_cipher_old(struct dm_target *ti, char *cipher_in, char *key } cc->key_parts = cc->tfms_count; - cc->cipher = kstrdup(cipher, GFP_KERNEL); - if (!cc->cipher) - goto bad_mem; - chainmode = strsep(&tmp, "-"); *ivmode = strsep(&tmp, ":"); *ivopts = tmp;
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> --- drivers/md/dm-crypt.c | 58 -------------------- 1 file changed, 58 deletions(-) -- 2.17.1