Given the new “router ban”, and how it’s all because of security, it occurs to me that an Ada implementation of the requisite standards/protocols, proved with SPARK and leveraging Annex H’s Inspection_Point and Reviewable pragmas would go a long way to addressing the problems — bonus points if it’s bare-metal, foregoing even an OS.
(The way to hit all the problems would be to VHDL the components, too. On that thought, see this thread.)
The router ban is actually more about the HW than the SW, because there’s no way to actually see what’s inside the chip in your box. So you can’t tell where the malware is. But to build a cybersecure product, you need both HW+SW working together. So switching to Ada/SPARK along with new RTL would be the smart move.
It’s a little ironic because there is a valid problem here which is software vulnerabilities which TP-link have been renowned for. I could be wrong but it looks like TP-Link may avoid the ban just by manufacturing in the U.S. which wouldn’t solve the problem at all. A fully fledged open source Ada SPARK network stack would be great though but I guess quite an undertaking.
I would suspect that an FPGA with three CPUs: one for external (administrative, non-secure) work, one that’s secure (root-of-trust), and one that’s secure and manages all the traffic would be pretty easy to build.
The RTL would take a month or something, because the necessary IP already exists: you just need to wire it together.
Then the SW can be developed one MVP at a time: A simple 2-port switch that expands numbers of ports and data rate.
Probably need to build a HW wrapper around it that’ll redirect all the traffic out the usual single WiFi port on the board.
But one could also create the ability to do Ethernet-over-cable (traditional ethernet), Ethernet-over-USB, etc. Because then it’s just wrapping stuff.
Personally, you could just take any of the existing examples from the FPGA vendors that do WiFi, and just expand. Opentitan is open-source and is meant to be used as the root-of-trust CPU.