Slashdot Mirror
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."
Getting rid of ACPI sounds also like a "good luck with that" plan.
Well I call for an end to spurious pluralization, so there!
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Perfect example would be dell bios. There is no way DELL would allow a USER into bios. Especially one that might cause issues that can't be condensed into auto-replies.
Restore the madness of youth's lechery
You don't have to.
Just don't lock your implementation away and let people actually use it
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
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.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
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.
Firmware is just fine, as long as it's non-proprietary--free as in freedom.
ACPI WMI specs from the HW makers would be nice. It's frustrating how many laptops have broken hotkeys under Linux.
Precisely how does he intend that a machine boot to the install media without executable firmware?
He does not complain about executable, he complains about proprietary.
Besides, ACPI is complete overkill for booting.
Finally! A year of moderation! Ready for 2019?
ACPI WMI specs from the HW makers would be nice. It's frustrating how many laptops have broken hotkeys under Linux.
If we are currently at the point where you can't even get the details of what the Windows Management Instrumentation blobs embedded in the motherboard firmware mean, that might be another reason why somebody running a Linux company might dislike ACPI...
As long as (through some mixture of overt standard-setting to that effect, and basic 'you actually think that we are going to keep testing our BIOS once it boots Windows? That means that it's ready to ship!' OEM engineering) proprietary firmware is basically the lowest level of Windows drivers, writing other OSes on top of it just isn't going to be a pleasant experience.
So how did RMS posses Shuttleworths body?
At Canonical, making Unity worse is job 1! It gets harder every release to make Unity worse than the last one, so it takes all their mental effort. Perhaps with open firmware, Unity could actually electrocute the user, opening a whole new realm of "worse".
Socialism: a lie told by totalitarians and believed by fools.
That. Absolutely.
Shuttleworth may be slightly off the mark, but his dislike for proprietary firmware is worth supporting, given what we're learning daily about what people who mean us no good are doing with our consumer electronics.
You are welcome on my lawn.
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.
Its already been decided by the industry that its going to be ACPI.
And Canonical helped desgin it... with ACPI in it
http://www.businesswire.com/ne...
So I don't understand why Mark is suddenly against it. Sudden change of heart leading Ubuntu to be non compatible with other linux operating systems? Again? I don't get it.
Well.. maybe. Or Maybe not. But Definitely not sort of.
Isn't device tree pretty much declarative firmware? It has gained quite a bit of ground in the ARM on Linux world recently too. Seems like the solution already exists, it just need a bigger push.
He's talking about ACPI. That is, firmware that the kernel is expected to trust and run in it's own context after being loaded. That is quite distinct from bootstrap firmware that is expected to load and jump into the bootloader and then be inactive until the next boot.
BTW, much of it is actually broken in various ways.
I think you mean PLCC. It can be soldered directly to a board or socketed. And in the recent past it was the choice for socketing BIOS chips after DIP32 fell out of favor. QFP is quad flat pack which is always directly soldered to the board and not easily removed. I never seen a QFP socket outside of test fixtures.
With the high density of todays boards, even PLCC is gigantic in terms of footprint so many have moved to smaller SMT packages. I have seen Intel motherboards using 8 pin SOIC chips, most likely on an I2C or SPI bus. You can buy sockets for them but no mainstream motherboard maker sockets them.
it's called reference frameworks. By the time you get to Userland, a Creative soundcard looks to the software identical to a Turtle Beach. This would be impossible without a reference. One obvious example is DirectX. What you want out of the arse end of the driver layer is a device interface that's compatible with DirectX. What happens between the driver layer and the hardware is entirely up to the manufacturer, but the DirectX compatibility is a certain requirement for even the slightest hope that you'll even get a peep out of it in Windows. And one of the reasons why the Linux driver model, at least from my own personal perspective, is horribly broken. Is there a reference framework for *anything* in Linux?
Political debates have me rolling my eyes so much I think I got optical whiplash. I should sue. - Foamy The Squirrel
Everybody runs into problems with ACPI. I've never seen it work properly, on any OS, on any machine that I've owned.
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.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
"What Shutters wants is irrelevant. What he needs is open interface specifications to the hardware."
I think that's what he wants:
"Declarative firmware that describes hardware linkages and dependencies but doesn’t include executable code is the best chance we have of real bottom-up security. The Linux device tree is a very good starting point."
I don't read your sig. Why are you reading mine?
ACPI is not just used for booting, it's used for controlling the customizations between systems. While the PC architecture has changed little in the way of memory maps since the 1980s, there are still things that various computer manufacturers do that no OS could ever program for.
For example, PCI interrupt routing was completely up to the manufacturer in routing which IRQ when to which PCI IRQ. They were normally scrambled so you don't have all the cards using one IRQ line, but that information needs to be communicated between the BIOS and the kernel, otherwise the kernel has no way to handle PCI interrupts properly.
You could define a data structure (which is what ACPI does), or you could program into the kernel every variation around for every motherboard, and hope that every mobo manufacturer out there updates the list and submits the patch.
The other thing is, well, ACPI handles rebooting, shutdowns and suspend/resume. It tells you how to poke the hardware in various ways to accomplish the goal. It isolates the difference between hardware to the people who know it best - the hardware guys.
Some of these things may be GPIO pins that change for routing convenience (to enable/disable wireless, for example, or for various status LEDs), power switches that control how the regulators operate, other settings and controls for various voltage rails and such.
Every PC is not the same, each manufacturer might choose a different power regulator IC that requires different programming to turn it on and off, and ACPI is best to handle it. otherwise the kernel will have to have each and every variation in it programmed in.
Honestly Shuttleworth's reasoning "Binary blobs can contain NSA exploits" is completely irrelevant to ACPI since ACPI byte-code can be completely de-compiled back in to the original source language making it very easy for security researchers to detect any funny business.
Honestly the modern PC has several microcontrollers in it that contain code that the primary CPU never even sees. I personally would consider those a much bigger security threat than ACPI.
So lets ask ourselves... why does he really want to get rid of ACPI? The answer is pretty simple, it going to take a lot of coding effort to get the Linux ACPI stack ready to fully support ACPI 5.0 and Connected Standby found on a lot of brand new laptops. This is just a feeble attempt to mask the fact that puring all his resources in dumb projects like Mir and Unity doesn't leave much left to keep up to date on new open PC platform standards.
Your description of the GPLv666 with a "Demonic Possession" section sounds very worthy of a Charles Stross novel, in every respect. Kudos!
"Ahh! I see you're in that indeterminate Schrodinger state where - oh, uh
Declarative firmware only gets you so far. You can say 'Register to do X is at this address' but without software than knows what the hell to do with X you don't have a solution. Without an open interface spec, you can't write the software.
That's why open interface specifications are a prerequisite for a bottom-up auditable code set.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
You misunderstand me, I love slack too.
I was (somewhat tongue-in-cheek) pointing to its role as the standard implementation. Which unfortunately is really just a memory as for over a decade now other distros have insisted tenaciously on ignoring solid standards and everyone just reinvents the wheel, in ever more byzantine fashion each iteration.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.