Re: [PATCH 7/7] mac80211: Switch to new AEAD interface

2015-06-02 Thread Jouni Malinen
On Mon, Jun 01, 2015 at 05:36:58PM +0200, Stephan Mueller wrote:
 Am Montag, 1. Juni 2015, 16:35:26 schrieb Johannes Berg:
 IOW, I think something like this would make sense:
 
 That looks definitely cleaner :-)

Indeed.. That AAD length-in-the-buffer design came from the over ten
year old code that was optimized to cover the CCM construction with the
same buffer and that was not cleaned up when this was converted to use
cryptoapi couple of years ago.

 Though, my main concern was just to ensure that the aad length value is not 
 zero.

It won't be in IEEE 802.11 use cases. The exact length depends on the
IEEE 802.11 frame type, but AAD is constructed in a way that it is
normally a bit over 20 octets while allowing CCM to fit the related
operations into two AES blocks.
 
-- 
Jouni MalinenPGP id EFC895FA
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 7/7] mac80211: Switch to new AEAD interface

2015-06-01 Thread Stephan Mueller
Am Montag, 1. Juni 2015, 16:35:26 schrieb Johannes Berg:

Hi Johannes,


IOW, I think something like this would make sense:


That looks definitely cleaner :-)

Though, my main concern was just to ensure that the aad length value is not 
zero.


Ciao
Stephan
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 7/7] mac80211: Switch to new AEAD interface

2015-06-01 Thread Johannes Berg
On Mon, 2015-06-01 at 15:49 +0200, Stephan Mueller wrote:

 The contents, now, that's a more interesting question. I believe it can
 never be all zeroes, since association request frames are not
 encrypted/protected and thus at least one byte in here must be non-zero.
 The MAC addresses are also very likely non-zero, but technically
 00:00:00:00:00:00 is a valid MAC address I believe.
 
 So, even when having a malicious AP, that value is never zero? The driver of 
 the question is the following code in the patch set:
 
 +   sg_set_buf(sg[0], aad[2], be16_to_cpup((__be16 *)aad));
 
 ...
 
 +   aead_request_set_crypt(aead_req, sg, sg, data_len, b_0);
 
 ...
 
 crypto_aead_encrypt(aead_req);
 
 
 When I played around with the aead_request_set_crypt, I saw a crash in the 
 scatterlist handling of the crypto API when the first SGL entry has a zero 
 length.

Wait, I guess that's a *third* way for this to be zero a valid pointer
but zero length data?

Oh, no - you're referring to the CCM/GCM cases only, I guess, i.e. this
part:

-   sg_init_one(assoc, aad[2], be16_to_cpup((__be16 *)aad));
+   sg_set_buf(sg[0], aad[2], be16_to_cpup((__be16 *)aad));

I was looking at GMAC and that has a constant for the length :-)

Ok - here the length is kinda passed a part of the AAD buffer, but this
is really just some arcane code that should be fixed to use a proper
struct. The value there, even though it is __be16 and looks like it came
from the data, is actually created locally, see ccmp_special_blocks()
and gcmp_special_blocks().

johannes

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 7/7] mac80211: Switch to new AEAD interface

2015-06-01 Thread Stephan Mueller
Am Donnerstag, 21. Mai 2015, 13:20:49 schrieb Johannes Berg:

Hi Johannes,

 On Thu, 2015-05-21 at 18:44 +0800, Herbert Xu wrote:
  This patch makes use of the new AEAD interface which uses a single
  SG list instead of separate lists for the AD and plain text.
 
 Looks fine - want me to run any tests on it?

Just a short question on ieee80211_aes_ccm_encrypt, ieee80211_aes_ccm_decrypt, 
ieee80211_aes_gcm_encrypt, ieee80211_aes_gcm_decrypt, ieee80211_aes_gmac: can 
the aad parameter of these functions be zero?

-- 
Ciao
Stephan
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 7/7] mac80211: Switch to new AEAD interface

2015-06-01 Thread Stephan Mueller
Am Montag, 1. Juni 2015, 15:42:41 schrieb Johannes Berg:

Hi Johannes,

On Mon, 2015-06-01 at 15:21 +0200, Stephan Mueller wrote:
 Just a short question on ieee80211_aes_ccm_encrypt,
 ieee80211_aes_ccm_decrypt, ieee80211_aes_gcm_encrypt,
 ieee80211_aes_gcm_decrypt, ieee80211_aes_gmac: can the aad parameter of
 these functions be zero?

What do you mean by zero? The pointer itself can clearly never be
NULL.

Thanks for clarifying: indeed I mean the value of the pointer, not the pointer 
itself :-)

The contents, now, that's a more interesting question. I believe it can
never be all zeroes, since association request frames are not
encrypted/protected and thus at least one byte in here must be non-zero.
The MAC addresses are also very likely non-zero, but technically
00:00:00:00:00:00 is a valid MAC address I believe.

So, even when having a malicious AP, that value is never zero? The driver of 
the question is the following code in the patch set:

+   sg_set_buf(sg[0], aad[2], be16_to_cpup((__be16 *)aad));

...

+   aead_request_set_crypt(aead_req, sg, sg, data_len, b_0);

...

crypto_aead_encrypt(aead_req);


When I played around with the aead_request_set_crypt, I saw a crash in the 
scatterlist handling of the crypto API when the first SGL entry has a zero 
length.

Ciao
Stephan
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 7/7] mac80211: Switch to new AEAD interface

2015-06-01 Thread Johannes Berg
On Mon, 2015-06-01 at 15:21 +0200, Stephan Mueller wrote:

 Just a short question on ieee80211_aes_ccm_encrypt, 
 ieee80211_aes_ccm_decrypt, 
 ieee80211_aes_gcm_encrypt, ieee80211_aes_gcm_decrypt, ieee80211_aes_gmac: can 
 the aad parameter of these functions be zero?

What do you mean by zero? The pointer itself can clearly never be
NULL.

The contents, now, that's a more interesting question. I believe it can
never be all zeroes, since association request frames are not
encrypted/protected and thus at least one byte in here must be non-zero.
The MAC addresses are also very likely non-zero, but technically
00:00:00:00:00:00 is a valid MAC address I believe.

johannes


--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 7/7] mac80211: Switch to new AEAD interface

2015-06-01 Thread Johannes Berg
On Mon, 2015-06-01 at 16:05 +0200, Johannes Berg wrote:

 Ok - here the length is kinda passed a part of the AAD buffer, but this
 is really just some arcane code that should be fixed to use a proper
 struct. The value there, even though it is __be16 and looks like it came
 from the data, is actually created locally, see ccmp_special_blocks()
 and gcmp_special_blocks().

IOW, I think something like this would make sense:

(but I'll hold it until after Herbert's patches I guess)

From 20bd0e92ab0d7ef545687da762228622bcdabeec Mon Sep 17 00:00:00 2001
From: Johannes Berg johannes.b...@intel.com
Date: Mon, 1 Jun 2015 16:33:11 +0200
Subject: [PATCH] mac80211: move AAD length out of AAD buffer

The code currently passes the AAD buffer as a __be16 with the
length, followed by the actual data, but doesn't use a struct
or make this explicit in any other way, so it's confusing.

Change the code to pass the AAD length explicity outside of
the buffer.

Reported-by: Stephan Mueller smuel...@chronox.de
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
 net/mac80211/aes_ccm.c | 18 +++---
 net/mac80211/aes_ccm.h | 14 ++-
 net/mac80211/aes_gcm.c | 10 
 net/mac80211/aes_gcm.h |  6 +++--
 net/mac80211/wpa.c | 64 +++---
 5 files changed, 62 insertions(+), 50 deletions(-)

diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
index 208df7c0b6ea..b6e2f096127a 100644
--- a/net/mac80211/aes_ccm.c
+++ b/net/mac80211/aes_ccm.c
@@ -19,9 +19,10 @@
 #include key.h
 #include aes_ccm.h
 
-void ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
-  u8 *data, size_t data_len, u8 *mic,
-  size_t mic_len)
+void ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0,
+  u8 *aad, size_t aad_len,
+  u8 *data, size_t data_len,
+  u8 *mic, size_t mic_len)
 {
struct scatterlist assoc, pt, ct[2];
 
@@ -33,7 +34,7 @@ void ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 
*b_0, u8 *aad,
memset(aead_req, 0, sizeof(aead_req_data));
 
sg_init_one(pt, data, data_len);
-   sg_init_one(assoc, aad[2], be16_to_cpup((__be16 *)aad));
+   sg_init_one(assoc, aad, aad_len);
sg_init_table(ct, 2);
sg_set_buf(ct[0], data, data_len);
sg_set_buf(ct[1], mic, mic_len);
@@ -45,9 +46,10 @@ void ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 
*b_0, u8 *aad,
crypto_aead_encrypt(aead_req);
 }
 
-int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic,
- size_t mic_len)
+int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0,
+ u8 *aad, size_t aad_len,
+ u8 *data, size_t data_len,
+ u8 *mic, size_t mic_len)
 {
struct scatterlist assoc, pt, ct[2];
char aead_req_data[sizeof(struct aead_request) +
@@ -61,7 +63,7 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 
*b_0, u8 *aad,
memset(aead_req, 0, sizeof(aead_req_data));
 
sg_init_one(pt, data, data_len);
-   sg_init_one(assoc, aad[2], be16_to_cpup((__be16 *)aad));
+   sg_init_one(assoc, aad, aad_len);
sg_init_table(ct, 2);
sg_set_buf(ct[0], data, data_len);
sg_set_buf(ct[1], mic, mic_len);
diff --git a/net/mac80211/aes_ccm.h b/net/mac80211/aes_ccm.h
index 6a73d1e4d186..bfe355e4a680 100644
--- a/net/mac80211/aes_ccm.h
+++ b/net/mac80211/aes_ccm.h
@@ -15,12 +15,14 @@
 struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[],
size_t key_len,
size_t mic_len);
-void ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
-  u8 *data, size_t data_len, u8 *mic,
-  size_t mic_len);
-int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic,
- size_t mic_len);
+void ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0,
+  u8 *aad, size_t aad_len,
+  u8 *data, size_t data_len,
+  u8 *mic, size_t mic_len);
+int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0,
+ u8 *aad, size_t aad_len,
+ u8 *data, size_t data_len,
+ u8 *mic, size_t mic_len);
 void ieee80211_aes_key_free(struct crypto_aead *tfm);
 
 #endif /* AES_CCM_H */
diff --git a/net/mac80211/aes_gcm.c b/net/mac80211/aes_gcm.c
index fd278bbe1b0d..fb6823c5e381 100644
--- a/net/mac80211/aes_gcm.c
+++ b/net/mac80211/aes_gcm.c
@@ 

Re: [PATCH 7/7] mac80211: Switch to new AEAD interface

2015-05-22 Thread Herbert Xu
On Fri, May 22, 2015 at 09:43:28AM +0200, Johannes Berg wrote:
 
 Oops, sorry, of course - I was running in a VM :)

Thanks!

Does this patch on top help?

diff --git a/net/mac80211/aes_gmac.c b/net/mac80211/aes_gmac.c
index 7eee32b..133be53 100644
--- a/net/mac80211/aes_gmac.c
+++ b/net/mac80211/aes_gmac.c
@@ -24,22 +24,24 @@
 int ieee80211_aes_gmac(struct crypto_aead *tfm, const u8 *aad, u8 *nonce,
   const u8 *data, size_t data_len, u8 *mic)
 {
-   struct scatterlist sg[3];
+   struct scatterlist sg[4];
char aead_req_data[sizeof(struct aead_request) +
   crypto_aead_reqsize(tfm)]
__aligned(__alignof__(struct aead_request));
struct aead_request *aead_req = (void *)aead_req_data;
-   u8 iv[AES_BLOCK_SIZE];
+   u8 zero[GMAC_MIC_LEN], iv[AES_BLOCK_SIZE];
 
if (data_len  GMAC_MIC_LEN)
return -EINVAL;
 
memset(aead_req, 0, sizeof(aead_req_data));
 
-   sg_init_table(sg, 3);
+   memset(zero, 0, GMAC_MIC_LEN);
+   sg_init_table(sg, 4);
sg_set_buf(sg[0], aad, AAD_LEN);
sg_set_buf(sg[1], data, data_len - GMAC_MIC_LEN);
-   sg_set_buf(sg[2], mic, GMAC_MIC_LEN);
+   sg_set_buf(sg[2], zero, GMAC_MIC_LEN);
+   sg_set_buf(sg[3], mic, GMAC_MIC_LEN);
 
memcpy(iv, nonce, GMAC_NONCE_LEN);
memset(iv + GMAC_NONCE_LEN, 0, sizeof(iv) - GMAC_NONCE_LEN);
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 7/7] mac80211: Switch to new AEAD interface

2015-05-22 Thread Herbert Xu
On Fri, May 22, 2015 at 10:18:03AM +0200, Johannes Berg wrote:

 Yep, that fixes things.

Great I will respin the patches.

Thanks,
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 7/7] mac80211: Switch to new AEAD interface

2015-05-22 Thread Johannes Berg
On Fri, 2015-05-22 at 15:41 +0800, Herbert Xu wrote:

 Did this have a code section at the end? Without it it's difficult
 to pin-point the crash because your compiler produces different
 output than mine.

Oops, sorry, of course - I was running in a VM :)

[   26.143579] BUG: unable to handle kernel NULL pointer dereference at 
  (null)
[   26.144406] IP: [811d9e7d] scatterwalk_map_and_copy+0x3d/0xd0
[   26.145071] PGD da3a067 PUD d9ee067 PMD 0 
[   26.145514] Oops:  [#1] PREEMPT SMP DEBUG_PAGEALLOC 
[   26.146146] CPU: 1 PID: 661 Comm: hostapd Not tainted 4.0.0+ #860
[   26.146746] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.7.5-20140531_083030-gandalf 04/01/2014
[   26.148333] task: 88000d9a4a20 ti: 8807 task.ti: 
8807
[   26.149625] RIP: 0010:[811d9e7d]  [811d9e7d] 
scatterwalk_map_and_copy+0x3d/0xd0
[   26.151223] RSP: 0018:880733b8  EFLAGS: 00010246
[   26.152156] RAX:  RBX: 0010 RCX: 77ff8000
[   26.153396] RDX: 8000 RSI:  RDI: 880733c8
[   26.153481] RBP: 88073428 R08: 0001 R09: 0010
[   26.153481] R10: 0010 R11: 0012 R12: 0001
[   26.153481] R13: 880735f8 R14:  R15: 0030
[   26.153481] FS:  7f20eee60700() GS:88000f60() 
knlGS:
[   26.153481] CS:  0010 DS:  ES:  CR0: 80050033
[   26.153481] CR2:  CR3: 0da2a000 CR4: 07a0
[   26.153481] Stack:
[   26.153481]   0030 880733d8 
811e05c6
[   26.153481]  880733f8 811df815 880735f8 
88073598
[   26.153481]  88073408 811dfc86 88073438 
880735f8
[   26.153481] Call Trace:
[   26.153481]  [811e05c6] ? shash_async_final+0x16/0x20
[   26.153481]  [811df815] ? crypto_ahash_op+0x25/0x60
[   26.153481]  [811dfc86] ? crypto_ahash_final+0x16/0x20
[   26.153481]  [811e3608] gcm_enc_copy_hash+0x28/0x30
[   26.153481]  [811e36fc] crypto_gcm_encrypt+0xec/0x100
[   26.153481]  [811e3610] ? gcm_enc_copy_hash+0x30/0x30
[   26.153481]  [811da875] old_crypt+0xc5/0xe0
[   26.153481]  [811da8cd] old_encrypt+0x1d/0x20
[   26.153481]  [814b688b] ieee80211_aes_gmac+0x21b/0x230
[...]
[   26.153481]  [81543dee] system_call_fastpath+0x12/0x76
[   26.153481] Code: 89 e5 41 55 49 89 fd 41 54 48 8d 7d a0 45 89 c4 53 89 cb 
48 83 ec 58 e8 12 ff ff ff ba 00 00 00 80 48 b9 00 00 00 80 ff 77 00 00 48 8b 
30 48 83 e6 fc 4c 01 ea 48 0f 42 0d 81 31 63 00 48 01 ca 
[   26.153481] RIP  [811d9e7d] scatterwalk_map_and_copy
+0x3d/0xd0
[   26.153481]  RSP 880733b8
[   26.153481] CR2: 
[   26.153481] ---[ end trace b6af799d0103eb26 ]---

johannes

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 7/7] mac80211: Switch to new AEAD interface

2015-05-22 Thread Herbert Xu
On Fri, May 22, 2015 at 09:32:28AM +0200, Johannes Berg wrote:
 
 The CCM and GCM part seems to work, but GMAC causes a kernel crash:

Awesome :)

 [   26.143579] BUG: unable to handle kernel NULL pointer dereference at   
 (null)
 [   26.144406] IP: [811d9e7d] scatterwalk_map_and_copy+0x3d/0xd0
 [   26.145071] PGD da3a067 PUD d9ee067 PMD 0 
 [   26.145514] Oops:  [#1] PREEMPT SMP DEBUG_PAGEALLOC 
 [   26.146146] CPU: 1 PID: 661 Comm: hostapd Not tainted 4.0.0+ #860
 [   26.146746] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
 1.7.5-20140531_083030-gandalf 04/01/2014
 [   26.148333] task: 88000d9a4a20 ti: 8807 task.ti: 
 8807
 [   26.149625] RIP: 0010:[811d9e7d]  [811d9e7d] 
 scatterwalk_map_and_copy+0x3d/0xd0
 [   26.151223] RSP: 0018:880733b8  EFLAGS: 00010246
 [   26.152156] RAX:  RBX: 0010 RCX: 
 77ff8000
 [   26.153396] RDX: 8000 RSI:  RDI: 
 880733c8
 [   26.153481] RBP: 88073428 R08: 0001 R09: 
 0010
 [   26.153481] R10: 0010 R11: 0012 R12: 
 0001
 [   26.153481] R13: 880735f8 R14:  R15: 
 0030
 [   26.153481] FS:  7f20eee60700() GS:88000f60() 
 knlGS:
 [   26.153481] CS:  0010 DS:  ES:  CR0: 80050033
 [   26.153481] CR2:  CR3: 0da2a000 CR4: 
 07a0
 [   26.153481] Stack:
 [   26.153481]   0030 880733d8 
 811e05c6
 [   26.153481]  880733f8 811df815 880735f8 
 88073598
 [   26.153481]  88073408 811dfc86 88073438 
 880735f8
 [   26.153481] Call Trace:
 [   26.153481]  [811e05c6] ? shash_async_final+0x16/0x20
 [   26.153481]  [811df815] ? crypto_ahash_op+0x25/0x60
 [   26.153481]  [811dfc86] ? crypto_ahash_final+0x16/0x20
 [   26.153481]  [811e3608] gcm_enc_copy_hash+0x28/0x30
 [   26.153481]  [811e36fc] crypto_gcm_encrypt+0xec/0x100
 [   26.153481]  [811e3610] ? gcm_enc_copy_hash+0x30/0x30
 [   26.153481]  [811da875] old_crypt+0xc5/0xe0
 [   26.153481]  [811da8cd] old_encrypt+0x1d/0x20
 [   26.153481]  [814b688b] ieee80211_aes_gmac+0x21b/0x230
 [   26.153481]  [811e3710] ? crypto_gcm_encrypt+0x100/0x100
 [   26.153481]  [811e2f10] ? __gcm_hash_final_done+0x60/0x60
 [   26.153481]  [814b66a4] ? ieee80211_aes_gmac+0x34/0x230
 [   26.153481]  [81498621] 
 ieee80211_crypto_aes_gmac_encrypt+0x191/0x1a0
 [   26.153481]  [8153b794] ieee80211_tx_h_encrypt+0x67/0x77
 [   26.153481]  [814cd496] invoke_tx_handlers+0xe6/0x1b0

Did this have a code section at the end? Without it it's difficult
to pin-point the crash because your compiler produces different
output than mine.

Thanks,
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 7/7] mac80211: Switch to new AEAD interface

2015-05-22 Thread Johannes Berg
On Thu, 2015-05-21 at 18:44 +0800, Herbert Xu wrote:
 This patch makes use of the new AEAD interface which uses a single
 SG list instead of separate lists for the AD and plain text.

The CCM and GCM part seems to work, but GMAC causes a kernel crash:

[   26.143579] BUG: unable to handle kernel NULL pointer dereference at 
  (null)
[   26.144406] IP: [811d9e7d] scatterwalk_map_and_copy+0x3d/0xd0
[   26.145071] PGD da3a067 PUD d9ee067 PMD 0 
[   26.145514] Oops:  [#1] PREEMPT SMP DEBUG_PAGEALLOC 
[   26.146146] CPU: 1 PID: 661 Comm: hostapd Not tainted 4.0.0+ #860
[   26.146746] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.7.5-20140531_083030-gandalf 04/01/2014
[   26.148333] task: 88000d9a4a20 ti: 8807 task.ti: 
8807
[   26.149625] RIP: 0010:[811d9e7d]  [811d9e7d] 
scatterwalk_map_and_copy+0x3d/0xd0
[   26.151223] RSP: 0018:880733b8  EFLAGS: 00010246
[   26.152156] RAX:  RBX: 0010 RCX: 77ff8000
[   26.153396] RDX: 8000 RSI:  RDI: 880733c8
[   26.153481] RBP: 88073428 R08: 0001 R09: 0010
[   26.153481] R10: 0010 R11: 0012 R12: 0001
[   26.153481] R13: 880735f8 R14:  R15: 0030
[   26.153481] FS:  7f20eee60700() GS:88000f60() 
knlGS:
[   26.153481] CS:  0010 DS:  ES:  CR0: 80050033
[   26.153481] CR2:  CR3: 0da2a000 CR4: 07a0
[   26.153481] Stack:
[   26.153481]   0030 880733d8 
811e05c6
[   26.153481]  880733f8 811df815 880735f8 
88073598
[   26.153481]  88073408 811dfc86 88073438 
880735f8
[   26.153481] Call Trace:
[   26.153481]  [811e05c6] ? shash_async_final+0x16/0x20
[   26.153481]  [811df815] ? crypto_ahash_op+0x25/0x60
[   26.153481]  [811dfc86] ? crypto_ahash_final+0x16/0x20
[   26.153481]  [811e3608] gcm_enc_copy_hash+0x28/0x30
[   26.153481]  [811e36fc] crypto_gcm_encrypt+0xec/0x100
[   26.153481]  [811e3610] ? gcm_enc_copy_hash+0x30/0x30
[   26.153481]  [811da875] old_crypt+0xc5/0xe0
[   26.153481]  [811da8cd] old_encrypt+0x1d/0x20
[   26.153481]  [814b688b] ieee80211_aes_gmac+0x21b/0x230
[   26.153481]  [811e3710] ? crypto_gcm_encrypt+0x100/0x100
[   26.153481]  [811e2f10] ? __gcm_hash_final_done+0x60/0x60
[   26.153481]  [814b66a4] ? ieee80211_aes_gmac+0x34/0x230
[   26.153481]  [81498621] 
ieee80211_crypto_aes_gmac_encrypt+0x191/0x1a0
[   26.153481]  [8153b794] ieee80211_tx_h_encrypt+0x67/0x77
[   26.153481]  [814cd496] invoke_tx_handlers+0xe6/0x1b0

johannes

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 7/7] mac80211: Switch to new AEAD interface

2015-05-22 Thread Johannes Berg
On Fri, 2015-05-22 at 16:05 +0800, Herbert Xu wrote:
 On Fri, May 22, 2015 at 09:43:28AM +0200, Johannes Berg wrote:
  
  Oops, sorry, of course - I was running in a VM :)
 
 Thanks!
 
 Does this patch on top help?

Yep, that fixes things.

johannes

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 7/7] mac80211: Switch to new AEAD interface

2015-05-21 Thread Johannes Berg
On Thu, 2015-05-21 at 19:50 +0800, Herbert Xu wrote:
 On Thu, May 21, 2015 at 01:20:49PM +0200, Johannes Berg wrote:
  On Thu, 2015-05-21 at 18:44 +0800, Herbert Xu wrote:
   This patch makes use of the new AEAD interface which uses a single
   SG list instead of separate lists for the AD and plain text.
  
  Looks fine - want me to run any tests on it?
 
 That would be great!
 
 However, they depend on a series which has not been merged into
 cryptodev yet so you'll need to apply the following pathces first:
 
 https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg14270.html

Do you have a branch somewhere with all of that?

johannes

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 7/7] mac80211: Switch to new AEAD interface

2015-05-21 Thread Herbert Xu
On Thu, May 21, 2015 at 01:20:49PM +0200, Johannes Berg wrote:
 On Thu, 2015-05-21 at 18:44 +0800, Herbert Xu wrote:
  This patch makes use of the new AEAD interface which uses a single
  SG list instead of separate lists for the AD and plain text.
 
 Looks fine - want me to run any tests on it?

That would be great!

However, they depend on a series which has not been merged into
cryptodev yet so you'll need to apply the following pathces first:

https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg14270.html

Thanks,
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 7/7] mac80211: Switch to new AEAD interface

2015-05-21 Thread Herbert Xu
This patch makes use of the new AEAD interface which uses a single
SG list instead of separate lists for the AD and plain text.

Signed-off-by: Herbert Xu herb...@gondor.apana.org.au
---

 net/mac80211/aes_ccm.c  |   30 ++
 net/mac80211/aes_gcm.c  |   30 ++
 net/mac80211/aes_gmac.c |   14 +-
 3 files changed, 33 insertions(+), 41 deletions(-)

diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
index 70d53da..42575ef 100644
--- a/net/mac80211/aes_ccm.c
+++ b/net/mac80211/aes_ccm.c
@@ -22,7 +22,7 @@ void ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 
*b_0, u8 *aad,
   u8 *data, size_t data_len, u8 *mic,
   size_t mic_len)
 {
-   struct scatterlist assoc, pt, ct[2];
+   struct scatterlist sg[3];
 
char aead_req_data[sizeof(struct aead_request) +
   crypto_aead_reqsize(tfm)]
@@ -31,15 +31,14 @@ void ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 
*b_0, u8 *aad,
 
memset(aead_req, 0, sizeof(aead_req_data));
 
-   sg_init_one(pt, data, data_len);
-   sg_init_one(assoc, aad[2], be16_to_cpup((__be16 *)aad));
-   sg_init_table(ct, 2);
-   sg_set_buf(ct[0], data, data_len);
-   sg_set_buf(ct[1], mic, mic_len);
+   sg_init_table(sg, 3);
+   sg_set_buf(sg[0], aad[2], be16_to_cpup((__be16 *)aad));
+   sg_set_buf(sg[1], data, data_len);
+   sg_set_buf(sg[2], mic, mic_len);
 
aead_request_set_tfm(aead_req, tfm);
-   aead_request_set_assoc(aead_req, assoc, assoc.length);
-   aead_request_set_crypt(aead_req, pt, ct, data_len, b_0);
+   aead_request_set_crypt(aead_req, sg, sg, data_len, b_0);
+   aead_request_set_ad(aead_req, sg[0].length, 0);
 
crypto_aead_encrypt(aead_req);
 }
@@ -48,7 +47,7 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 
*b_0, u8 *aad,
  u8 *data, size_t data_len, u8 *mic,
  size_t mic_len)
 {
-   struct scatterlist assoc, pt, ct[2];
+   struct scatterlist sg[3];
char aead_req_data[sizeof(struct aead_request) +
   crypto_aead_reqsize(tfm)]
__aligned(__alignof__(struct aead_request));
@@ -59,15 +58,14 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 
*b_0, u8 *aad,
 
memset(aead_req, 0, sizeof(aead_req_data));
 
-   sg_init_one(pt, data, data_len);
-   sg_init_one(assoc, aad[2], be16_to_cpup((__be16 *)aad));
-   sg_init_table(ct, 2);
-   sg_set_buf(ct[0], data, data_len);
-   sg_set_buf(ct[1], mic, mic_len);
+   sg_init_table(sg, 3);
+   sg_set_buf(sg[0], aad[2], be16_to_cpup((__be16 *)aad));
+   sg_set_buf(sg[1], data, data_len);
+   sg_set_buf(sg[2], mic, mic_len);
 
aead_request_set_tfm(aead_req, tfm);
-   aead_request_set_assoc(aead_req, assoc, assoc.length);
-   aead_request_set_crypt(aead_req, ct, pt, data_len + mic_len, b_0);
+   aead_request_set_crypt(aead_req, sg, sg, data_len + mic_len, b_0);
+   aead_request_set_ad(aead_req, sg[0].length, 0);
 
return crypto_aead_decrypt(aead_req);
 }
diff --git a/net/mac80211/aes_gcm.c b/net/mac80211/aes_gcm.c
index b91c9d7..12dcd66 100644
--- a/net/mac80211/aes_gcm.c
+++ b/net/mac80211/aes_gcm.c
@@ -18,7 +18,7 @@
 void ieee80211_aes_gcm_encrypt(struct crypto_aead *tfm, u8 *j_0, u8 *aad,
   u8 *data, size_t data_len, u8 *mic)
 {
-   struct scatterlist assoc, pt, ct[2];
+   struct scatterlist sg[3];
 
char aead_req_data[sizeof(struct aead_request) +
   crypto_aead_reqsize(tfm)]
@@ -27,15 +27,14 @@ void ieee80211_aes_gcm_encrypt(struct crypto_aead *tfm, u8 
*j_0, u8 *aad,
 
memset(aead_req, 0, sizeof(aead_req_data));
 
-   sg_init_one(pt, data, data_len);
-   sg_init_one(assoc, aad[2], be16_to_cpup((__be16 *)aad));
-   sg_init_table(ct, 2);
-   sg_set_buf(ct[0], data, data_len);
-   sg_set_buf(ct[1], mic, IEEE80211_GCMP_MIC_LEN);
+   sg_init_table(sg, 3);
+   sg_set_buf(sg[0], aad[2], be16_to_cpup((__be16 *)aad));
+   sg_set_buf(sg[1], data, data_len);
+   sg_set_buf(sg[2], mic, IEEE80211_GCMP_MIC_LEN);
 
aead_request_set_tfm(aead_req, tfm);
-   aead_request_set_assoc(aead_req, assoc, assoc.length);
-   aead_request_set_crypt(aead_req, pt, ct, data_len, j_0);
+   aead_request_set_crypt(aead_req, sg, sg, data_len, j_0);
+   aead_request_set_ad(aead_req, sg[0].length, 0);
 
crypto_aead_encrypt(aead_req);
 }
@@ -43,7 +42,7 @@ void ieee80211_aes_gcm_encrypt(struct crypto_aead *tfm, u8 
*j_0, u8 *aad,
 int ieee80211_aes_gcm_decrypt(struct crypto_aead *tfm, u8 *j_0, u8 *aad,
  u8 *data, size_t data_len, u8 *mic)
 {
-   struct scatterlist assoc, pt, ct[2];
+   struct scatterlist sg[3];
char 

Re: [PATCH 7/7] mac80211: Switch to new AEAD interface

2015-05-21 Thread Johannes Berg
On Thu, 2015-05-21 at 18:44 +0800, Herbert Xu wrote:
 This patch makes use of the new AEAD interface which uses a single
 SG list instead of separate lists for the AD and plain text.

Looks fine - want me to run any tests on it?

johannes

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 7/7] mac80211: Switch to new AEAD interface

2015-05-21 Thread Herbert Xu
On Thu, May 21, 2015 at 02:17:44PM +0200, Johannes Berg wrote:

 Do you have a branch somewhere with all of that?

OK the prerequisite patches are now in cryptodev.

Thanks,
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html