Imagination Solution to FCC Rules for WiFi Routers: Run OpenWrt / DD-WRT and the WiFi Driver in Separate Virtual Machines

About a year ago, discussions started about new rules from the FCC that could prevent routers from installing open source third party operating systems such as OpenWrt or DDWRT. Despite the FCC assurance that the rules were meant to prevent some users from illegally tweaking the RF settings, and that it would not have to impact installing of open source alternatives, the reality is that companies such as TP-Link ended up locking their routers up due to the new rules, while Linksys would only ensure OpenWrt/ DD-WRT compatibility on some of their routers, but not all. Companies are probably doing that due to the extra work that would be required to separate the RF settings which need to be locked, and the rest of the firmware. But Imagination Technology’s prpl security group has a solution for their MIPS Warrior P-Class processors using hardware virtualization.

OpenWrt_Virtualization_Block_Diagram

In order to show the concept works, they’ve developed the solution on an evaluation board based on Baikal T1 dual core MIPS P5600 communication processor, and using a Realtek RTL8192 WiFi adapter and the Ethernet port (WAN) for communications. The serial port was used for debugging Linux.

One the software side, they run an hypervisor, and three virtual machines (VM) leveraging the processor hardware capabilities:

  • Open source L4Re hypervisor comprised of an L4 microkernel that can run trusted native applications and act as a trusted hypervisor for operating systems.
  • Open VM for OpenWrt running OpenWrt and providing the main interface to the router facilities
  • Isolated VM for the Wi-Fi driver without direct access to the driver from other VMs, except through the virtual network connection using ports 85 for http, 449 for https or 29 for ssh. That’s the important part to comply with the FCC rules.
  • Dedicated VM for third party applications acting as a sandbox for running third party applications that provide additional functionality such as home automation apps.

Here’s the demo.

Of course, this will not solve the issues for existing cheap routers, but this could be a solution for future not-so-low-end WiFi routers.

Share this:
FacebookTwitterHacker NewsSlashdotRedditLinkedInPinterestFlipboardMeWeLineEmailShare

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK 5 ITX RK3588 mini-ITX motherboard

9 Replies to “Imagination Solution to FCC Rules for WiFi Routers: Run OpenWrt / DD-WRT and the WiFi Driver in Separate Virtual Machines”

  1. Great. This is the design behind QubesOS and while not perfect, it’s better then a blob. In fact, Qubes uses Xen which has much more overhead then a microkernel like L4Re so this is better.

    Really good solution. Hopefully we’ll see this getting to phones and even desktops as a workaround to graphics and other blobs.

    Of course, it all depends on a trustworthy hardware virtualization layer. But MIPS is pretty good there.

  2. I’m currious about “donation” from nsa or any federal blob unit to FCC. They are lot of imagination to put a good spy in, sure they forget to apply only their endless imagination on >20dbm device…
    Who paid FCC?

  3. Unfortunately, the blobs often suck. The “make wifi fast” project is working to de-suck the linux wifi stack, something that’s going to be harder to do with even more devices running blobs.

  4. This is like QubesOS, except it’s the exact opposite of QubesOS. Because QubesOS is about making sure your computer is secure against external attack, and this use of virtualization is about treating the user as the attacker.

    No, this is not a real solution to the FCC’s rule.

  5. @Decade
    Intentions are irrelevant. If you have a hypervisor you trust (FOSS) isolating the blob, even if the blob has a backdoor allowing remote code execution, it can’t tunnel into the lan.

    It’s precisely the same security design QubesOS has. QubesOS even has documentations mentioning closed source LAN firmwares that can’t be trusted isolated in this exact same way.

    Not only this is a really good solution to the FCC’s regulations, it’s actually a good security feature to have regardless. After-all, FOSS drivers have bugs and exploits too so if you can isolate them you’re better off security wise.

  6. @RK

    [it can’t tunnel into the lan]

    If the wireless of router share internet to other device at home, connected to each other – your android phone can talk to your pc – why this VM can’t go out to leek information about you.
    It ‘s seem an dangerous way to accept that at home. In other hand, it’s a perfect push button to disabled wireless dissident/illegal/gouvmentNonLikedProject just from control commander data center of nsa or kgb…

    A better way to free air is to propose a new layer to lower Tx if wireless station have enough db at reception. No need to cop everything everywhere.
    my 2 cents

  7. better this VM can send your wireless key ondemand, to activate patriotact at home.
    Who control the totality of android data sending over internet, unreal to send also VM data to a fake android server?
    Sorry but it’s not a good definition of better world for me. I think about journalist, sources againts corruption, real privacy for real capacity of thinking well as we can, etc…

Leave a Reply

Your email address will not be published. Required fields are marked *

Boardcon Rockchip and Allwinner SoM and SBC products
Boardcon Rockchip and Allwinner SoM and SBC products