LKML Archive on
help / color / mirror / Atom feed
From: Megha Dey <>
To: Herbert Xu <>
Subject: Re: [RFC] crypto: Remove mcryptd
Date: Thu, 26 Jul 2018 17:25:07 -0700	[thread overview]
Message-ID: <1532651107.19157.24.camel@megha-Z97X-UD7-TH> (raw)
In-Reply-To: <>

On Fri, 2018-07-20 at 11:53 +0800, Herbert Xu wrote:
> On Fri, May 11, 2018 at 06:44:13PM -0700, Megha Dey wrote:
> >
> > +static struct ahash_alg *simd_ahash_create_compat(const char *algname,
> > +						       const char *drvname,
> > +						       const char *basename)
> > +{
> > +	struct ahash_alg *alg;
> > +	struct ahash_alg *ialg;
> > +	int err;
> I think there has been a misunderstsanding.  You're not actually
> using the simd wrapper here.  All you're doing is creating a function
> with the word simd in its name.  In all other respects this is just
> exposing the underlying algorithm to users directly, which cannot
> work because the underlying algorithm requires SIMD.

Hi Herbert,

Thanks for the feedback.

I still have some questions though:

1. On the existing algorithms covered in aesni_intel-glue.c (eg:
__cbc-aes-aesni), 3 algorithms are registered in /proc/crypto:

     cryptd(__cbc-aes-aesni)--> registered via cryptd_create_skcipher

     cbc-aes-aesni	--> registered via simd_skcipher_create_compat

     __cbc-aes-aesni    --> registered as the internal algorithm

I would want to know why do we need the cryptd(__cbc-aes-aesni)
algorithm at all. I do not see any of the associated setkey, encrypt or
decrypt functions getting called during the selftest or while running
tcrypt. I just see the simd_(setkey, encrypt, decrypt) functions
directly called the inner algorithms. However, if I remove the cryptd
algorithm, none of the algorithms are registered.

> What you need to do is create an actual simd wrapper with cryptd
This simd wrapper is already present for skcipher right(in simd.c)?
Assuming we only have ciphers and no hash algorithms, are any changes
required in these wrappers?

Pseudo code:
1. Register inner algorithm (cbc-aes-aesni-mb) in aes_cbc_mb_mod_init()
2. Register outer algorithm with the mcryptd- prefix for the driver name
using the simd_skcipher_create_compat(mcryptd-cbc-aes-aesni-mb)
3. tcrypt/testmanager calls the
4. Shift helper functions which help flush outstanding jobs to glue
5. Delete mcryptd.c
6. All similar simd wrapper for hash algorithms. 

> and all the functions that may do SIMD work needs to invoke cryptd
> if may_use_simd() (and other conditions) is false.
> This wrapper should live in crypto/simd.c.
> Cheers,

  reply	other threads:[~2018-07-27  0:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-12  1:44 Megha Dey
2018-05-31 18:15 ` Megha Dey
2018-07-20  3:53 ` Herbert Xu
2018-07-27  0:25   ` Megha Dey [this message]
2018-08-08  9:56     ` Herbert Xu
2018-08-10  2:40       ` Megha Dey
2018-08-16  6:55         ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1532651107.19157.24.camel@megha-Z97X-UD7-TH \ \ \ \ \
    --subject='Re: [RFC] crypto: Remove mcryptd' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).