Transmit power isn't really what's at issue; it's radar avoidance measures like dynamic frequency selection that aren't implemented by the radio hardware and thus have to be done by the host Linux system. Existing wifi hardware is capable of limiting maximum transmit power for each channel, but unless router manufacturers want to disable half of the 5GHz band, they need to do something to ensure that the user can't turn off DFS. Existing chipsets don't allow for appropriate separation of concerns: the host system is responsible for some RF parameters like DFS, and the radio's baseband processor (running proprietary signed firmware) is being used to do packet scheduling and retransmissions.
Could they just disable support for the U-NII-2 channels in the hardware? Those are the ones that require DFS and I would find losing them to be preferable to manufacturers trying to prevent people from using OSS.
What are U-NII-2 channels used for? I've not come across that term before.
As an alternative suggestion, couldn't the transmit power be capped in hardware? I don't see why you'd need to have hardware that could exceed the specified transmit limits, other than to save money for the manufacturers (allowing them to tweak transmit power in software to meet the regulations in different countries, assuming the maximum transmit power for wireless routers varies from country to country).
As a side note, the L4Re hypervisor the article proposes using looks very promising, first I've heard of it, was hoping someone would make a hypervisor based on a provably secure kernel like L4 one day, seems like it already exists.
