[ath9k-devel] Key Cache corruption

[Antonio Quartulli <antonio@open-mesh.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hoi Adrian,

I don't want to push (I am just polling here ;-)), but have you been
able to squeeze any information out of the MAC guys?

Cheers,

On 04/12/13 18:08, Adrian Chadd wrote:
> Hi,
> 
> I'll see if I can organise a chat with the MAC guys this week at 
> Atheros and ask them about this. Stay tuned...
> 
> 
> -a
> 
> On 4 December 2013 05:23, Antonio Quartulli <antonio@open-mesh.com>
> wrote: Hi list, hi Adrian, hi Sujith (just added to the cc list),
> 
> sorry for the silence, but I have been busy testing different 
> approaches on how to solve this.
> 
> On 22/11/13 10:42, Adrian Chadd wrote:
> 
> 
> Mh, that is true with TKIP.
> 
> This means we have no way to recognize a TX key corruption. For
> this reason a periodic worker that unconditionally checks the cache
> and possibly refresh it looked like the best solution.
> 
> However, after testing this strategy I realised that the worker is
> not able to see the cache corruption: what it reads from the memory
> always matches what we have in mac80211 (but I am sure we had a
> corruption).
> 
> My opinion is that the corruption is really happening at a low-low 
> level and so the memory content is not even altered. This may be
> one of the reasons why this bug is so difficult to catch.
> 
> The only solution I see to this problem is to make the periodic
> worker refresh the key cache every second, no matter if a
> corruption is found or not.
> 
> However it does not sound like a good solution..any thought?
> 
> 
> 
> Another experiment I have done was to refresh the whole key cache
> each time a new key is pushed into ath9k. I did this because I
> observed that the corruption was triggered upon GTK upload (on
> re-keying). This fix seemed to make things better.
> 
> So another plausible strategy could be a mix of the above
> solutions:
> 
> 1) refresh the entire cache on each set_key(cmd=SET_KEY) call 2)
> upon detection of a number of RX decrypt errors schedule a worker 
> that refresh the entire cache (not the single slot...because that 
> could be the cause for another corruption...).
> 
> 
> Still we have the problem of the TX key corruption with TKIP. If
> this happens we can't detect it and we need to wait for the next
> set_key() before the key can be properly restored.....
> 
> 
> Any better idea?
> 
> 
> Regards,
> 
> 

- -- 
Antonio Quartulli
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJSpZitAAoJEEKTMo6mOh1VSLYQAIPCr6j6YJd0WiVeO23xGS75
hO7kfSm2y+zMJvl8WYFY5mKrUUssXYfp9YvDOUZV1KSK3cxHt93dzlEnvyhLCAQc
RpHsbg0DPcuxIKzH4hQVl6mYyzAqMm2/icRXome+6H2Fz8fcGNy+4FGwiAhvAZdx
3WIj773EwE8m2/M4Kpa5HHIrcmJ305EFopAXZMEP9N37V1ANTGkJDhWI9gU3sqC/
XQmeNsTY3m0LG/CTyhoT0RvkW284pGxQkVPd29QDQFYKAQv0DcrPmohcprPcfQmA
Bf1MIKTV734RQ+bU/TPw5lpCpUnGPhILwiijsnwNWGKSBEgjydS7LXp9/F+QMHHi
inUOY9zVJHvETCJ+4cI/xKOYU1UCAsqnKldBmY63BrJr/MhJ1JiPsKVbd6rIyGmP
KuQ9J4y+yP+y6TOYFoyFNlLFWRS+tbY2XPm51nV7aaYvmKZi+GgA8i1per3xmNAl
28Qwqnerjl+gyF0+IpU+61uMkx9wg3jIs2PtW9Ek7tSLOPb5vjyCmRvw8N+Djyax
fr57lMwqV/yKZJlv5NA6i04WoocHn3IM2WaS7BeO/7h4sDKY2BOprpc4YxFw9rPF
ZwhDNrVpMOWJzpnBwFyNNjXofQ6iVdtDmzHuUG98Y+WvEbMMV4Rq5sMu7rq03Mz7
w2IPW9twgtvcXUc2V7R3
=GZj5
-----END PGP SIGNATURE-----