| Message ID | 20180502095725.31935-2-antoine.tenart@bootlin.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Herbert Xu |
| Headers | show |
From: Antoine Tenart > Sent: 02 May 2018 10:57 > Adds the AEAD_REQUEST_ON_STACK primitive to allow allocating AEAD > requests on the stack, as it can already be done with various other > crypto algorithms within the kernel. > > Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> > --- > include/crypto/aead.h | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/include/crypto/aead.h b/include/crypto/aead.h > index 1e26f790b03f..b67064786546 100644 > --- a/include/crypto/aead.h > +++ b/include/crypto/aead.h > @@ -151,6 +151,11 @@ struct aead_alg { > struct crypto_alg base; > }; > > +#define AEAD_REQUEST_ON_STACK(name, tfm) \ > + char __##name##_desc[sizeof(struct aead_request) + \ > + crypto_aead_reqsize(tfm)] CRYPTO_MINALIGN_ATTR; \ > + struct aead_request *name = (void *)__##name##_desc > + This looks stunningly like a VLA. David
Hi David, On Wed, May 02, 2018 at 02:55:19PM +0000, David Laight wrote: > From: Antoine Tenart > > > > +#define AEAD_REQUEST_ON_STACK(name, tfm) \ > > + char __##name##_desc[sizeof(struct aead_request) + \ > > + crypto_aead_reqsize(tfm)] CRYPTO_MINALIGN_ATTR; \ > > + struct aead_request *name = (void *)__##name##_desc > > + > > This looks stunningly like a VLA. I was expecting this question :) The thing is this define looks *a lot* like the ones defined in other places in the crypto framework, such as SKCIPHER_REQUEST_ON_STACK and AHASH_REQUEST_ON_STACK. Those haven't been tackled down so far by the whole VLA removal so the idea was that the same solution will apply to the 3 of them (and then I'm not really adding a new one). If you do have a suggestion on how to fix the 3 of them, I'll be glad to make a patch for that, but I'm not sure there's an easy solution. And I don't think I saw a patch on the mailing list about those defines. Thanks, Antoine
On Thu, May 03, 2018 at 02:23:30PM +0200, 'Antoine Tenart' wrote: > > I was expecting this question :) The thing is this define looks *a lot* > like the ones defined in other places in the crypto framework, such as > SKCIPHER_REQUEST_ON_STACK and AHASH_REQUEST_ON_STACK. Those haven't been > tackled down so far by the whole VLA removal so the idea was that the > same solution will apply to the 3 of them (and then I'm not really > adding a new one). Those constructs only exist for reasons of backwards compatibility. There is no such reason for AEAD. So why do you need this? Cheers,
Hi Herbert, On Fri, May 04, 2018 at 07:00:06AM +0800, Herbert Xu wrote: > On Thu, May 03, 2018 at 02:23:30PM +0200, 'Antoine Tenart' wrote: > > > > I was expecting this question :) The thing is this define looks *a lot* > > like the ones defined in other places in the crypto framework, such as > > SKCIPHER_REQUEST_ON_STACK and AHASH_REQUEST_ON_STACK. Those haven't been > > tackled down so far by the whole VLA removal so the idea was that the > > same solution will apply to the 3 of them (and then I'm not really > > adding a new one). > > Those constructs only exist for reasons of backwards compatibility. > > There is no such reason for AEAD. So why do you need this? In this driver we need to perform in certain cases an invalidation, which is done thanks to invalidation requests. To do this we create dummy requests, using SKCIPHER_REQUEST_ON_STACK and AHASH_REQUEST_ON_STACK for ciphers and hashes. So when adding the AEAD algs support, in patch 8/10, AEAD_REQUEST_ON_STACK is used for the same reason. Should we allocate this in a different way? Thanks! Antoine
On Fri, May 04, 2018 at 09:18:41AM +0200, 'Antoine Tenart' wrote: > > In this driver we need to perform in certain cases an invalidation, > which is done thanks to invalidation requests. To do this we create > dummy requests, using SKCIPHER_REQUEST_ON_STACK and > AHASH_REQUEST_ON_STACK for ciphers and hashes. So when adding the AEAD > algs support, in patch 8/10, AEAD_REQUEST_ON_STACK is used for the same > reason. > > Should we allocate this in a different way? These are not uses intended for the ON_STACK macros. They were only ever meant for existing users of the synchonous crypto API. I would suggest either allocating a new request on the spot or if that is not convenient, pre-allocating it in the cra_init function. Cheers,
Hi Herbert, On Sat, May 05, 2018 at 02:18:55PM +0800, Herbert Xu wrote: > On Fri, May 04, 2018 at 09:18:41AM +0200, 'Antoine Tenart' wrote: > > > > In this driver we need to perform in certain cases an invalidation, > > which is done thanks to invalidation requests. To do this we create > > dummy requests, using SKCIPHER_REQUEST_ON_STACK and > > AHASH_REQUEST_ON_STACK for ciphers and hashes. So when adding the AEAD > > algs support, in patch 8/10, AEAD_REQUEST_ON_STACK is used for the same > > reason. > > > > Should we allocate this in a different way? > > These are not uses intended for the ON_STACK macros. They were > only ever meant for existing users of the synchonous crypto API. OK, I see. > I would suggest either allocating a new request on the spot or if > that is not convenient, pre-allocating it in the cra_init function. Or we could have similar macros in the driver: we wouldn't have VLAs since it would be driver specific. Thanks! Antoine
diff --git a/include/crypto/aead.h b/include/crypto/aead.h index 1e26f790b03f..b67064786546 100644 --- a/include/crypto/aead.h +++ b/include/crypto/aead.h @@ -151,6 +151,11 @@ struct aead_alg { struct crypto_alg base; }; +#define AEAD_REQUEST_ON_STACK(name, tfm) \ + char __##name##_desc[sizeof(struct aead_request) + \ + crypto_aead_reqsize(tfm)] CRYPTO_MINALIGN_ATTR; \ + struct aead_request *name = (void *)__##name##_desc + struct crypto_aead { unsigned int authsize; unsigned int reqsize;
Adds the AEAD_REQUEST_ON_STACK primitive to allow allocating AEAD requests on the stack, as it can already be done with various other crypto algorithms within the kernel. Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> --- include/crypto/aead.h | 5 +++++ 1 file changed, 5 insertions(+)