On Sun, May 17, 2015 at 10:25 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Sun, 2015-05-17 at 21:23 +0300, Emmanuel Grumbach wrote: > >> One thing that I still haven't understood here is how can we get to a >> situation in which we already parsed the EAPOL of the GTK re-keying, >> but not a data frame that must have been sent before the EAPOL? >> The Rx path is serialized after all. I'd expect maybe to loose frames >> because we are still using the old key while the new key has been sent >> and not to get to the situation where: >> >> data: old Key PN = 997 >> data: old Key PN = 998 >> data: old Key PN = 999 >> set new key PN = 0 >> data: old Key PN = 1000 >> (new key's PN gets set to 1000 ** BUG **) >> data: new Key PN = 1 <DROPPED> > > Yeah, this is the situation. How it happens is like this: > (* - data, # - control) > > > * data RX in HW, decrypt w/ old key, PN=998 > * data RX in mac80211 - PN <= 998 [old key] > # set key pointer to new key > * data RX in HW, decrypt w/ old key, PN=999 > * data RX in mac80211 - PN <= 999 [new key!! - PROBLEM FOR NEXT FRAME] > # delete old key from HW crypto > # add new key to HW crypto Yeah - ok. But how come we *already* set the pointer to the new key while the HW is still successfully decrypting with the old key. This is the point I can' figure out. I'd expect the transmitting side to stop using the old key prior to sending the EAPOL (which #triggers the set key pointer line). So those 2 lines don't make sense to me: > # set key pointer to new key > * data RX in HW, decrypt w/ old key, PN=999 After all, the Rx path is serialized all the way through from the air to mac80211. The only thing I can think about is that the sending side is still using the old key *after* it already sent its EAPOL frames. Then, by pure change, we can still decrypt them in HW because the HW hasn't been updated yet (these frames are successfully decrypted because of race basically) and then, these frames come up to mac80211 *after* the EAPOL but with the old key. This is what the submitter says: " The encryption key indeed changes immediately after the last packet of the handshake, but the Initialization Vector is still counting up against the old value. " So maybe that's the real issue? > > Perhaps then the easier way to solve it would be to simply delete HW > crypto *before* changing the key pointer. Somewhat similar, but perhaps > simpler, than my previous patch. This would end up with the scenario > like this: > > * data RX in HW, decrypt w/ old key, PN=998 > * data RX in mac80211 - PN <= 998 [old key] > # delete old key from HW crypto > # set key pointer to new key > * data RX in HW, decryption possible > * data RX in mac80211, decrypt fails [old key was used, new key is > valid] > # add new key to HW crypto > > The problem with that approach is how to handle drivers that *must* use > HW crypto, like ath10k, and cannot fall back to software crypto. For > those, having a state where a key is valid in software but not uploaded > to hardware is basically an invalid state. > > Then again, we can probably accept that for the transition period, as > the result really would only be to indicate to mac80211 that unencrypted > frames must not be accepted (key pointer exists.) > > That'd look something like this: > http://p.sipsolutions.net/941c1a69a9c54a73.txt > > 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
