Re: [PATCH -next] cfg80211: fix possible memory leak in cfg80211_iter_combinations()
On Mon, 2016-10-17 at 15:25 +, Wei Yongjun wrote: > From: Wei Yongjun > > 'limits' is malloced in cfg80211_iter_combinations() and should be > freed > before leaving from the error handling cases, otherwise it will cause > memory leak. Yep, thanks; applied. johannes
Re: [PATCH 1/2] ath10k: add per peer htt tx stats support for 10.4
On 2016-10-12 10:29, Valo, Kalle wrote:
writes:
From: Anilkumar Kolli
Per peer tx stats are part of 'HTT_10_4_T2H_MSG_TYPE_PEER_STATS'
event, Firmware sends one HTT event for every four PPDUs.
HTT payload has success pkts/bytes, failed pkts/bytes, retry
pkts/bytes and rate info per ppdu.
Peer stats are enabled through 'WMI_SERVICE_PEER_STATS',
which are nowadays enabled by default.
Parse peer stats and update the tx rate information per STA.
tx rate, Peer stats are tested on QCA4019 with Firmware version
10.4-3.2.1-00028.
Signed-off-by: Anilkumar Kolli
This and patch 2 add few new warnings:
drivers/net/wireless/ath/ath10k/htt_rx.c: In function
'ath10k_htt_fetch_peer_stats':
drivers/net/wireless/ath/ath10k/htt_rx.c:2279:3: warning: too many
arguments for format [-Wformat-extra-args]
drivers/net/wireless/ath/ath10k/htt_rx.c:2285:17: warning: incorrect
type in assignment (different base types)
drivers/net/wireless/ath/ath10k/htt_rx.c:2285:17:expected unsigned
int [unsigned] [usertype] peer_id
drivers/net/wireless/ath/ath10k/htt_rx.c:2285:17:got restricted
__le16 [usertype] peer_id
drivers/net/wireless/ath/ath10k/debugfs_sta.c:84: space required
before the open parenthesis '('
I will fix and send V2.
Thanks,
Anil.
[PATCH 19/28] brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap
A bugfix added a sanity check around the assignment and use of the
'is_11d' variable, which looks correct to me, but as the function is
rather complex already, this confuses the compiler to the point where
it can no longer figure out if the variable is always initialized
correctly:
brcm80211/brcmfmac/cfg80211.c: In function ‘brcmf_cfg80211_start_ap’:
brcm80211/brcmfmac/cfg80211.c:4586:10: error: ‘is_11d’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
This adds an initialization for the newly introduced case in which
the variable should not really be used, in order to make the warning
go away.
Fixes: b3589dfe0212 ("brcmfmac: ignore 11d configuration errors")
Cc: Hante Meuleman
Cc: Arend van Spriel
Cc: Kalle Valo
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index b777e1b..78d9966 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -4516,7 +4516,7 @@ brcmf_cfg80211_start_ap(struct wiphy *wiphy, struct
net_device *ndev,
/* store current 11d setting */
if (brcmf_fil_cmd_int_get(ifp, BRCMF_C_GET_REGULATORY,
&ifp->vif->is_11d)) {
- supports_11d = false;
+ is_11d = supports_11d = false;
} else {
country_ie = brcmf_parse_tlvs((u8 *)settings->beacon.tail,
settings->beacon.tail_len,
--
2.9.0
Re: [PATCH] mac80211_hwsim: suggest nl80211 instead of wext driver in documentation
On Mon, Oct 17, 2016 at 11:39:04AM +0200, Johannes Berg wrote:
> On Mon, 2016-10-17 at 00:39 +0200, Linus Lüssing wrote:
> > For mac80211_hwsim interfaces, suggest to use wpa_supplicant with the
> > more modern, netlink based driver instead of wext.
>
> Makes sense, applied.
>
> > Actually, I wasn't even able to make a connection with the
> > configuration
> > files and information provided in
> > Documentation/networking/mac80211_hwsim/{README,hostapd.conf/wpa_supp
> > licant.conf}
> >
> This less so, we even have a few test cases we run regularly, but I
> don't know. Maybe there's something special in those configuration
> files that we don't test for otherwise.
I investigated a little further and the problem is probably that
I'm running a minimal Linux kernel which was compiled without
CONFIG_CFG80211_WEXT :-).
Anyways, thanks for applying the patch!
Regards, Linus
Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption
On 17 October 2016 at 18:08, Andy Lutomirski wrote: > On Mon, Oct 17, 2016 at 12:37 AM, Ard Biesheuvel > wrote: >> On 17 October 2016 at 08:28, Johannes Berg wrote: >>> On Sat, 2016-10-15 at 18:16 +0100, Ard Biesheuvel wrote: The CCM code goes out of its way to perform the CTR encryption of the MAC using the subordinate CTR driver. To this end, it tweaks the input and output scatterlists so the aead_req 'odata' and/or 'auth_tag' fields [which may live on the stack] are prepended to the CTR payload. This involves calling sg_set_buf() on addresses which are not direct mapped, which is not supported. >>> Since the calculation of the MAC keystream involves a single call into the cipher, to which we have a handle already given that the CBC-MAC calculation uses it as well, just calculate the MAC keystream directly, and record it in the aead_req private context so we can apply it to the MAC in cypto_ccm_auth_mac(). This greatly simplifies the scatterlist manipulation, and no longer requires scatterlists to refer to buffers that may live on the stack. >>> >>> No objection from me, Herbert? >>> >>> I'm getting a bit nervous though - I'd rather have any fix first so >>> people get things working again - so maybe I'll apply your other patch >>> and mine first, and then we can replace yours by this later. >>> >> >> Could we get a statement first whether it is supported to allocate >> aead_req (and other crypto req structures) on the stack? If not, then >> we have our work cut out for us. But if it is, I'd rather we didn't >> apply the kzalloc/kfree patch, since it is just a workaround for the >> broken generic CCM driver, for which a fix is already available. > > I'm not a crypto person, but I don't see why not. There's even a > helper called SKCIPHER_REQUEST_ON_STACK. :) The only problem I know > of is pointing a scatterlist at the stack, which is bad for much the > same reason as doing real DMA from the stack. Excellent point! So the CCM code was an easy fix, although the RFC4309 part is still broken: It does """ scatterwalk_map_and_copy(iv + 16, req->src, 0, req->assoclen - 8, 0); ... sg_set_buf(rctx->src, iv + 16, req->assoclen - 8); sg = scatterwalk_ffwd(rctx->src + 1, req->src, req->assoclen); """ which essentially just hides the last 8 bytes of associated data from the inner CCM transform. So we'd need to rewrite this part to create a new scatterlist that omits those 8 bytes instead of just replacing the first sg entry and point it to another buffer entirely (and copy the data into it) The GCM code is much more complicated, and does not easily allow the offending sg_set_buf() calls to be turned into something that only involves direct mapped memory references. I haven't looked at anything else. Annoyingly, all this complication with scatterlists etc is for doing asynchronous crypto via DMA capable crypto accelerators, and the networking code (ipsec as well as mac80211, afaik) only allow synchronous in the first place, given that they execute in softirq context.
Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption
On Mon, Oct 17, 2016 at 12:37 AM, Ard Biesheuvel wrote: > On 17 October 2016 at 08:28, Johannes Berg wrote: >> On Sat, 2016-10-15 at 18:16 +0100, Ard Biesheuvel wrote: >>> The CCM code goes out of its way to perform the CTR encryption of the >>> MAC using the subordinate CTR driver. To this end, it tweaks the >>> input and output scatterlists so the aead_req 'odata' and/or >>> 'auth_tag' fields [which may live on the stack] are prepended to the >>> CTR payload. This involves calling sg_set_buf() on addresses which >>> are not direct mapped, which is not supported. >> >>> Since the calculation of the MAC keystream involves a single call >>> into the cipher, to which we have a handle already given that the >>> CBC-MAC calculation uses it as well, just calculate the MAC keystream >>> directly, and record it in the aead_req private context so we can >>> apply it to the MAC in cypto_ccm_auth_mac(). This greatly simplifies >>> the scatterlist manipulation, and no longer requires scatterlists to >>> refer to buffers that may live on the stack. >> >> No objection from me, Herbert? >> >> I'm getting a bit nervous though - I'd rather have any fix first so >> people get things working again - so maybe I'll apply your other patch >> and mine first, and then we can replace yours by this later. >> > > Could we get a statement first whether it is supported to allocate > aead_req (and other crypto req structures) on the stack? If not, then > we have our work cut out for us. But if it is, I'd rather we didn't > apply the kzalloc/kfree patch, since it is just a workaround for the > broken generic CCM driver, for which a fix is already available. I'm not a crypto person, but I don't see why not. There's even a helper called SKCIPHER_REQUEST_ON_STACK. :) The only problem I know of is pointing a scatterlist at the stack, which is bad for much the same reason as doing real DMA from the stack.
[PATCH -next] cfg80211: fix possible memory leak in cfg80211_iter_combinations()
From: Wei Yongjun
'limits' is malloced in cfg80211_iter_combinations() and should be freed
before leaving from the error handling cases, otherwise it will cause
memory leak.
Fixes: 0c317a02ca98 ("cfg80211: support virtual interfaces with different
beacon intervals")
Signed-off-by: Wei Yongjun
---
net/wireless/util.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/wireless/util.c b/net/wireless/util.c
index dd545ff..e36dbae 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1672,8 +1672,10 @@ int cfg80211_iter_combinations(struct wiphy *wiphy,
if (params->beacon_int_gcd) {
if (c->beacon_int_min_gcd &&
- params->beacon_int_gcd < c->beacon_int_min_gcd)
+ params->beacon_int_gcd < c->beacon_int_min_gcd) {
+ kfree(limits);
return -EINVAL;
+ }
if (!c->beacon_int_min_gcd &&
params->beacon_int_different)
goto cont;
Re: [PATCH v4] mac80211: move struct aead_req off the stack
On Mon, 2016-10-17 at 15:05 +0100, Ard Biesheuvel wrote: > From: Johannes Berg That really ought to have been you - I think I may have lost that by accident. I'll change it. > In addition, take care not to put any of our own stack allocations > into > scatterlists. This involves reserving some extra room when allocating > the > aead_request structures, and referring to those allocations in the > scatter- > lists (while copying the data from/to the stack before/after the > crypto > operation, as appropriate) I removed the "to the stack after" language, since that doesn't actually occur :) > --- a/net/mac80211/aes_cmac.h > +++ b/net/mac80211/aes_cmac.h > @@ -11,6 +11,8 @@ > > #include > > +#define CMAC_AAD_LEN 20 This part (and aes_cmac.c changes) shouldn't have been there, but that was my mistake - removed. With that, I've applied this. Will send it to davem tomorrow. johannes
[PATCH v4] mac80211: move struct aead_req off the stack
From: Johannes Berg
Some crypto implementations (such as the generic CCM wrapper in crypto/)
use scatterlists to map fields of private data in their struct aead_req.
This means these data structures cannot live in the vmalloc area, which
means that they cannot live on the stack (with CONFIG_VMAP_STACK.)
This currently occurs only with the generic software implementation, but
the private data and usage is implementation specific, so move the whole
data structures off the stack into heap by allocating every time we need
to use them.
In addition, take care not to put any of our own stack allocations into
scatterlists. This involves reserving some extra room when allocating the
aead_request structures, and referring to those allocations in the scatter-
lists (while copying the data from/to the stack before/after the crypto
operation, as appropriate)
Signed-off-by: Johannes Berg
Signed-off-by: Ard Biesheuvel
---
net/mac80211/aes_ccm.c | 46 +---
net/mac80211/aes_ccm.h | 8 ++--
net/mac80211/aes_cmac.c | 5 +--
net/mac80211/aes_cmac.h | 2 +
net/mac80211/aes_gcm.c | 43 +++---
net/mac80211/aes_gcm.h | 6 ++-
net/mac80211/aes_gmac.c | 26 +--
net/mac80211/aes_gmac.h | 4 ++
net/mac80211/wpa.c | 22 --
9 files changed, 97 insertions(+), 65 deletions(-)
diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
index 7663c28ba353..a4e0d59a40dd 100644
--- a/net/mac80211/aes_ccm.c
+++ b/net/mac80211/aes_ccm.c
@@ -18,21 +18,24 @@
#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)
+int 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 sg[3];
+ struct aead_request *aead_req;
+ int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(tfm);
+ u8 *__aad;
- 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;
+ aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
+ if (!aead_req)
+ return -ENOMEM;
- memset(aead_req, 0, sizeof(aead_req_data));
+ __aad = (u8 *)aead_req + reqsize;
+ memcpy(__aad, aad, CCM_AAD_LEN);
sg_init_table(sg, 3);
- sg_set_buf(&sg[0], &aad[2], be16_to_cpup((__be16 *)aad));
+ 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);
@@ -41,6 +44,9 @@ void ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8
*b_0, u8 *aad,
aead_request_set_ad(aead_req, sg[0].length);
crypto_aead_encrypt(aead_req);
+ kzfree(aead_req);
+
+ return 0;
}
int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
@@ -48,18 +54,23 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8
*b_0, u8 *aad,
size_t mic_len)
{
struct scatterlist sg[3];
- 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;
+ struct aead_request *aead_req;
+ int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(tfm);
+ u8 *__aad;
+ int err;
if (data_len == 0)
return -EINVAL;
- memset(aead_req, 0, sizeof(aead_req_data));
+ aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
+ if (!aead_req)
+ return -ENOMEM;
+
+ __aad = (u8 *)aead_req + reqsize;
+ memcpy(__aad, aad, CCM_AAD_LEN);
sg_init_table(sg, 3);
- sg_set_buf(&sg[0], &aad[2], be16_to_cpup((__be16 *)aad));
+ 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);
@@ -67,7 +78,10 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8
*b_0, u8 *aad,
aead_request_set_crypt(aead_req, sg, sg, data_len + mic_len, b_0);
aead_request_set_ad(aead_req, sg[0].length);
- return crypto_aead_decrypt(aead_req);
+ err = crypto_aead_decrypt(aead_req);
+ kzfree(aead_req);
+
+ return err;
}
struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[],
diff --git a/net/mac80211/aes_ccm.h b/net/mac80211/aes_ccm.h
index 6a73d1e4d186..fcd3254c5cf0 100644
--- a/net/mac80211/aes_ccm.h
+++ b/net/mac80211/aes_ccm.h
@@ -12,12 +12,14 @@
#include
+#define CCM_AAD_LEN32
+
struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u
Re: [PATCH v4] mac80211: move extra crypto data off the stack
> Indeed. And it keeps the clutter inside the aes_xxx.c files, which > could easily be updated in the future to use some auxdata feature if > it ever materializes. > > I think it would help this code, but also the ESP code you pointed > out, to have some kind of 'ordered synchronous' CRYPTO_xxx flag, > where the crypto API could manage the kmem cache and percpu pointers > to allocations. Yeah, could be useful to have that more generally. > This goes well beyond what we can do as a fix, though, so we need an > intermediate solution in any case. > > Shall I propose the patch? I assume you mean a mac80211 patch - sure, I'll take that instead of the two I have now. johannes
Re: [PATCH v4] mac80211: move extra crypto data off the stack
On 17 October 2016 at 14:16, Johannes Berg wrote: > On Mon, 2016-10-17 at 14:06 +0100, Ard Biesheuvel wrote: >> >> Actually, while I think it will be worthwhile going forward to >> implement such an 'auxiliary data' feature in a generic way, I still >> think we should address the issue at hand without too much >> complication. >> >> If we pedal back to the version of 'mac80211: move struct aead_req >> off the stack' that uses kzalloc() instead of aead_request_alloc(), >> we can simply add some space for aad[] and/or zero[], and get rid of >> the kmem cache entirely. >> >> If you're past this point already, i won't bother but otherwise I can >> rework 'mac80211: move struct aead_req off the stack' so that the >> other patch is no longer required (and IIRC, this is actually >> something you proposed yourself a couple of iterations ago?) > > Yes, I did consider that. > > It makes some sense, and I guess the extra memcpy() would be cheaper > than the extra alloc? > > I'd happily use that instead of the combination of my two patches. The > aead_request_alloc() is just a simple inline anyway, so no real problem > not using it. > Indeed. And it keeps the clutter inside the aes_xxx.c files, which could easily be updated in the future to use some auxdata feature if it ever materializes. I think it would help this code, but also the ESP code you pointed out, to have some kind of 'ordered synchronous' CRYPTO_xxx flag, where the crypto API could manage the kmem cache and percpu pointers to allocations. This goes well beyond what we can do as a fix, though, so we need an intermediate solution in any case. Shall I propose the patch?
Re: [PATCH v4] mac80211: move extra crypto data off the stack
On Mon, 2016-10-17 at 14:06 +0100, Ard Biesheuvel wrote: > > Actually, while I think it will be worthwhile going forward to > implement such an 'auxiliary data' feature in a generic way, I still > think we should address the issue at hand without too much > complication. > > If we pedal back to the version of 'mac80211: move struct aead_req > off the stack' that uses kzalloc() instead of aead_request_alloc(), > we can simply add some space for aad[] and/or zero[], and get rid of > the kmem cache entirely. > > If you're past this point already, i won't bother but otherwise I can > rework 'mac80211: move struct aead_req off the stack' so that the > other patch is no longer required (and IIRC, this is actually > something you proposed yourself a couple of iterations ago?) Yes, I did consider that. It makes some sense, and I guess the extra memcpy() would be cheaper than the extra alloc? I'd happily use that instead of the combination of my two patches. The aead_request_alloc() is just a simple inline anyway, so no real problem not using it. johannes
Re: [PATCH v4] mac80211: move extra crypto data off the stack
On 17 October 2016 at 11:02, Ard Biesheuvel wrote: > > >> On 17 Oct 2016, at 10:54, Johannes Berg wrote: >> >> Well, if your other patch to make it OK to be on-stack would be applied instead, this wouldn't make much sense either :) >>> >>> Yes but that one only fixes ccm not gcm >> >> Yes, but we can do the same for GCM, no? >> > > No, not really. ccm happens to use aes with the same key for the mac and the > encryption. gcm uses an another algo entirely for the mac > In this particular patch, we could reduce the size of the struct, but I don't actually think it'll make a difference to go from 48 to 36 bytes, given alignment etc., so I think I'll just leave it as is. >>> >>> I understand you are in a hurry, but this is unlikely to be the only >>> such issue. I will propose an 'auxdata' feature for the crypto api >>> that can be used here, but also for any other occurrence where client >>> data assoiciated with the request can no longer be allocated on the >>> stack >> >> No objections. I'll merge this anyway today I think, reverting is easy >> later. >> > > ok fair enough Actually, while I think it will be worthwhile going forward to implement such an 'auxiliary data' feature in a generic way, I still think we should address the issue at hand without too much complication. If we pedal back to the version of 'mac80211: move struct aead_req off the stack' that uses kzalloc() instead of aead_request_alloc(), we can simply add some space for aad[] and/or zero[], and get rid of the kmem cache entirely. If you're past this point already, i won't bother but otherwise I can rework 'mac80211: move struct aead_req off the stack' so that the other patch is no longer required (and IIRC, this is actually something you proposed yourself a couple of iterations ago?)
Re: [Projekt-wlan] [PATCHv5 2/2] mac80211: fix A-MSDU outer SA/DA
On Mon, 2016-10-17 at 12:29 +0200, michael-dev wrote: > > ether_addr_copy requires both arguments to be __aligned(2) according > to > include/linux/etherdevice.h. > bssid might be sdata->u.mgd.bssid, which is bssid in struct > ieee80211_if_managed, but neither sdata->u, sdata->u.mgd nor > sdata->u.mgd.bssid seem to be declared as __aligned(2).So > ether_addr_copy should not be used. They are in fact aligned today, given that they occur after a pointer. However, I did add the __aligned(2) annotation to make that plenty clear for the future. johannes
Re: [Projekt-wlan] [PATCHv5 2/2] mac80211: fix A-MSDU outer SA/DA
Am 17.10.2016 11:44, schrieb Johannes Berg: + if (bssid && ieee80211_has_fromds(hdr->frame_control)) + memcpy(h_80211_src, bssid, ETH_ALEN); + + if (bssid && ieee80211_has_tods(hdr->frame_control)) + memcpy(h_80211_dst, bssid, ETH_ALEN); but I also changed these to ether_addr_copy() ether_addr_copy requires both arguments to be __aligned(2) according to include/linux/etherdevice.h. bssid might be sdata->u.mgd.bssid, which is bssid in struct ieee80211_if_managed, but neither sdata->u, sdata->u.mgd nor sdata->u.mgd.bssid seem to be declared as __aligned(2). So ether_addr_copy should not be used. What am I missing? Regards, M. Braun
Re: [PATCH v4] mac80211: move extra crypto data off the stack
> On 17 Oct 2016, at 10:54, Johannes Berg wrote: > > >>> Well, if your other patch to make it OK to be on-stack would be >>> applied instead, this wouldn't make much sense either :) >>> >> >> Yes but that one only fixes ccm not gcm > > Yes, but we can do the same for GCM, no? > No, not really. ccm happens to use aes with the same key for the mac and the encryption. gcm uses an another algo entirely for the mac >>> In this particular patch, we could reduce the size of the struct, >>> but I >>> don't actually think it'll make a difference to go from 48 to 36 >>> bytes, >>> given alignment etc., so I think I'll just leave it as is. >>> >> >> I understand you are in a hurry, but this is unlikely to be the only >> such issue. I will propose an 'auxdata' feature for the crypto api >> that can be used here, but also for any other occurrence where client >> data assoiciated with the request can no longer be allocated on the >> stack > > No objections. I'll merge this anyway today I think, reverting is easy > later. > ok fair enough
Re: [PATCH v4] mac80211: move extra crypto data off the stack
> > Well, if your other patch to make it OK to be on-stack would be > > applied instead, this wouldn't make much sense either :) > > > > Yes but that one only fixes ccm not gcm Yes, but we can do the same for GCM, no? > > In this particular patch, we could reduce the size of the struct, > > but I > > don't actually think it'll make a difference to go from 48 to 36 > > bytes, > > given alignment etc., so I think I'll just leave it as is. > > > > I understand you are in a hurry, but this is unlikely to be the only > such issue. I will propose an 'auxdata' feature for the crypto api > that can be used here, but also for any other occurrence where client > data assoiciated with the request can no longer be allocated on the > stack No objections. I'll merge this anyway today I think, reverting is easy later. johannes
Re: [PATCH v4] mac80211: move extra crypto data off the stack
> On 17 Oct 2016, at 10:35, Johannes Berg wrote: > >> On Mon, 2016-10-17 at 10:30 +0100, Ard Biesheuvel wrote: >> >> Yes. But as I replied, setting the req size is not supported atm, >> although it is reasonable to demand a way to allocate additional data >> in the request specifically for this issue. So let's proceed with the >> aead_request_alloc/free patch, but I would like to propose something >> on the API side to address this particular issue > > Well, if your other patch to make it OK to be on-stack would be applied > instead, this wouldn't make much sense either :) > Yes but that one only fixes ccm not gcm > In this particular patch, we could reduce the size of the struct, but I > don't actually think it'll make a difference to go from 48 to 36 bytes, > given alignment etc., so I think I'll just leave it as is. > I understand you are in a hurry, but this is unlikely to be the only such issue. I will propose an 'auxdata' feature for the crypto api that can be used here, but also for any other occurrence where client data assoiciated with the request can no longer be allocated on the stack
Re: [PATCH v4] mac80211: move extra crypto data off the stack
> On 17 Oct 2016, at 10:35, Johannes Berg wrote: > >> On Mon, 2016-10-17 at 10:30 +0100, Ard Biesheuvel wrote: >> >> Yes. But as I replied, setting the req size is not supported atm, >> although it is reasonable to demand a way to allocate additional data >> in the request specifically for this issue. So let's proceed with the >> aead_request_alloc/free patch, but I would like to propose something >> on the API side to address this particular issue > > Well, if your other patch to make it OK to be on-stack would be applied > instead, this wouldn't make much sense either :) > > In this particular patch, we could reduce the size of the struct, but I > don't actually think it'll make a difference to go from 48 to 36 bytes, > given alignment etc., so I think I'll just leave it as is. > > johannes
Re: [PATCHv5 2/2] mac80211: fix A-MSDU outer SA/DA
On Sat, 2016-10-15 at 13:28 +0200, Michael Braun wrote: > According to IEEE 802.11-2012 section 8.3.2 table 8-19, the outer > SA/DA > of A-MSDU frames need to be changed depending on FromDS/ToDS values. Also applied, > + if (bssid && ieee80211_has_fromds(hdr->frame_control)) > + memcpy(h_80211_src, bssid, ETH_ALEN); > + > + if (bssid && ieee80211_has_tods(hdr->frame_control)) > + memcpy(h_80211_dst, bssid, ETH_ALEN); but I also changed these to ether_addr_copy() johannes
Re: [PATCHv5 1/2] mac80211: avoid extra memcpy in A-MSDU head creation
On Sat, 2016-10-15 at 13:28 +0200, Michael Braun wrote: > Signed-off-by: Michael Braun > Applied. johannes
Re: [PATCH] mac80211_hwsim: suggest nl80211 instead of wext driver in documentation
On Mon, 2016-10-17 at 00:39 +0200, Linus Lüssing wrote:
> For mac80211_hwsim interfaces, suggest to use wpa_supplicant with the
> more modern, netlink based driver instead of wext.
Makes sense, applied.
> Actually, I wasn't even able to make a connection with the
> configuration
> files and information provided in
> Documentation/networking/mac80211_hwsim/{README,hostapd.conf/wpa_supp
> licant.conf}
>
This less so, we even have a few test cases we run regularly, but I
don't know. Maybe there's something special in those configuration
files that we don't test for otherwise.
johannes
Re: [PATCH v4] mac80211: move extra crypto data off the stack
On Mon, 2016-10-17 at 10:30 +0100, Ard Biesheuvel wrote: > Yes. But as I replied, setting the req size is not supported atm, > although it is reasonable to demand a way to allocate additional data > in the request specifically for this issue. So let's proceed with the > aead_request_alloc/free patch, but I would like to propose something > on the API side to address this particular issue Well, if your other patch to make it OK to be on-stack would be applied instead, this wouldn't make much sense either :) In this particular patch, we could reduce the size of the struct, but I don't actually think it'll make a difference to go from 48 to 36 bytes, given alignment etc., so I think I'll just leave it as is. johannes
Re: [PATCH v4] mac80211: move extra crypto data off the stack
On 17 October 2016 at 10:23, Johannes Berg wrote: > >> Apologies for going back and forth on this, but it appears there may >> be another way to deal with this. >> >> First of all, we only need this handling for the authenticated data, > > Are you sure b_0/j_0 aren't needed? We pass those > to aead_request_set_crypt(), and I wasn't sure what that really did > internally, perhaps like the internal data. > They are the IV[], which is a fixed length parameter of the algorithm. In contrast, the AAD[] could be of arbitrary length (from the POV of the crypto API) so it uses scatterlists. > Testing with that on the stack does seem to work, in fact. > > Surely we need zero for GMAC though, since we also put that into the sg > list. Thus for GMAC we definitely need 20+16 bytes, and since I round > up to a cacheline (at least on SMP) it doesn't really matter that we > could get 36 instead of the 48 I have now. > >> and only for CCM and GCM, not CMAC (which does not use scatterlists >> at all, it simply calls the AES cipher directly) > > I didn't modify CMAC, I think, only GMAC, which also uses scatterlists. > Ah ok, I misread the patch. >> So that leaves a fixed 20 bytes for GCM and fixed 32 bytes for CCM, > > and 36 for GMAC :) Yes. But as I replied, setting the req size is not supported atm, although it is reasonable to demand a way to allocate additional data in the request specifically for this issue. So let's proceed with the aead_request_alloc/free patch, but I would like to propose something on the API side to address this particular issue
Re: [PATCH v4] mac80211: move extra crypto data off the stack
> Apologies for going back and forth on this, but it appears there may > be another way to deal with this. > > First of all, we only need this handling for the authenticated data, Are you sure b_0/j_0 aren't needed? We pass those to aead_request_set_crypt(), and I wasn't sure what that really did internally, perhaps like the internal data. Testing with that on the stack does seem to work, in fact. Surely we need zero for GMAC though, since we also put that into the sg list. Thus for GMAC we definitely need 20+16 bytes, and since I round up to a cacheline (at least on SMP) it doesn't really matter that we could get 36 instead of the 48 I have now. > and only for CCM and GCM, not CMAC (which does not use scatterlists > at all, it simply calls the AES cipher directly) I didn't modify CMAC, I think, only GMAC, which also uses scatterlists. > So that leaves a fixed 20 bytes for GCM and fixed 32 bytes for CCM, and 36 for GMAC :) johannes
Re: [PATCH v4] mac80211: move extra crypto data off the stack
On 17 October 2016 at 10:14, Ard Biesheuvel wrote:
> On 17 October 2016 at 09:33, Johannes Berg wrote:
>> From: Johannes Berg
>>
>> As the stack can (on x86-64) now be virtually mapped rather than
>> using "normal" kernel memory, Sergey noticed mac80211 isn't using
>> the SG APIs correctly by putting on-stack buffers into SG tables.
>> This leads to kernel crashes.
>>
>> Fix this by allocating the extra fields dynamically on the fly as
>> needed, using a kmem cache.
>>
>> I used per-CPU memory in a previous iteration of this patch, but
>> Ard Biesheuvel pointed out that was also vmalloc'ed on some
>> architectures.
>>
>> Reported-by: Sergey Senozhatsky
>> Signed-off-by: Johannes Berg
>
> Apologies for going back and forth on this, but it appears there may
> be another way to deal with this.
>
> First of all, we only need this handling for the authenticated data,
> and only for CCM and GCM, not CMAC (which does not use scatterlists at
> all, it simply calls the AES cipher directly)
>
> So that leaves a fixed 20 bytes for GCM and fixed 32 bytes for CCM,
> which we could allocate along with the AEAD request, e..g.,
>
> """
> diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
> index 8e898a6e8de8..c0c33e6ad94e 100644
> --- a/net/mac80211/aes_ccm.c
> +++ b/net/mac80211/aes_ccm.c
> @@ -24,13 +24,17 @@ int ieee80211_aes_ccm_encrypt(struct crypto_aead
> *tfm, u8 *b_0, u8 *aad,
> {
> struct scatterlist sg[3];
> struct aead_request *aead_req;
> + u8 *__aad;
>
> aead_req = aead_request_alloc(tfm, GFP_ATOMIC);
> if (!aead_req)
> return -ENOMEM;
>
> + __aad = (u8 *)aead_req + crypto_aead_reqsize(tfm);
> + memcpy(__aad, aad, 2 * AES_BLOCK_SIZE);
> +
> sg_init_table(sg, 3);
> - sg_set_buf(&sg[0], &aad[2], be16_to_cpup((__be16 *)aad));
> + 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);
>
> @@ -49,6 +53,7 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead
> *tfm, u8 *b_0, u8 *aad,
> {
> struct scatterlist sg[3];
> struct aead_request *aead_req;
> + u8 *__aad;
> int err;
>
> if (data_len == 0)
> @@ -58,8 +63,11 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead
> *tfm, u8 *b_0, u8 *aad,
> if (!aead_req)
> return -ENOMEM;
>
> + __aad = (u8 *)aead_req + crypto_aead_reqsize(tfm);
> + memcpy(__aad, aad, 2 * AES_BLOCK_SIZE);
> +
> sg_init_table(sg, 3);
> - sg_set_buf(&sg[0], &aad[2], be16_to_cpup((__be16 *)aad));
> + 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);
>
> @@ -90,6 +98,8 @@ struct crypto_aead
> *ieee80211_aes_key_setup_encrypt(const u8 key[],
> if (err)
> goto free_aead;
>
> + crypto_aead_set_reqsize(tfm,
> + crypto_aead_reqsize(tfm) + 2 *
> AES_BLOCK_SIZE));
> return tfm;
>
Darn, it seems crypto_aead_set_reqsize() is internal to the crypto API ... :-(
Re: [PATCH v4] mac80211: move extra crypto data off the stack
On 17 October 2016 at 09:33, Johannes Berg wrote:
> From: Johannes Berg
>
> As the stack can (on x86-64) now be virtually mapped rather than
> using "normal" kernel memory, Sergey noticed mac80211 isn't using
> the SG APIs correctly by putting on-stack buffers into SG tables.
> This leads to kernel crashes.
>
> Fix this by allocating the extra fields dynamically on the fly as
> needed, using a kmem cache.
>
> I used per-CPU memory in a previous iteration of this patch, but
> Ard Biesheuvel pointed out that was also vmalloc'ed on some
> architectures.
>
> Reported-by: Sergey Senozhatsky
> Signed-off-by: Johannes Berg
Apologies for going back and forth on this, but it appears there may
be another way to deal with this.
First of all, we only need this handling for the authenticated data,
and only for CCM and GCM, not CMAC (which does not use scatterlists at
all, it simply calls the AES cipher directly)
So that leaves a fixed 20 bytes for GCM and fixed 32 bytes for CCM,
which we could allocate along with the AEAD request, e..g.,
"""
diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
index 8e898a6e8de8..c0c33e6ad94e 100644
--- a/net/mac80211/aes_ccm.c
+++ b/net/mac80211/aes_ccm.c
@@ -24,13 +24,17 @@ int ieee80211_aes_ccm_encrypt(struct crypto_aead
*tfm, u8 *b_0, u8 *aad,
{
struct scatterlist sg[3];
struct aead_request *aead_req;
+ u8 *__aad;
aead_req = aead_request_alloc(tfm, GFP_ATOMIC);
if (!aead_req)
return -ENOMEM;
+ __aad = (u8 *)aead_req + crypto_aead_reqsize(tfm);
+ memcpy(__aad, aad, 2 * AES_BLOCK_SIZE);
+
sg_init_table(sg, 3);
- sg_set_buf(&sg[0], &aad[2], be16_to_cpup((__be16 *)aad));
+ 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);
@@ -49,6 +53,7 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead
*tfm, u8 *b_0, u8 *aad,
{
struct scatterlist sg[3];
struct aead_request *aead_req;
+ u8 *__aad;
int err;
if (data_len == 0)
@@ -58,8 +63,11 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead
*tfm, u8 *b_0, u8 *aad,
if (!aead_req)
return -ENOMEM;
+ __aad = (u8 *)aead_req + crypto_aead_reqsize(tfm);
+ memcpy(__aad, aad, 2 * AES_BLOCK_SIZE);
+
sg_init_table(sg, 3);
- sg_set_buf(&sg[0], &aad[2], be16_to_cpup((__be16 *)aad));
+ 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);
@@ -90,6 +98,8 @@ struct crypto_aead
*ieee80211_aes_key_setup_encrypt(const u8 key[],
if (err)
goto free_aead;
+ crypto_aead_set_reqsize(tfm,
+ crypto_aead_reqsize(tfm) + 2 * AES_BLOCK_SIZE));
return tfm;
free_aead:
"""
[PATCH v4] mac80211: move extra crypto data off the stack
From: Johannes Berg
As the stack can (on x86-64) now be virtually mapped rather than
using "normal" kernel memory, Sergey noticed mac80211 isn't using
the SG APIs correctly by putting on-stack buffers into SG tables.
This leads to kernel crashes.
Fix this by allocating the extra fields dynamically on the fly as
needed, using a kmem cache.
I used per-CPU memory in a previous iteration of this patch, but
Ard Biesheuvel pointed out that was also vmalloc'ed on some
architectures.
Reported-by: Sergey Senozhatsky
Signed-off-by: Johannes Berg
---
net/mac80211/aes_cmac.c| 5 +-
net/mac80211/aes_cmac.h| 2 +
net/mac80211/aes_gmac.c| 9 ++-
net/mac80211/aes_gmac.h| 5 +-
net/mac80211/ieee80211_i.h | 7 ++
net/mac80211/main.c| 8 +++
net/mac80211/wpa.c | 173 -
7 files changed, 166 insertions(+), 43 deletions(-)
diff --git a/net/mac80211/aes_cmac.c b/net/mac80211/aes_cmac.c
index bdf0790d89cc..ebb8c2dc9928 100644
--- a/net/mac80211/aes_cmac.c
+++ b/net/mac80211/aes_cmac.c
@@ -20,7 +20,6 @@
#define CMAC_TLEN 8 /* CMAC TLen = 64 bits (8 octets) */
#define CMAC_TLEN_256 16 /* CMAC TLen = 128 bits (16 octets) */
-#define AAD_LEN 20
static void gf_mulx(u8 *pad)
@@ -101,7 +100,7 @@ void ieee80211_aes_cmac(struct crypto_cipher *tfm, const u8
*aad,
memset(zero, 0, CMAC_TLEN);
addr[0] = aad;
- len[0] = AAD_LEN;
+ len[0] = CMAC_AAD_LEN;
addr[1] = data;
len[1] = data_len - CMAC_TLEN;
addr[2] = zero;
@@ -119,7 +118,7 @@ void ieee80211_aes_cmac_256(struct crypto_cipher *tfm,
const u8 *aad,
memset(zero, 0, CMAC_TLEN_256);
addr[0] = aad;
- len[0] = AAD_LEN;
+ len[0] = CMAC_AAD_LEN;
addr[1] = data;
len[1] = data_len - CMAC_TLEN_256;
addr[2] = zero;
diff --git a/net/mac80211/aes_cmac.h b/net/mac80211/aes_cmac.h
index 3702041f44fd..6645f8963278 100644
--- a/net/mac80211/aes_cmac.h
+++ b/net/mac80211/aes_cmac.h
@@ -11,6 +11,8 @@
#include
+#define CMAC_AAD_LEN 20
+
struct crypto_cipher *ieee80211_aes_cmac_key_setup(const u8 key[],
size_t key_len);
void ieee80211_aes_cmac(struct crypto_cipher *tfm, const u8 *aad,
diff --git a/net/mac80211/aes_gmac.c b/net/mac80211/aes_gmac.c
index 6951af9715c0..86892e2e3c8c 100644
--- a/net/mac80211/aes_gmac.c
+++ b/net/mac80211/aes_gmac.c
@@ -19,13 +19,12 @@
#define GMAC_MIC_LEN 16
#define GMAC_NONCE_LEN 12
-#define AAD_LEN 20
int ieee80211_aes_gmac(struct crypto_aead *tfm, const u8 *aad, u8 *nonce,
- const u8 *data, size_t data_len, u8 *mic)
+ const u8 *data, size_t data_len, u8 *mic, u8 *zero)
{
struct scatterlist sg[4];
- u8 zero[GMAC_MIC_LEN], iv[AES_BLOCK_SIZE];
+ u8 iv[AES_BLOCK_SIZE];
struct aead_request *aead_req;
if (data_len < GMAC_MIC_LEN)
@@ -37,7 +36,7 @@ int ieee80211_aes_gmac(struct crypto_aead *tfm, const u8
*aad, u8 *nonce,
memset(zero, 0, GMAC_MIC_LEN);
sg_init_table(sg, 4);
- sg_set_buf(&sg[0], aad, AAD_LEN);
+ sg_set_buf(&sg[0], aad, GMAC_AAD_LEN);
sg_set_buf(&sg[1], data, data_len - GMAC_MIC_LEN);
sg_set_buf(&sg[2], zero, GMAC_MIC_LEN);
sg_set_buf(&sg[3], mic, GMAC_MIC_LEN);
@@ -47,7 +46,7 @@ int ieee80211_aes_gmac(struct crypto_aead *tfm, const u8
*aad, u8 *nonce,
iv[AES_BLOCK_SIZE - 1] = 0x01;
aead_request_set_crypt(aead_req, sg, sg, 0, iv);
- aead_request_set_ad(aead_req, AAD_LEN + data_len);
+ aead_request_set_ad(aead_req, GMAC_AAD_LEN + data_len);
crypto_aead_encrypt(aead_req);
aead_request_free(aead_req);
diff --git a/net/mac80211/aes_gmac.h b/net/mac80211/aes_gmac.h
index d328204d73a8..f06833c9095f 100644
--- a/net/mac80211/aes_gmac.h
+++ b/net/mac80211/aes_gmac.h
@@ -11,10 +11,13 @@
#include
+#define GMAC_MIC_LEN 16
+#define GMAC_AAD_LEN 20
+
struct crypto_aead *ieee80211_aes_gmac_key_setup(const u8 key[],
size_t key_len);
int ieee80211_aes_gmac(struct crypto_aead *tfm, const u8 *aad, u8 *nonce,
- const u8 *data, size_t data_len, u8 *mic);
+ const u8 *data, size_t data_len, u8 *mic, u8 *zero);
void ieee80211_aes_gmac_key_free(struct crypto_aead *tfm);
#endif /* AES_GMAC_H */
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 34c2add2c455..a63593f6b645 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1128,6 +1128,13 @@ enum mac80211_scan_state {
SCAN_ABORT,
};
+struct ieee80211_crypto_bufs {
+ u8 buf1[32];
+ u8 buf2[16];
+} cacheline_aligned_in_smp;
+
+extern struct kmem_cache *ieee80211_crypto_bufs_cache;
+
struct ieee80211_local {
/* embed the driver visible part.
* don't cast (use the static inlines below), but we keep
Re: [PATCH v3] mac80211: move struct aead_req off the stack
On 17 October 2016 at 09:03, Johannes Berg wrote:
> From: Johannes Berg
>
> Some crypto implementations (such as the generic CCM wrapper in crypto/)
> use scatterlists to map fields of private data in their struct aead_req.
> This means these data structures cannot live in the vmalloc area, which
> means that they cannot live on the stack (with CONFIG_VMAP_STACK.)
>
> This currently occurs only with the generic software implementation, but
> the private data and usage is implementation specific, so move the whole
> data structures off the stack into heap by allocating every time we need
> to use them.
>
> This pattern already exists in the IPsec ESP driver, but in the future,
> we may want/need to improve upon this, e.g. by using a slab cache.
>
> (Based on Ard's patch, but that was missing error handling and GCM/GMAC)
>
> Signed-off-by: Ard Biesheuvel
> Signed-off-by: Johannes Berg
> ---
> v3: remove superfluous aead_request_set_tfm() calls
Reviewed-by: Ard Biesheuvel
> ---
> net/mac80211/aes_ccm.c | 36 +++-
> net/mac80211/aes_ccm.h | 6 +++---
> net/mac80211/aes_gcm.c | 33 +
> net/mac80211/aes_gcm.h | 4 ++--
> net/mac80211/aes_gmac.c | 11 +--
> net/mac80211/wpa.c | 12
> 6 files changed, 50 insertions(+), 52 deletions(-)
>
> diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
> index 7663c28ba353..8e898a6e8de8 100644
> --- a/net/mac80211/aes_ccm.c
> +++ b/net/mac80211/aes_ccm.c
> @@ -18,29 +18,29 @@
> #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)
> +int 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 sg[3];
> + struct aead_request *aead_req;
>
> - 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;
> -
> - memset(aead_req, 0, sizeof(aead_req_data));
> + aead_req = aead_request_alloc(tfm, GFP_ATOMIC);
> + if (!aead_req)
> + return -ENOMEM;
>
> 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_crypt(aead_req, sg, sg, data_len, b_0);
> aead_request_set_ad(aead_req, sg[0].length);
>
> crypto_aead_encrypt(aead_req);
> + aead_request_free(aead_req);
> +
> + return 0;
> }
>
> int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
> @@ -48,26 +48,28 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8
> *b_0, u8 *aad,
> size_t mic_len)
> {
> struct scatterlist sg[3];
> - 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;
> + struct aead_request *aead_req;
> + int err;
>
> if (data_len == 0)
> return -EINVAL;
>
> - memset(aead_req, 0, sizeof(aead_req_data));
> + aead_req = aead_request_alloc(tfm, GFP_ATOMIC);
> + if (!aead_req)
> + return -ENOMEM;
>
> 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_crypt(aead_req, sg, sg, data_len + mic_len, b_0);
> aead_request_set_ad(aead_req, sg[0].length);
>
> - return crypto_aead_decrypt(aead_req);
> + err = crypto_aead_decrypt(aead_req);
> + aead_request_free(aead_req);
> +
> + return err;
> }
>
> struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[],
> diff --git a/net/mac80211/aes_ccm.h b/net/mac80211/aes_ccm.h
> index 6a73d1e4d186..03e21b0995e3 100644
> --- a/net/mac80211/aes_ccm.h
> +++ b/net/mac80211/aes_ccm.h
> @@ -15,9 +15,9 @@
> 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_encrypt(s
[PATCH v3] mac80211: move struct aead_req off the stack
From: Johannes Berg
Some crypto implementations (such as the generic CCM wrapper in crypto/)
use scatterlists to map fields of private data in their struct aead_req.
This means these data structures cannot live in the vmalloc area, which
means that they cannot live on the stack (with CONFIG_VMAP_STACK.)
This currently occurs only with the generic software implementation, but
the private data and usage is implementation specific, so move the whole
data structures off the stack into heap by allocating every time we need
to use them.
This pattern already exists in the IPsec ESP driver, but in the future,
we may want/need to improve upon this, e.g. by using a slab cache.
(Based on Ard's patch, but that was missing error handling and GCM/GMAC)
Signed-off-by: Ard Biesheuvel
Signed-off-by: Johannes Berg
---
v3: remove superfluous aead_request_set_tfm() calls
---
net/mac80211/aes_ccm.c | 36 +++-
net/mac80211/aes_ccm.h | 6 +++---
net/mac80211/aes_gcm.c | 33 +
net/mac80211/aes_gcm.h | 4 ++--
net/mac80211/aes_gmac.c | 11 +--
net/mac80211/wpa.c | 12
6 files changed, 50 insertions(+), 52 deletions(-)
diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
index 7663c28ba353..8e898a6e8de8 100644
--- a/net/mac80211/aes_ccm.c
+++ b/net/mac80211/aes_ccm.c
@@ -18,29 +18,29 @@
#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)
+int 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 sg[3];
+ struct aead_request *aead_req;
- 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;
-
- memset(aead_req, 0, sizeof(aead_req_data));
+ aead_req = aead_request_alloc(tfm, GFP_ATOMIC);
+ if (!aead_req)
+ return -ENOMEM;
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_crypt(aead_req, sg, sg, data_len, b_0);
aead_request_set_ad(aead_req, sg[0].length);
crypto_aead_encrypt(aead_req);
+ aead_request_free(aead_req);
+
+ return 0;
}
int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
@@ -48,26 +48,28 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8
*b_0, u8 *aad,
size_t mic_len)
{
struct scatterlist sg[3];
- 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;
+ struct aead_request *aead_req;
+ int err;
if (data_len == 0)
return -EINVAL;
- memset(aead_req, 0, sizeof(aead_req_data));
+ aead_req = aead_request_alloc(tfm, GFP_ATOMIC);
+ if (!aead_req)
+ return -ENOMEM;
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_crypt(aead_req, sg, sg, data_len + mic_len, b_0);
aead_request_set_ad(aead_req, sg[0].length);
- return crypto_aead_decrypt(aead_req);
+ err = crypto_aead_decrypt(aead_req);
+ aead_request_free(aead_req);
+
+ return err;
}
struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[],
diff --git a/net/mac80211/aes_ccm.h b/net/mac80211/aes_ccm.h
index 6a73d1e4d186..03e21b0995e3 100644
--- a/net/mac80211/aes_ccm.h
+++ b/net/mac80211/aes_ccm.h
@@ -15,9 +15,9 @@
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_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,
Re: [PATCH v3] mac80211: move extra crypto data off the stack
[snip] Sorry, this went out by mistake. johannes
[PATCH v3] mac80211: move extra crypto data off the stack
From: Johannes Berg
As the stack can (on x86-64) now be virtually mapped rather than
using "normal" kernel memory, Sergey noticed mac80211 isn't using
the SG APIs correctly by putting on-stack buffers into SG tables.
This leads to kernel crashes.
Fix this by allocating a bit of per-CPU memory for the extra data
that encryption/decryption/verification needs, instead of having
it stored on the stack.
Signed-off-by: Johannes Berg
---
net/mac80211/aes_ccm.c | 2 --
net/mac80211/aes_cmac.c| 5 ++-
net/mac80211/aes_cmac.h| 2 ++
net/mac80211/aes_gcm.c | 2 --
net/mac80211/aes_gmac.c| 10 +++---
net/mac80211/aes_gmac.h| 5 ++-
net/mac80211/ieee80211_i.h | 7
net/mac80211/main.c| 8 +
net/mac80211/wpa.c | 86 +-
9 files changed, 97 insertions(+), 30 deletions(-)
diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
index 5c9fe00be6cc..8e898a6e8de8 100644
--- a/net/mac80211/aes_ccm.c
+++ b/net/mac80211/aes_ccm.c
@@ -34,7 +34,6 @@ int ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8
*b_0, u8 *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_crypt(aead_req, sg, sg, data_len, b_0);
aead_request_set_ad(aead_req, sg[0].length);
@@ -64,7 +63,6 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8
*b_0, u8 *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_crypt(aead_req, sg, sg, data_len + mic_len, b_0);
aead_request_set_ad(aead_req, sg[0].length);
diff --git a/net/mac80211/aes_cmac.c b/net/mac80211/aes_cmac.c
index bdf0790d89cc..ebb8c2dc9928 100644
--- a/net/mac80211/aes_cmac.c
+++ b/net/mac80211/aes_cmac.c
@@ -20,7 +20,6 @@
#define CMAC_TLEN 8 /* CMAC TLen = 64 bits (8 octets) */
#define CMAC_TLEN_256 16 /* CMAC TLen = 128 bits (16 octets) */
-#define AAD_LEN 20
static void gf_mulx(u8 *pad)
@@ -101,7 +100,7 @@ void ieee80211_aes_cmac(struct crypto_cipher *tfm, const u8
*aad,
memset(zero, 0, CMAC_TLEN);
addr[0] = aad;
- len[0] = AAD_LEN;
+ len[0] = CMAC_AAD_LEN;
addr[1] = data;
len[1] = data_len - CMAC_TLEN;
addr[2] = zero;
@@ -119,7 +118,7 @@ void ieee80211_aes_cmac_256(struct crypto_cipher *tfm,
const u8 *aad,
memset(zero, 0, CMAC_TLEN_256);
addr[0] = aad;
- len[0] = AAD_LEN;
+ len[0] = CMAC_AAD_LEN;
addr[1] = data;
len[1] = data_len - CMAC_TLEN_256;
addr[2] = zero;
diff --git a/net/mac80211/aes_cmac.h b/net/mac80211/aes_cmac.h
index 3702041f44fd..6645f8963278 100644
--- a/net/mac80211/aes_cmac.h
+++ b/net/mac80211/aes_cmac.h
@@ -11,6 +11,8 @@
#include
+#define CMAC_AAD_LEN 20
+
struct crypto_cipher *ieee80211_aes_cmac_key_setup(const u8 key[],
size_t key_len);
void ieee80211_aes_cmac(struct crypto_cipher *tfm, const u8 *aad,
diff --git a/net/mac80211/aes_gcm.c b/net/mac80211/aes_gcm.c
index aa8eb2718bc1..831054c6c756 100644
--- a/net/mac80211/aes_gcm.c
+++ b/net/mac80211/aes_gcm.c
@@ -30,7 +30,6 @@ int ieee80211_aes_gcm_encrypt(struct crypto_aead *tfm, u8
*j_0, u8 *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_crypt(aead_req, sg, sg, data_len, j_0);
aead_request_set_ad(aead_req, sg[0].length);
@@ -58,7 +57,6 @@ int ieee80211_aes_gcm_decrypt(struct crypto_aead *tfm, u8
*j_0, u8 *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_crypt(aead_req, sg, sg,
data_len + IEEE80211_GCMP_MIC_LEN, j_0);
aead_request_set_ad(aead_req, sg[0].length);
diff --git a/net/mac80211/aes_gmac.c b/net/mac80211/aes_gmac.c
index 15cfcebf0884..86892e2e3c8c 100644
--- a/net/mac80211/aes_gmac.c
+++ b/net/mac80211/aes_gmac.c
@@ -19,13 +19,12 @@
#define GMAC_MIC_LEN 16
#define GMAC_NONCE_LEN 12
-#define AAD_LEN 20
int ieee80211_aes_gmac(struct crypto_aead *tfm, const u8 *aad, u8 *nonce,
- const u8 *data, size_t data_len, u8 *mic)
+ const u8 *data, size_t data_len, u8 *mic, u8 *zero)
{
struct scatterlist sg[4];
- u8 zero[GMAC_MIC_LEN], iv[AES_BLOCK_SIZE];
+ u8 iv[AES_BLOCK_SIZE];
struct aead_request *aead_req;
if (data_len < GMAC_MIC_LEN)
@@ -37,7 +36,7 @@ int ieee80211_aes_gmac(struct crypto_aead *tfm, const u8
*aad, u8 *nonce,
memset(zero, 0, GMAC_MIC_LEN);
sg_init_table(sg, 4);
- sg_set_buf(&sg[0], aad, AAD_LEN);
+ sg_set_buf(&sg[0], aad, GMAC_AAD_LEN);
sg_set_buf(&sg[1], da
[PATCH v2] mac80211: move struct aead_req off the stack
From: Johannes Berg
Some crypto implementations (such as the generic CCM wrapper in crypto/)
use scatterlists to map fields of private data in their struct aead_req.
This means these data structures cannot live in the vmalloc area, which
means that they cannot live on the stack (with CONFIG_VMAP_STACK.)
This currently occurs only with the generic software implementation, but
the private data and usage is implementation specific, so move the whole
data structures off the stack into heap by allocating every time we need
to use them.
This pattern already exists in the IPsec ESP driver, but in the future,
we may want/need to improve upon this, e.g. by using a slab cache.
(Based on Ard's patch, but that was missing error handling and GCM/GMAC)
Signed-off-by: Ard Biesheuvel
Signed-off-by: Johannes Berg
---
net/mac80211/aes_ccm.c | 34 +++---
net/mac80211/aes_ccm.h | 6 +++---
net/mac80211/aes_gcm.c | 31 +--
net/mac80211/aes_gcm.h | 4 ++--
net/mac80211/aes_gmac.c | 10 +-
net/mac80211/wpa.c | 12
6 files changed, 50 insertions(+), 47 deletions(-)
diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
index 7663c28ba353..5c9fe00be6cc 100644
--- a/net/mac80211/aes_ccm.c
+++ b/net/mac80211/aes_ccm.c
@@ -18,18 +18,16 @@
#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)
+int 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 sg[3];
+ struct aead_request *aead_req;
- 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;
-
- memset(aead_req, 0, sizeof(aead_req_data));
+ aead_req = aead_request_alloc(tfm, GFP_ATOMIC);
+ if (!aead_req)
+ return -ENOMEM;
sg_init_table(sg, 3);
sg_set_buf(&sg[0], &aad[2], be16_to_cpup((__be16 *)aad));
@@ -41,6 +39,9 @@ void ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8
*b_0, u8 *aad,
aead_request_set_ad(aead_req, sg[0].length);
crypto_aead_encrypt(aead_req);
+ aead_request_free(aead_req);
+
+ return 0;
}
int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
@@ -48,15 +49,15 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8
*b_0, u8 *aad,
size_t mic_len)
{
struct scatterlist sg[3];
- 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;
+ struct aead_request *aead_req;
+ int err;
if (data_len == 0)
return -EINVAL;
- memset(aead_req, 0, sizeof(aead_req_data));
+ aead_req = aead_request_alloc(tfm, GFP_ATOMIC);
+ if (!aead_req)
+ return -ENOMEM;
sg_init_table(sg, 3);
sg_set_buf(&sg[0], &aad[2], be16_to_cpup((__be16 *)aad));
@@ -67,7 +68,10 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8
*b_0, u8 *aad,
aead_request_set_crypt(aead_req, sg, sg, data_len + mic_len, b_0);
aead_request_set_ad(aead_req, sg[0].length);
- return crypto_aead_decrypt(aead_req);
+ err = crypto_aead_decrypt(aead_req);
+ aead_request_free(aead_req);
+
+ return err;
}
struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[],
diff --git a/net/mac80211/aes_ccm.h b/net/mac80211/aes_ccm.h
index 6a73d1e4d186..03e21b0995e3 100644
--- a/net/mac80211/aes_ccm.h
+++ b/net/mac80211/aes_ccm.h
@@ -15,9 +15,9 @@
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_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);
diff --git a/net/mac80211/aes_gcm.c b/net/mac80211/aes_gcm.c
index 3afe361fd27c..aa8eb2718bc1 100644
--- a/net/mac80211/aes_gcm.c
+++ b/net/mac80211/aes_gcm.c
@@
Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption
On Mon, 2016-10-17 at 08:50 +0100, Ard Biesheuvel wrote: > I just realised that patch should probably use > aead_request_alloc/aead_request_free [and drop the memset]. That also > fixes the latent bug where the alignment of the req ctx is not take > into account. Good point, I'll fix that up. > > > > > > > > Also, regarding your __percpu patch: those are located in the > > > vmalloc > > > area as well, at least on arm64, and likely other architectures > > > too. > > > > Crap. Any other bright ideas? > > > > kmem_cache_create() and kmem_cache_alloc() for the aad/b0/j0/etc? Hmm. Yeah I guess we should do those dynamically as well then. johannes
Re: linux-4.9-rc1/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c:1561: poor error checking ?
Hi David,
On Mon, 2016-10-17 at 07:40 +, David Binderman wrote:
> Hello there,
>
> linux-4.9-rc1/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c:1561]: (style)
> Checking if unsigned variable 'len' is less than zero.
>
> Source code is
>
> len = min((size_t)le32_to_cpu(rsp->len) << 2,
> iwl_rx_packet_payload_len(hcmd.resp_pkt) - sizeof(*rsp));
> len = min(len - delta, count);
> if (len < 0) {
> ret = -EFAULT;
> goto out;
> }
>
> Suggest improve error checking.
Thanks for reporting! A fix for this is already queued in our internal
tree and will be sent upstream soon.
--
Cheers,
Luca.
Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption
On 17 October 2016 at 08:47, Johannes Berg wrote: > On Mon, 2016-10-17 at 08:37 +0100, Ard Biesheuvel wrote: >> >> Could we get a statement first whether it is supported to allocate >> aead_req (and other crypto req structures) on the stack? > > Well, we haven't heard from Herbert :) > >> If not, then >> we have our work cut out for us. But if it is, I'd rather we didn't >> apply the kzalloc/kfree patch, since it is just a workaround for the >> broken generic CCM driver, for which a fix is already available. > > Yeah but I can't apply it. I just fixed up your kzalloc patch to also > handle GCM and GMAC, and to have error checking. Will send it in a > minute. > I just realised that patch should probably use aead_request_alloc/aead_request_free [and drop the memset]. That also fixes the latent bug where the alignment of the req ctx is not take into account. >> Also, regarding your __percpu patch: those are located in the vmalloc >> area as well, at least on arm64, and likely other architectures too. > > Crap. Any other bright ideas? > kmem_cache_create() and kmem_cache_alloc()
[PATCH] mac80211: move struct aead_req off the stack
From: Johannes Berg
Some crypto implementations (such as the generic CCM wrapper in crypto/)
use scatterlists to map fields of private data in their struct aead_req.
This means these data structures cannot live in the vmalloc area, which
means that they cannot live on the stack (with CONFIG_VMAP_STACK.)
This currently occurs only with the generic software implementation, but
the private data and usage is implementation specific, so move the whole
data structures off the stack into heap by allocating every time we need
to use them.
This pattern already exists in the IPsec ESP driver, but in the future,
we may want/need to improve upon this, e.g. by using a slab cache.
(Based on Ard's patch, but that was missing error handling and GCM/GMAC)
Signed-off-by: Ard Biesheuvel
Signed-off-by: Johannes Berg
---
net/mac80211/aes_ccm.c | 34 +++---
net/mac80211/aes_ccm.h | 6 +++---
net/mac80211/aes_gcm.c | 33 +++--
net/mac80211/aes_gcm.h | 4 ++--
net/mac80211/aes_gmac.c | 12 +++-
net/mac80211/wpa.c | 12
6 files changed, 54 insertions(+), 47 deletions(-)
diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
index 7663c28ba353..cd2f10744238 100644
--- a/net/mac80211/aes_ccm.c
+++ b/net/mac80211/aes_ccm.c
@@ -18,18 +18,15 @@
#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)
+int 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 sg[3];
+ struct aead_request *aead_req;
- 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;
-
- memset(aead_req, 0, sizeof(aead_req_data));
+ aead_req = kzalloc(sizeof(struct aead_request) +
+ crypto_aead_reqsize(tfm), GFP_ATOMIC);
sg_init_table(sg, 3);
sg_set_buf(&sg[0], &aad[2], be16_to_cpup((__be16 *)aad));
@@ -41,6 +38,8 @@ void ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8
*b_0, u8 *aad,
aead_request_set_ad(aead_req, sg[0].length);
crypto_aead_encrypt(aead_req);
+ kfree(aead_req);
+ return 0;
}
int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
@@ -48,15 +47,16 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8
*b_0, u8 *aad,
size_t mic_len)
{
struct scatterlist sg[3];
- 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;
+ struct aead_request *aead_req;
+ int err;
if (data_len == 0)
return -EINVAL;
- memset(aead_req, 0, sizeof(aead_req_data));
+ aead_req = kzalloc(sizeof(struct aead_request) +
+ crypto_aead_reqsize(tfm), GFP_ATOMIC);
+ if (!aead_req)
+ return -ENOMEM;
sg_init_table(sg, 3);
sg_set_buf(&sg[0], &aad[2], be16_to_cpup((__be16 *)aad));
@@ -67,7 +67,11 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8
*b_0, u8 *aad,
aead_request_set_crypt(aead_req, sg, sg, data_len + mic_len, b_0);
aead_request_set_ad(aead_req, sg[0].length);
- return crypto_aead_decrypt(aead_req);
+ err = crypto_aead_decrypt(aead_req);
+
+ kfree(aead_req);
+
+ return err;
}
struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[],
diff --git a/net/mac80211/aes_ccm.h b/net/mac80211/aes_ccm.h
index 6a73d1e4d186..03e21b0995e3 100644
--- a/net/mac80211/aes_ccm.h
+++ b/net/mac80211/aes_ccm.h
@@ -15,9 +15,9 @@
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_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);
diff --git a/net/mac80211/aes_gcm.c b/net/mac80211/aes_gcm.c
index 3afe361fd27c..2bd715df512f 100644
--
Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption
On Mon, 2016-10-17 at 08:37 +0100, Ard Biesheuvel wrote: > > Could we get a statement first whether it is supported to allocate > aead_req (and other crypto req structures) on the stack? Well, we haven't heard from Herbert :) > If not, then > we have our work cut out for us. But if it is, I'd rather we didn't > apply the kzalloc/kfree patch, since it is just a workaround for the > broken generic CCM driver, for which a fix is already available. Yeah but I can't apply it. I just fixed up your kzalloc patch to also handle GCM and GMAC, and to have error checking. Will send it in a minute. > Also, regarding your __percpu patch: those are located in the vmalloc > area as well, at least on arm64, and likely other architectures too. Crap. Any other bright ideas? johannes
Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption
On 17 October 2016 at 08:28, Johannes Berg wrote: > On Sat, 2016-10-15 at 18:16 +0100, Ard Biesheuvel wrote: >> The CCM code goes out of its way to perform the CTR encryption of the >> MAC using the subordinate CTR driver. To this end, it tweaks the >> input and output scatterlists so the aead_req 'odata' and/or >> 'auth_tag' fields [which may live on the stack] are prepended to the >> CTR payload. This involves calling sg_set_buf() on addresses which >> are not direct mapped, which is not supported. > >> Since the calculation of the MAC keystream involves a single call >> into the cipher, to which we have a handle already given that the >> CBC-MAC calculation uses it as well, just calculate the MAC keystream >> directly, and record it in the aead_req private context so we can >> apply it to the MAC in cypto_ccm_auth_mac(). This greatly simplifies >> the scatterlist manipulation, and no longer requires scatterlists to >> refer to buffers that may live on the stack. > > No objection from me, Herbert? > > I'm getting a bit nervous though - I'd rather have any fix first so > people get things working again - so maybe I'll apply your other patch > and mine first, and then we can replace yours by this later. > Could we get a statement first whether it is supported to allocate aead_req (and other crypto req structures) on the stack? If not, then we have our work cut out for us. But if it is, I'd rather we didn't apply the kzalloc/kfree patch, since it is just a workaround for the broken generic CCM driver, for which a fix is already available. Also, regarding your __percpu patch: those are located in the vmalloc area as well, at least on arm64, and likely other architectures too.
Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption
On Sat, 2016-10-15 at 18:16 +0100, Ard Biesheuvel wrote: > The CCM code goes out of its way to perform the CTR encryption of the > MAC using the subordinate CTR driver. To this end, it tweaks the > input and output scatterlists so the aead_req 'odata' and/or > 'auth_tag' fields [which may live on the stack] are prepended to the > CTR payload. This involves calling sg_set_buf() on addresses which > are not direct mapped, which is not supported. > Since the calculation of the MAC keystream involves a single call > into the cipher, to which we have a handle already given that the > CBC-MAC calculation uses it as well, just calculate the MAC keystream > directly, and record it in the aead_req private context so we can > apply it to the MAC in cypto_ccm_auth_mac(). This greatly simplifies > the scatterlist manipulation, and no longer requires scatterlists to > refer to buffers that may live on the stack. No objection from me, Herbert? I'm getting a bit nervous though - I'd rather have any fix first so people get things working again - so maybe I'll apply your other patch and mine first, and then we can replace yours by this later. johannes
