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.
