2
0

013-rt2x00-Work-around-a-firmware-bug-with-shared-keys.patch 4.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143
  1. From a4296994eb8061ee3455721a296c387c639bf635 Mon Sep 17 00:00:00 2001
  2. From: Bernd Edlinger <[email protected]>
  3. Date: Tue, 15 Jan 2019 14:01:29 +0000
  4. Subject: [PATCH 13/28] rt2x00: Work around a firmware bug with shared keys
  5. Apparently the rt2x61 firmware fails temporarily to decode
  6. broadcast packets if the shared keys are not assigned
  7. in the "correct" sequence. At the same time unicast
  8. packets work fine, since they are encrypted with the
  9. pairwise key.
  10. At least with WPA2 CCMP mode the shared keys are
  11. set in the following sequence: keyidx=1, 2, 1, 2.
  12. After a while only keyidx 2 gets decrypted, and
  13. keyidx 1 is ignored, probably because there is never
  14. a keyidx 3.
  15. Symptoms are arping -b works for 10 minutes, since
  16. keyidx=2 is used for broadcast, and then it stops
  17. working for 10 minutes, because keyidx=1 is used.
  18. That failure mode repeats forever.
  19. Note, the firmware does not even know which keyidx
  20. corresponds to which hw_key_idx so the firmware is
  21. trying to be smarter than the driver, which is bound
  22. to fail.
  23. As workaround the function rt61pci_config_shared_key
  24. requests software decryption of the shared keys,
  25. by returning EOPNOTSUPP. However, pairwise keys are
  26. still handled by hardware which works just fine.
  27. Signed-off-by: Bernd Edlinger <[email protected]>
  28. Acked-by: Stanislaw Gruszka <[email protected]>
  29. Signed-off-by: Kalle Valo <[email protected]>
  30. ---
  31. drivers/net/wireless/ralink/rt2x00/rt61pci.c | 93 +-------------------
  32. 1 file changed, 4 insertions(+), 89 deletions(-)
  33. --- a/drivers/net/wireless/ralink/rt2x00/rt61pci.c
  34. +++ b/drivers/net/wireless/ralink/rt2x00/rt61pci.c
  35. @@ -321,97 +321,12 @@ static int rt61pci_config_shared_key(str
  36. struct rt2x00lib_crypto *crypto,
  37. struct ieee80211_key_conf *key)
  38. {
  39. - struct hw_key_entry key_entry;
  40. - struct rt2x00_field32 field;
  41. - u32 mask;
  42. - u32 reg;
  43. -
  44. - if (crypto->cmd == SET_KEY) {
  45. - /*
  46. - * rt2x00lib can't determine the correct free
  47. - * key_idx for shared keys. We have 1 register
  48. - * with key valid bits. The goal is simple, read
  49. - * the register, if that is full we have no slots
  50. - * left.
  51. - * Note that each BSS is allowed to have up to 4
  52. - * shared keys, so put a mask over the allowed
  53. - * entries.
  54. - */
  55. - mask = (0xf << crypto->bssidx);
  56. -
  57. - reg = rt2x00mmio_register_read(rt2x00dev, SEC_CSR0);
  58. - reg &= mask;
  59. -
  60. - if (reg && reg == mask)
  61. - return -ENOSPC;
  62. -
  63. - key->hw_key_idx += reg ? ffz(reg) : 0;
  64. -
  65. - /*
  66. - * Upload key to hardware
  67. - */
  68. - memcpy(key_entry.key, crypto->key,
  69. - sizeof(key_entry.key));
  70. - memcpy(key_entry.tx_mic, crypto->tx_mic,
  71. - sizeof(key_entry.tx_mic));
  72. - memcpy(key_entry.rx_mic, crypto->rx_mic,
  73. - sizeof(key_entry.rx_mic));
  74. -
  75. - reg = SHARED_KEY_ENTRY(key->hw_key_idx);
  76. - rt2x00mmio_register_multiwrite(rt2x00dev, reg,
  77. - &key_entry, sizeof(key_entry));
  78. -
  79. - /*
  80. - * The cipher types are stored over 2 registers.
  81. - * bssidx 0 and 1 keys are stored in SEC_CSR1 and
  82. - * bssidx 1 and 2 keys are stored in SEC_CSR5.
  83. - * Using the correct defines correctly will cause overhead,
  84. - * so just calculate the correct offset.
  85. - */
  86. - if (key->hw_key_idx < 8) {
  87. - field.bit_offset = (3 * key->hw_key_idx);
  88. - field.bit_mask = 0x7 << field.bit_offset;
  89. -
  90. - reg = rt2x00mmio_register_read(rt2x00dev, SEC_CSR1);
  91. - rt2x00_set_field32(&reg, field, crypto->cipher);
  92. - rt2x00mmio_register_write(rt2x00dev, SEC_CSR1, reg);
  93. - } else {
  94. - field.bit_offset = (3 * (key->hw_key_idx - 8));
  95. - field.bit_mask = 0x7 << field.bit_offset;
  96. -
  97. - reg = rt2x00mmio_register_read(rt2x00dev, SEC_CSR5);
  98. - rt2x00_set_field32(&reg, field, crypto->cipher);
  99. - rt2x00mmio_register_write(rt2x00dev, SEC_CSR5, reg);
  100. - }
  101. -
  102. - /*
  103. - * The driver does not support the IV/EIV generation
  104. - * in hardware. However it doesn't support the IV/EIV
  105. - * inside the ieee80211 frame either, but requires it
  106. - * to be provided separately for the descriptor.
  107. - * rt2x00lib will cut the IV/EIV data out of all frames
  108. - * given to us by mac80211, but we must tell mac80211
  109. - * to generate the IV/EIV data.
  110. - */
  111. - key->flags |= IEEE80211_KEY_FLAG_GENERATE_IV;
  112. - }
  113. -
  114. /*
  115. - * SEC_CSR0 contains only single-bit fields to indicate
  116. - * a particular key is valid. Because using the FIELD32()
  117. - * defines directly will cause a lot of overhead, we use
  118. - * a calculation to determine the correct bit directly.
  119. + * Let the software handle the shared keys,
  120. + * since the hardware decryption does not work reliably,
  121. + * because the firmware does not know the key's keyidx.
  122. */
  123. - mask = 1 << key->hw_key_idx;
  124. -
  125. - reg = rt2x00mmio_register_read(rt2x00dev, SEC_CSR0);
  126. - if (crypto->cmd == SET_KEY)
  127. - reg |= mask;
  128. - else if (crypto->cmd == DISABLE_KEY)
  129. - reg &= ~mask;
  130. - rt2x00mmio_register_write(rt2x00dev, SEC_CSR0, reg);
  131. -
  132. - return 0;
  133. + return -EOPNOTSUPP;
  134. }
  135. static int rt61pci_config_pairwise_key(struct rt2x00_dev *rt2x00dev,