Shuttleworth Wants To Get Rid of Proprietary Firmware 147
jones_supa writes "In a new blog post, the Ubuntu main man Mark Shuttleworth calls for an end to proprietary firmwares such as ACPI. His reasoning is that running any firmware code on your phone, tablet, PC, TV, wifi router, washing machine, server, or the server running the cloud your SAAS app is running on, is a threat vector against you, and NSA's best friend. 'Arguing for ACPI on your next-generation device is arguing for a trojan horse of monumental proportions to be installed in your living room and in your data center. I've been to Troy, there is not much left.' As better solutions, Shuttleworth suggests delivering your innovative code directly to the upstream kernel, or using declarative firmware that describes hardware linkages and dependencies but doesn't include executable code."
Re:Precisely how... (Score:5, Interesting)
I'm talking about the device not the kernel.
I can compile up my own kernel and test my device against it. But I can't go and deploy my device on the myriad computer/OS configurations out there if I need stuff compiled into the kernel. ACPI solves a problem. If your solution that replaces ACPI doesn't solve the problem ACPI solves while also solving the trojan-via-firmware problem, then it's useless. ACPI is horrible, and I'm all for replacing it with something better but I'm not seeing a proposal that does both.
Re:Some context from a hardware perspective. (Score:4, Interesting)
Okay, but despite being Turing complete most of those devices could be contained by an open source firmware in a secure way. For example the LED controller is probably what, an I2C device? There is no way it could compromise anything with an even half way competent ACPI implementation. The battery monitor, LCD, GPS and probably a few others probably fall into that category too.
For everything else you need a secure APCI implementation that is based on not trusting the firmware in those devices. Okay, the wifi firmware could intercept, modify or leak any packets, but at least with an open source ACPI implementation the damage could be limited, contained and perhaps detected. It's not perfect but it's a lot better than what we have now.