Very nice research and writeup. For those who haven't seen it a couple of years ago, Project Zero also had a series of articles about exploiting Broadcom's WiFi stack [0].
[0] https://googleprojectzero.blogspot.com/2017/04/over-air-expl...
For security purposes we do not want any binary drivers, blobs, bloated boat loaders and other fancy non-security in the hardware. This is really really basic security level.
Writing new firmware would be a lot easier than designing a new chipset.
A few RF transceivers and an FPGA like an Artix-7 (which has PCIe capability) might do the trick. It wouldn't be as cheap as a mass produced chipset, but a completely open 802.11ac chipset is unlikely to be mass produced anyway.
We already have examples of LTE base stations being run with SDR hardware like the LimeSDR, which is just an RF transceiver and an Altera FPGA, with a USB3 connection to the FPGA fabric.
In fact there are some SDR/FPGA dev kits that are Mini PCIe size and intended for use inside a laptop, specifically designed with LTE in mind[1].
So WiFi seems doable, even if you end up with a soft core CPU in the FPGA to do the same jobs WiFi chipset firmware is doing right now, at least you'd have full control over it and the firmware running on it.
Current market FPGAs definitely aren't some shining beacon alternative to shitty hardware vendors, they are amongst the worst of the lot.
It needs a lot of money. You'd have to sell people a free virtual spaceship with the thousand-dollar tiers, maybe. And persuade people to accept higher per-unit costs than the cheap Chinese equivalents.
The better approach is probably a fully open firmware for an existing ASIC - let someone else subsidize your production costs. Obviously there's still attack surface in the fixed-function ASIC components but the attack surface is way smaller and the boundary could probably be audited fairly well.
Honestly it feels like a fantasy though
At least, I'd rather have anything but the current alternative: a device on the PCI bus having DMA with a firmware I can't audit.
Same thing with WWAN device by the way.
> with a firmware I can't audit.
In modern fast datapaths, there is a good deal of hardware acceleration involved, the firmware code would probably be incomprehensible without intimately knowing these.
Tradeoffs, as always.
For some applications, I want low latency and high throughput. For others, I want security.
Does than mean the procedure of responsible disclosure was followed but vendor failed to patch on time?
List of impacted devices includes PS4, Xbox One, Samsung Chromebooks, and Microsoft Surface devices.
Nicely written paper from Embedi researcher Denis Selianin himself:
https://embedi.org/blog/remotely-compromise-devices-by-using...
All kinds of jailbreaks, no matter if for the first generations of iPhones, for consoles, or for rooting Android devices, are based on vendors implementing shoddy security. Take it away and whoops, now we as users are fully in the death grip of what vendors and RIAA/MAFIAA allow us to do.
IMHO it's already gotten a bit too far in that direction, and if there's no mass revolt (which is itself quite unlikely), it's only going to get worse. The old Franklin quote has never been so relevant... people these days are so highly valuing "safe" over "free", that they don't realise they're building prisons around themselves.
In the United States, you can also join The Repair Association advocacy group: https://repair.org/
> PCs are just several embedded devices in a trenchcoat
Saying this without any animosity, but you would probably be interested in reading about the history of operating systems. Desktop OSes are a (very visible) minority, and it's the opposite way in my opinion: a desktop OS is an OS + a large suite of tools + a shell.
It's literally something that operates the system so that every program written doesn't have to handle all the low level IO, that enables task management, etc.
But as of right now you can use[1] the Lattice iCE40 (small, 8k LUTs), Lattice UltraPlus (5k LUTs, DSPs) and Lattice ECP5[2] (~85k LUTs, with 5G SerDes and PCIe Gen 2) with completely open tools. The ECP5 in particular would be well suited for it.
And there is a productive effort[3] to do the same for the Artix-7 and other Xilinx 7 Series parts.
Even for those parts that are still very much closed, you can load an existing bitstream on them using open tools. Intel Max10, which is the part found on the LimeSDR Mini, is one of those even though we don't have open bitstream documentation for it yet.
The major commercial FPGA tools all work Linux at this point too, I use most of them on Ubuntu routinely including Lattice Diamond, Altera/Intel Quartus, and Xilinx ISE/Vivado.
[1] http://www.clifford.at/icestorm/
After the memory controller, bus bridges, GPUs, and DMA controller, it's probably the largest one.
Probably best to distinguish between processing-heavy and throughput-heavy; apart from the GPU, all those are throughput-heavy but do very little to the data, and I think would not normally have a recognisable processor or an OS. There's the additional problem that they're required to boot, so nowhere convenient to load the OS from unless you scatter SPI flash across the board.
GPUs on the other hand have a full task-switching operating system.
I would be surprised if the faster bus and memory controllers had it (because of latency problems). I would expect something like it on a USB controller, GPU, network or disk interface. I really have no idea what to expect from a DMA controller.
While you can achieve the same abstraction in hardware it’s much easier and cheaper to simply pick a small micro controller and do all the black magic you need in software especially since the flash on some of these cards can be really really bad as it’s often the lowest grade flash or worse recycled memory that ends up being used which means you end up with chips that are 50-80% defected so the controller ensures that these sectors/cells aren’t used.
> "hreadX provides priority-based, preemptive scheduling, fast interrupt response, memory management, interthread communication, mutual exclusion, event notification, and thread synchronization features. Major distinguishing technology characteristics of ThreadX include preemption-threshold, priority inheritance, efficient timer management, picokernel design, event-chaining, fast software timers, and compact size. The minimal footprint of ThreadX on an ARM processor is on the order of 2KB"
ie it's generic code that gets built into a unikernel-style image with the device-specific code that actually implements the various tasks required of a wifi controller.
I haven’t seen any evidence that any of these MC does anything beyond that.