On Friday 07 September 2012 18:27:57 Johannes Berg wrote: > On Fri, 2012-09-07 at 18:25 +0200, Christian Lamparter wrote: > > > > > if we want to do the right thing here, then I guess > > > > we should go for another alternative: a rxkey manager > > > > of some sorts. So, we delete keys from the firmware > > > > context once MFP comes into the game. > > > > > > That's kinda what I do though, the flag tells you > > > (at key installation) whether MFP will be used or > > > not. It's just that in the AP case, mac80211 doesn't > > > actually know. > > > > Oh no, I mean dynamic reconfiguration of the firmware's > > keycache during runtime. > > Right right, but for MFP that doesn't help since in AP mode > we don't know whether to expect encrypted management frames > or not. Hmpf, don't we set the CMAC key in this case? (Note: I haven't seen much/any of the 11w spec, as 802.11-2012 is AFAICT still not available for _free_). However, my thinking is/was that when mac80211 tries to upload the CMAC key, return -EOPNOTSUPP and we kick the ccm per-station key, so the firmware won't try to decrypt incoming (mgmt and data) frames with this combination anymore. > > But for this, we would need > > a way to tell mac80211 when driver wants to delete a key > > from the hw/fw cache and when there is room for another > > one (Didn't you had a patch for the "we have a empty slot > > in the rxkey cache we are not using" case some time ago? > > However in this case, we want to tell mac80211 what "exact" > > key (by MAC of the peer and key index) we want.) > > I had a patch for the opposite: please remove this key, I can't > handle it any more. Adding a new one in that case couldn't be > done. Ah well, that's too bad. Altough, I thought you removed it because its prone to cause rx/tx races?! > > Of course, I'm well aware of the "amount of work" and the > > problems associated with removing and readding keys during > > runtime without causing races (or just minor races). > > Actually that's not too difficult, the bigger difficulty is > actually knowing which key to re-upload I think. Well, the firmware reports a "CACHE MISS" status in every encrypted rx frame if no key was found in the rxkey cache. Of course, being a cache, we can make some sort of LRU (not sure about the size, but rxkey cache * 2 would be a start) and keep track of the rx key usage. This way when a "rxkey" becomes more popular it will be detected and "replace" a rxkey that is no longer active... and so on. Regards, Chr -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
