From mboxrd@z Thu Jan 1 00:00:00 1970 From: Antonio Quartulli Date: Wed, 04 Dec 2013 14:23:44 +0100 Subject: [ath9k-devel] Key Cache corruption (was: GTK/PTK problem - key.c magic-bitshift) In-Reply-To: References: <20131117110802.GD1381@neomailbox.net> <20131118215127.GC1443@open-mesh.com> <20131122091848.GF1443@open-mesh.com> Message-ID: <529F2CE0.4080009@open-mesh.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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) iQIcBAEBCAAGBQJSnyzgAAoJEEKTMo6mOh1VxggP/jzp+UB8lPiFItwMPXwob8ik qNd1WcQhcShft8MrmK9kfjzp91t/uBby/QVsqwxKu8sVIpuQJaGI4ikOtIZ6/8b6 FGkn+JouKY+gmEsT6U4Hfq6v4Ri/xKkUt5JfPN7moQr3OszitbnDGlO3gr9qY3Vv YjDGkZPlAmGCpnLUY1nHiBrEhj0WX2GrFXQC06wskk5UYEyvE5PDy9LUt1ASQkxe qa6rBWaanVT0YpLhoHXNldSu6aF1r1HXaG+lKnBMgJlBcLSBta7oxzYjxj6oPtLQ J+QYkdkkwrEGqVR8JL+54tAYkJ0TZvw+DKuJ6PcWE/Z74LiiVczrEZ0yf5oQm8Ki EgQUay8X3gOT9ZFIrnYUK3i2PdA8UsBv/xmIOhlRHqx2Au7bcekM+9c7tIZjxz0V QVspKLaRefvP4thcB0Sni56D05vHdV69wFPui+d+Y2Z/i72NjP4x2AXylfOmVNsV 9tI135f8see5wQOQN7WJFuM67h7GlyeSIeAZWFjwhdDBWSmWDtal9w9930MZgAVe Oh1oLCoboi3gywiN4bpL59Thvt164prDQA6aA9uu90Ytbzxept0ZUITd+z5XQVbb BLBWLSrZme0BDCqkJw55Z/ypl4TlXIIdWK935YDNMPRl1RGo86KUDSoCbFZNjc4J w8WBV7CS7jmU+E2DjLzy =gnO4 -----END PGP SIGNATURE-----