On Fri, 2012-09-07 at 19:01 +0200, Christian Lamparter wrote: > > > 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? Hmm, I guess we would have that, and actually ... we know MFP will be used for the *station* so we should in fact know this already. I'll need to revise my patch. D'oh. > (Note: I haven't > seen much/any of the 11w spec, as 802.11-2012 is AFAICT still not > available for _free_). Hm. Well it was published March 29th, so it should be available in 3 weeks if they hold their promise ... > 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. CMAC keys aren't per-station, so we'd have to remove them all or something? But I think we already know about MFP for the station when we set the key, I'll check this. > > > 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?! No, just because it was unused. Adding a new key could also be implemented, or you could iterate the keys in some way maybe. > > > 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. Right. Seems pretty simple really, but I guess the devil is in the details :-) Anyway I'll revise that patch (after dinner) and see if MFP flag is set correctly, if so then we can just use that. johannes -- 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
