MT7612U: hardware CCMP is unreached — what it would take, and why not to design the key surface yet

[snokvist]

Summary

The MT7612U MAC has per-station CCMP key hardware. devourer does not reach any
of it — on every backend, CCMP is done in software. This issue records what
would be involved on MediaTek, and deliberately does not propose an IRadio
key surface: per the review discussion on #424, a crypto key contract should
be designed against two backends rather than one.

This is a capability question, not a defect. #424 ships a working WPA2-PSK AP
on this part using devourer's existing software CCMP.

Why it is not just a flag

Four separate things are missing, only one of which is a register:

1. Two registers are absent from the tree. MT_WCID_KEY and MT_WCID_IV
   are both undefined in src/mt7612u/regs.h; mt76x02_mac_wcid_set_key()
   writes both (mt76x02_mac.c). MT_WCID_ATTR, MT_SKEY and MT_SKEY_MODE
   are defined and are zeroed at init by wcid_and_key_clear()
   (src/mt7612u/init.cpp) — which is the "encrypt nothing" configuration an
   injector wants, and the same registers a key install writes.

2. The per-frame encrypt gate is currently set the wrong way for crypto.
   There is such a flag — MT_TXD_INFO_WIV — and mt_tx_build() sets it
   unconditionally, meaning "no hardware IV insertion, this frame is not
   encrypted". mt76 gates it on whether the WCID has a key (!wcid || hw_key_idx == 0xff || sw_iv). A key install has to make WIV conditional,
   not just fill the key slots.

3. TX selects encryption by WCID, so it is per-station and all-or-nothing.
   txwi->wcid chooses the key, and every library path calls mt_tx_build()
   with 0xff, the no-station index. mt_wcid_setup(idx, mac) exists but its
   only caller anywhere is src/mt7612u/tools/bringup.cpp (for its rate-LUT
   gate) — no library or Mt7612uRadio path installs a station. So a station
   table has to exist before a key has anywhere to live.

4. RX needs real work, not a flag. The hardware strips the MIC and MMIC but
   not the IV/PN: mt76 removes that in the driver using MT_RXINFO_PN_LEN,
   and deliberately does not on a fragment. MT_RXINFO_PN_LEN is already
   defined here and unused; MT_RXINFO_DECRYPT is not defined at all.

What is deliberately not proposed

An IRadio key surface. IRadio has no key install and no cipher enum today,
which is a reasonable place to be when only Jaguar1 carries the Realtek
TX-descriptor security field (SET_TX_DESC_SEC_TYPE_8812, per
docs/ap-mode.md). A key interface is a much larger contract than a feature
flag — key lifetime, GTK vs PTK, rekey, who owns the replay counter — and
expensive to undo once callers exist. It should be shaped by a second backend
that actually wants it, not by this one alone.

What would make this worth doing

Two things the software path cannot give:

• GTK rekey, which docs/ap-mode.md puts explicitly out of scope on
  Realtek.
• Throughput, unmeasured. Software CCMP's cost on this stack has not been
  quantified, so "hardware crypto is faster here" is currently an assumption.
  A measurement of the software path's per-frame cost would be the cheapest
  way to decide whether any of the above is worth the interface churn.

Current state

docs/mt7612u-ap-mode.md (§ "What is still missing: hardware key install")
carries the same list against file:line in the merged subtree, and is the place
to keep it current.