On 2018-01-24 16:56, Johannes Berg wrote:
> On Wed, 2018-01-24 at 16:19 +0100, Felix Fietkau wrote:
>> Apparently hardware does not perform CCMP PN validation in hardware, so
>> we need to take care of this in the driver. This is important for
>> protecting against replay attacks
>>
>> +static int
>> +mt76_check_ccmp_pn(struct sk_buff *skb)
>> +{
>> + struct mt76_rx_status *status = (struct mt76_rx_status *) skb->cb;
>> + struct mt76_wcid *wcid = status->wcid;
>> + int ret;
>> +
>> + if (!(status->flag & RX_FLAG_DECRYPTED))
>> + return 0;
>> +
>> + if (!wcid || !wcid->rx_check_pn)
>> + return 0;
>> +
>> + BUILD_BUG_ON(sizeof(status->iv) != sizeof(wcid->rx_key_pn[0]));
>> + ret = memcmp(status->iv, wcid->rx_key_pn[status->tid],
>> + sizeof(status->iv));
>> + if (ret <= 0)
>> + return -EINVAL; /* replay */
>> +
>> + memcpy(wcid->rx_key_pn[status->tid], status->iv, sizeof(status->iv));
>> + status->flag |= RX_FLAG_PN_VALIDATED;
>
> You shouldn't do this, try to somehow make it rely on mac80211 instead.
>
> Otherwise, you really have to handle CCMP vs. fragmentation.
I guess I will have to look into fragmentation. I have a second driver
pending that only reports the CCMP PN outside of the packet, and for
performance reasons I really don't want to translate it and move it to a
place where mac80211 can parse it.
I'm also looking into doing parallel rx in software to see if I can get
more performance that way. I think for that I would also need CCMP PN
validation in the driver.
- Felix
