* [PATCH] mac80211: Allocate a sync skcipher explicitly for FILS AEAD
@ 2017-02-04 16:08 Jouni Malinen
2017-02-06 6:54 ` Johannes Berg
0 siblings, 1 reply; 4+ messages in thread
From: Jouni Malinen @ 2017-02-04 16:08 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Ard Biesheuvel, Jouni Malinen
The skcipher could have been of the async variant which may return from
skcipher_encrypt() with -EINPROGRESS after having queued the request.
The FILS AEAD implementation here does not have code for dealing with
that possibility, so allocate a sync cipher explicitly to avoid
potential issues with hardware accelerators.
This is based on the patch sent out by Ard.
Fixes: 39404feee691 ("mac80211: FILS AEAD protection for station mode association frames")
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
---
net/mac80211/fils_aead.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/fils_aead.c b/net/mac80211/fils_aead.c
index e3bbe24..912f3e2c 100644
--- a/net/mac80211/fils_aead.c
+++ b/net/mac80211/fils_aead.c
@@ -192,7 +192,7 @@ static int aes_siv_encrypt(const u8 *key, size_t key_len,
/* CTR */
- tfm2 = crypto_alloc_skcipher("ctr(aes)", 0, 0);
+ tfm2 = crypto_alloc_skcipher("ctr(aes)", 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(tfm2)) {
kfree(tmp);
return PTR_ERR(tfm2);
@@ -251,7 +251,7 @@ static int aes_siv_decrypt(const u8 *key, size_t key_len,
/* CTR */
- tfm2 = crypto_alloc_skcipher("ctr(aes)", 0, 0);
+ tfm2 = crypto_alloc_skcipher("ctr(aes)", 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(tfm2))
return PTR_ERR(tfm2);
/* K2 for CTR */
--
2.7.4
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] mac80211: Allocate a sync skcipher explicitly for FILS AEAD
2017-02-04 16:08 [PATCH] mac80211: Allocate a sync skcipher explicitly for FILS AEAD Jouni Malinen
@ 2017-02-06 6:54 ` Johannes Berg
2017-02-06 9:00 ` Herbert Xu
0 siblings, 1 reply; 4+ messages in thread
From: Johannes Berg @ 2017-02-06 6:54 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless, Ard Biesheuvel, Herbert Xu
Hi,
> The skcipher could have been of the async variant which may return
> from skcipher_encrypt() with -EINPROGRESS after having queued the
> request.
> The FILS AEAD implementation here does not have code for dealing with
> that possibility, so allocate a sync cipher explicitly to avoid
> potential issues with hardware accelerators.
> - tfm2 = crypto_alloc_skcipher("ctr(aes)", 0, 0);
> + tfm2 = crypto_alloc_skcipher("ctr(aes)", 0,
> CRYPTO_ALG_ASYNC);
I'll apply this, after having found some code elsewhere that does
something similar, but I'll note that this is super confusing, since
the only documentation mentioning this flag says:
The mask flag restricts the type of cipher. The only allowed flag is
CRYPTO_ALG_ASYNC to restrict the cipher lookup function to
asynchronous ciphers. Usually, a caller provides a 0 for the mask flag.
(I have a vague feeling the first sentence was intended to be
documentation for the algorithm *implementation* specifying the flag,
and the second for a caller doing a lookup, or something strange?)
johannes
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] mac80211: Allocate a sync skcipher explicitly for FILS AEAD
2017-02-06 6:54 ` Johannes Berg
@ 2017-02-06 9:00 ` Herbert Xu
2017-02-06 9:04 ` Johannes Berg
0 siblings, 1 reply; 4+ messages in thread
From: Herbert Xu @ 2017-02-06 9:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: Jouni Malinen, linux-wireless, Ard Biesheuvel
On Mon, Feb 06, 2017 at 07:54:37AM +0100, Johannes Berg wrote:
> Hi,
>
> > The skcipher could have been of the async variant which may return
> > from skcipher_encrypt() with -EINPROGRESS after having queued the
> > request.
> > The FILS AEAD implementation here does not have code for dealing with
> > that possibility, so allocate a sync cipher explicitly to avoid
> > potential issues with hardware accelerators.
>
> > - tfm2 = crypto_alloc_skcipher("ctr(aes)", 0, 0);
> > + tfm2 = crypto_alloc_skcipher("ctr(aes)", 0,
> > CRYPTO_ALG_ASYNC);
>
> I'll apply this, after having found some code elsewhere that does
> something similar, but I'll note that this is super confusing, since
> the only documentation mentioning this flag says:
>
> The mask flag restricts the type of cipher. The only allowed flag is
> CRYPTO_ALG_ASYNC to restrict the cipher lookup function to
> asynchronous ciphers. Usually, a caller provides a 0 for the mask flag.
The type and mask are used as follows when checking an algorithm:
alg->type & mask == type & mask
So to request a synchronous algorithm (that is, one with the
CRYPTO_ALG_ASYNC bit set to zero), you would set type to 0 and
mask to CRYPTO_ALG_ASYNC.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] mac80211: Allocate a sync skcipher explicitly for FILS AEAD
2017-02-06 9:00 ` Herbert Xu
@ 2017-02-06 9:04 ` Johannes Berg
0 siblings, 0 replies; 4+ messages in thread
From: Johannes Berg @ 2017-02-06 9:04 UTC (permalink / raw)
To: Herbert Xu; +Cc: Jouni Malinen, linux-wireless, Ard Biesheuvel
> The type and mask are used as follows when checking an algorithm:
>
> alg->type & mask == type & mask
>
> So to request a synchronous algorithm (that is, one with the
> CRYPTO_ALG_ASYNC bit set to zero), you would set type to 0 and
> mask to CRYPTO_ALG_ASYNC.
Ah. Ok, that makes sense, thanks for the explanation.
johannes
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-02-06 9:04 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-02-04 16:08 [PATCH] mac80211: Allocate a sync skcipher explicitly for FILS AEAD Jouni Malinen
2017-02-06 6:54 ` Johannes Berg
2017-02-06 9:00 ` Herbert Xu
2017-02-06 9:04 ` Johannes Berg
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).