Shuttleworth Wants To Get Rid of Proprietary Firmware

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."

Comments

Re:Precisely how...

[TechyImmigrant]

I design hardware. I could wait for someone to accept my changes into the Linux Kernel before I start testing it, or I could write some firmware accessible through ACPI.

What Shutters wants is irrelevant. What he needs is open interface specifications to the hardware.

What RMS has been saying all along.

[Anonymous Coward]

So people are just now figuring out that o'l fatty hippy beard Richard Stallman was right all along?

Color me fucking surprised! Any code you can't see can and will be used against you.

RMS says things that are uncomfortable and difficult but painfully true. Don't mistake is disinterest in your feelings (Or business model) as hostility.

Re:Precisely how...

[Anonymous Coward]

Firmware is just fine, as long as it's non-proprietary--free as in freedom.

Re:Possesion

[fahrbot-bot]

So how did RMS posses Shuttleworth's body?

There's an obscure clause deep down in the GPL ...

Some context from a hardware perspective.

[queazocotal]

Great - you don't want ACPI.

I'm looking at my Nokia n900 phone.
(merely because I happen to have a detailed understanding of the design).

Inside it, there are the following closed-source blobs running on turing complete processors.

LED controller firmware.
SIM java virtual machine
SIM raw firmware.
eMMC controller.
SD controller.
Hard-real-time modem controller.
Modem high-level engine.
Bluetooth CPU.
Wifi processor.
Main linux application processor
GPU.
I strongly suspect there is also an embedded processor in:
Power managment controller.
LCD.
Battery charge monitor.
GPS. (It's possible this is just an application running on the closed-source modem high level engine).

https://srlabs.de/rooting-sim-...
http://www.youtube.com/watch?v... (rooting SD cards)
http://www.youtube.com/watch?v... (battery firmware hacking)
Similar efforts have been done with reverse engineering the firmware of bluetooth devices, wifi.
The notion that you should only care about the code running on the CPU being open has always seemed really naive to me.

Re:Precisely how...

[TechyImmigrant]

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.