Re: [PATCH RFC 1/3] crypto: Prevent to register duplicate cra_driver_name

[LABBE Corentin]

On Thu, Dec 21, 2017 at 01:35:27PM +0100, LABBE Corentin wrote:
> On Thu, Dec 21, 2017 at 05:35:22PM +1100, Herbert Xu wrote:
> > On Wed, Dec 20, 2017 at 08:09:25PM +, Corentin Labbe wrote:
> > > Each crypto algorithm "cra_name" can have multiple implementation called
> > > "cra_driver_name".
> > > If two different implementation have the same cra_driver_name, nothing
> > > can easily differentiate them.
> > > Furthermore the mechanism for getting a crypto algorithm with its
> > > implementation name (crypto_alg_match() in crypto/crypto_user.c) will
> > > get only the first one found.
> > > 
> > > So this patch prevent the registration of two implementation with the
> > > same cra_driver_name.
> > > 
> > > Signed-off-by: Corentin Labbe 
> > 
> > No this is intentional.  The idea is that you can hot-replace
> > an implementation by registering a new version of it while the
> > old one is still in use.  The new one will be used for all new
> > allocations.
> > 
> 
> But the new implementation is different from the first so should have a new 
> name.
> The only case I found is ctr-aes-ce, and both are different (use/dontuse 
> simd) so qualifying for different name.
> 
> Anyway, any advice on how to populate properly /sys/crypto with unique name ?
> I have two idea:
> - A number which increment after each register
> - cra_driver_name-priority
> 
> Or does I use /sys/crypto/cra_driver_name/priority ? (which need to use some 
> usage count on cra_driver_name node)

I just see that kobject already have reference counting so this solution is the 
better.

Regards

Re: [PATCH RFC 1/3] crypto: Prevent to register duplicate cra_driver_name

[LABBE Corentin]

On Thu, Dec 21, 2017 at 01:35:27PM +0100, LABBE Corentin wrote:
> On Thu, Dec 21, 2017 at 05:35:22PM +1100, Herbert Xu wrote:
> > On Wed, Dec 20, 2017 at 08:09:25PM +, Corentin Labbe wrote:
> > > Each crypto algorithm "cra_name" can have multiple implementation called
> > > "cra_driver_name".
> > > If two different implementation have the same cra_driver_name, nothing
> > > can easily differentiate them.
> > > Furthermore the mechanism for getting a crypto algorithm with its
> > > implementation name (crypto_alg_match() in crypto/crypto_user.c) will
> > > get only the first one found.
> > > 
> > > So this patch prevent the registration of two implementation with the
> > > same cra_driver_name.
> > > 
> > > Signed-off-by: Corentin Labbe 
> > 
> > No this is intentional.  The idea is that you can hot-replace
> > an implementation by registering a new version of it while the
> > old one is still in use.  The new one will be used for all new
> > allocations.
> > 
> 
> But the new implementation is different from the first so should have a new 
> name.
> The only case I found is ctr-aes-ce, and both are different (use/dontuse 
> simd) so qualifying for different name.
> 
> Anyway, any advice on how to populate properly /sys/crypto with unique name ?
> I have two idea:
> - A number which increment after each register
> - cra_driver_name-priority
> 
> Or does I use /sys/crypto/cra_driver_name/priority ? (which need to use some 
> usage count on cra_driver_name node)

I just see that kobject already have reference counting so this solution is the 
better.

Regards

Re: [PATCH RFC 1/3] crypto: Prevent to register duplicate cra_driver_name

[LABBE Corentin]

On Thu, Dec 21, 2017 at 05:35:22PM +1100, Herbert Xu wrote:
> On Wed, Dec 20, 2017 at 08:09:25PM +, Corentin Labbe wrote:
> > Each crypto algorithm "cra_name" can have multiple implementation called
> > "cra_driver_name".
> > If two different implementation have the same cra_driver_name, nothing
> > can easily differentiate them.
> > Furthermore the mechanism for getting a crypto algorithm with its
> > implementation name (crypto_alg_match() in crypto/crypto_user.c) will
> > get only the first one found.
> > 
> > So this patch prevent the registration of two implementation with the
> > same cra_driver_name.
> > 
> > Signed-off-by: Corentin Labbe 
> 
> No this is intentional.  The idea is that you can hot-replace
> an implementation by registering a new version of it while the
> old one is still in use.  The new one will be used for all new
> allocations.
> 

But the new implementation is different from the first so should have a new 
name.
The only case I found is ctr-aes-ce, and both are different (use/dontuse simd) 
so qualifying for different name.

Anyway, any advice on how to populate properly /sys/crypto with unique name ?
I have two idea:
- A number which increment after each register
- cra_driver_name-priority

Or does I use /sys/crypto/cra_driver_name/priority ? (which need to use some 
usage count on cra_driver_name node)

Regards

Re: [PATCH RFC 1/3] crypto: Prevent to register duplicate cra_driver_name

[LABBE Corentin]

On Thu, Dec 21, 2017 at 05:35:22PM +1100, Herbert Xu wrote:
> On Wed, Dec 20, 2017 at 08:09:25PM +, Corentin Labbe wrote:
> > Each crypto algorithm "cra_name" can have multiple implementation called
> > "cra_driver_name".
> > If two different implementation have the same cra_driver_name, nothing
> > can easily differentiate them.
> > Furthermore the mechanism for getting a crypto algorithm with its
> > implementation name (crypto_alg_match() in crypto/crypto_user.c) will
> > get only the first one found.
> > 
> > So this patch prevent the registration of two implementation with the
> > same cra_driver_name.
> > 
> > Signed-off-by: Corentin Labbe 
> 
> No this is intentional.  The idea is that you can hot-replace
> an implementation by registering a new version of it while the
> old one is still in use.  The new one will be used for all new
> allocations.
> 

But the new implementation is different from the first so should have a new 
name.
The only case I found is ctr-aes-ce, and both are different (use/dontuse simd) 
so qualifying for different name.

Anyway, any advice on how to populate properly /sys/crypto with unique name ?
I have two idea:
- A number which increment after each register
- cra_driver_name-priority

Or does I use /sys/crypto/cra_driver_name/priority ? (which need to use some 
usage count on cra_driver_name node)

Regards

Re: [PATCH RFC 1/3] crypto: Prevent to register duplicate cra_driver_name

[Herbert Xu]

On Wed, Dec 20, 2017 at 08:09:25PM +, Corentin Labbe wrote:
> Each crypto algorithm "cra_name" can have multiple implementation called
> "cra_driver_name".
> If two different implementation have the same cra_driver_name, nothing
> can easily differentiate them.
> Furthermore the mechanism for getting a crypto algorithm with its
> implementation name (crypto_alg_match() in crypto/crypto_user.c) will
> get only the first one found.
> 
> So this patch prevent the registration of two implementation with the
> same cra_driver_name.
> 
> Signed-off-by: Corentin Labbe 

No this is intentional.  The idea is that you can hot-replace
an implementation by registering a new version of it while the
old one is still in use.  The new one will be used for all new
allocations.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH RFC 1/3] crypto: Prevent to register duplicate cra_driver_name

[Herbert Xu]

On Wed, Dec 20, 2017 at 08:09:25PM +, Corentin Labbe wrote:
> Each crypto algorithm "cra_name" can have multiple implementation called
> "cra_driver_name".
> If two different implementation have the same cra_driver_name, nothing
> can easily differentiate them.
> Furthermore the mechanism for getting a crypto algorithm with its
> implementation name (crypto_alg_match() in crypto/crypto_user.c) will
> get only the first one found.
> 
> So this patch prevent the registration of two implementation with the
> same cra_driver_name.
> 
> Signed-off-by: Corentin Labbe 

No this is intentional.  The idea is that you can hot-replace
an implementation by registering a new version of it while the
old one is still in use.  The new one will be used for all new
allocations.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH RFC 1/3] crypto: Prevent to register duplicate cra_driver_name

[Stephan Mueller]

Am Mittwoch, 20. Dezember 2017, 21:09:25 CET schrieb Corentin Labbe:

Hi Corentin,

> Each crypto algorithm "cra_name" can have multiple implementation called
> "cra_driver_name".
> If two different implementation have the same cra_driver_name, nothing
> can easily differentiate them.
> Furthermore the mechanism for getting a crypto algorithm with its
> implementation name (crypto_alg_match() in crypto/crypto_user.c) will
> get only the first one found.
> 
> So this patch prevent the registration of two implementation with the
> same cra_driver_name.

Have you seen that happen? The driver_name should be an unambiguous name that 
is unique throughout all crypto implementations.

If you have seen a duplication, then this duplication should be fixed.

Ciao
Stephan

Re: [PATCH RFC 1/3] crypto: Prevent to register duplicate cra_driver_name

[Stephan Mueller]

Am Mittwoch, 20. Dezember 2017, 21:09:25 CET schrieb Corentin Labbe:

Hi Corentin,

> Each crypto algorithm "cra_name" can have multiple implementation called
> "cra_driver_name".
> If two different implementation have the same cra_driver_name, nothing
> can easily differentiate them.
> Furthermore the mechanism for getting a crypto algorithm with its
> implementation name (crypto_alg_match() in crypto/crypto_user.c) will
> get only the first one found.
> 
> So this patch prevent the registration of two implementation with the
> same cra_driver_name.

Have you seen that happen? The driver_name should be an unambiguous name that 
is unique throughout all crypto implementations.

If you have seen a duplication, then this duplication should be fixed.

Ciao
Stephan

[PATCH RFC 1/3] crypto: Prevent to register duplicate cra_driver_name

[Corentin Labbe]

Each crypto algorithm "cra_name" can have multiple implementation called
"cra_driver_name".
If two different implementation have the same cra_driver_name, nothing
can easily differentiate them.
Furthermore the mechanism for getting a crypto algorithm with its
implementation name (crypto_alg_match() in crypto/crypto_user.c) will
get only the first one found.

So this patch prevent the registration of two implementation with the
same cra_driver_name.

Signed-off-by: Corentin Labbe 
---
 crypto/algapi.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/crypto/algapi.c b/crypto/algapi.c
index 60d7366ed343..b8f6122f37e9 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -208,6 +208,11 @@ static struct crypto_larval *__crypto_register_alg(struct 
crypto_alg *alg)
goto err;
continue;
}
+   if (!strcmp(q->cra_driver_name, alg->cra_driver_name)) {
+   pr_err("Cannot register since cra_driver_name %s is 
already used\n",
+  alg->cra_driver_name);
+   goto err;
+   }
 
if (!strcmp(q->cra_driver_name, alg->cra_name) ||
!strcmp(q->cra_name, alg->cra_driver_name))
-- 
2.13.6

[PATCH RFC 1/3] crypto: Prevent to register duplicate cra_driver_name

[Corentin Labbe]

Each crypto algorithm "cra_name" can have multiple implementation called
"cra_driver_name".
If two different implementation have the same cra_driver_name, nothing
can easily differentiate them.
Furthermore the mechanism for getting a crypto algorithm with its
implementation name (crypto_alg_match() in crypto/crypto_user.c) will
get only the first one found.

So this patch prevent the registration of two implementation with the
same cra_driver_name.

Signed-off-by: Corentin Labbe 
---
 crypto/algapi.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/crypto/algapi.c b/crypto/algapi.c
index 60d7366ed343..b8f6122f37e9 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -208,6 +208,11 @@ static struct crypto_larval *__crypto_register_alg(struct 
crypto_alg *alg)
goto err;
continue;
}
+   if (!strcmp(q->cra_driver_name, alg->cra_driver_name)) {
+   pr_err("Cannot register since cra_driver_name %s is 
already used\n",
+  alg->cra_driver_name);
+   goto err;
+   }
 
if (!strcmp(q->cra_driver_name, alg->cra_name) ||
!strcmp(q->cra_name, alg->cra_driver_name))
-- 
2.13.6