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."
Precisely how... (Score:2)
Precisely how does he intend that a machine boot to the install media without executable firmware?
Or is he a proponent of the "disposable machine" -- once infected, you *have* to replace it, because you can't *reinstall*?
Re:Precisely how... (Score:4, Insightful)
Re:Precisely how... (Score:5, Insightful)
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.
Re: (Score:3)
Re: (Score:3)
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 basical
Re: (Score:3)
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.
Re: (Score:2)
and he will NEVER get it.
Hell you cant get open microcode on the freaking processors.
Shuttleworth is starting to become a little nutty.
Re: (Score:1)
Microcode has nothing to with any how you interact with the CPU though. ACPI However *is* the actual Interface. Hes saying lets label all the roads in this town and you're saying Mr. Smith never lets us play inside his yard.
Re: (Score:1)
"I could wait for someone to accept my changes into the Linux Kernel before I start testing it"
How's that? If you propose your changes to be accepted to Linux, you should already have tested it, and I guess that's how it generally works right now?
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: (Score:2)
ACPI solves a problem
And creates half a dozen worse problems in the process.
Re: (Score:2)
ACPI solves a problem
And creates half a dozen worse problems in the process.
Which bit of "ACPI is horrible, and I'm all for replacing it with something better" did you miss?
Re: (Score:2)
Re: (Score:2)
I hate ACPI and avoid it at all costs. But I'm fully aware that if you removed ACPI, you would have to replace it with something. My Apple 2 has a scheme for mapping ROMs on cards into memory and calling them at boot time based on descriptors in the ROMs. It has to exist in some form.
Re: (Score:1)
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.
Or; you could write a FOSS module interlinked with ACPI to coreboot [coreboot.org] and then everything would be free and you would have the ACPI you wanted. You would probably even find that the community would fix the bugs in the software you wrote for free and you would sell extra hardware.
The thing is, that we want the full source to every bit. Anything less and the security risk is just too great.
Re: (Score:2)
What Shutters wants is irrelevant. What he needs is open interface specifications to the hardware.
One might reasonably argue that what one needs is the source to the firmware and the tools needed to apply it to the device. One's rebuttal might involve cost, but not "you don't need that".
Re: (Score:3)
"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."
Re: (Score:3)
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.
Re: (Score:2)
Not on target systems I don't control. Can I plug my new thing into the USB port of a Samsung phone? Not if I have to replace the kernel. The thing is locked.
You can arrange your own machines how ever you like, but if you're building things to work on everyone's machines, then you need to test it in many contexts that you don't control.
Re: (Score:2)
Getting rid of ACPI sounds also like a "good luck with that" plan.
If anything, insufferably shitty firmware has been steadily bloating to the point where we should probably start including it in operating system marketshare charts...
Re: (Score:3)
Re: (Score:2)
Re: Precisely how... (Score:2)
Yah. But ARM has the little bit of cpu ram. Thus you start out without having to knowi anything about the busses like to the regular RAM. But there are specialized compilers for say AMD64 that produce programs that do not use RAM. But ...
Grub2 just will not fit in the usual sized BIOS ROM. Mostly everything is easy quantity 1 plus some sort of trade offs in money and skill and time. Now go fix it quantity G this calendar year with everyone trying to stop you.
Re: (Score:2)
He didn't say get rid of ACPI.
He said get rid of proprietary firmware.
You can have an open source ACPI (https://acpica.org/downloads) which you can audit to find the NSA evil bits.
Re: (Score:3, Informative)
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
Re: (Score:1)
What exactly was stupid about my post? Take it you have never heard of ACPI Source Language [acpi.info] or the Embedded Controller [thinkwiki.org]?
Seriously where should you more worried about NSA exploits1) a de-compilable and OS visible byte code that controls thermal and power management or 2) An invisible micro controller firmware that converts signals from your scan matrix laptop keyboard into P/S 2 signaling?
Seriously dude, I write firmware for a living... I know a thing or two about what it does and the state of Linux's ACPI s
Re: (Score:1)
Re:Precisely how... (Score:5, Informative)
Firmware is just fine, as long as it's non-proprietary--free as in freedom.
Re: (Score:2)
Re: (Score:2)
DIL socket. Add your own firmware chip.
Re: (Score:2)
Yuck QFP is a lot better far better pin density and easier to insert or remove safely.
Re: (Score:3)
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 o
Re: (Score:2)
Correct, I mis-identified the package, I have QFP on the brain as I have been searching ebay for some old stock to fix an old DSP board, looks like I have to scrounge for some TMS320's on old boards.
Some of the newer PLCC's have very dense pins on the surface mounted sockets. And honestly with I2C it is trivial to solder the chip on the board and simply provide a header to reprogram it. The funny part is a lot of the guys that really want socketed chips to use with their external programme
Re:Precisely how... (Score:5, Informative)
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.
Re: (Score:2)
So you can't power off the machine while it's booting?
Give your head a shake.
Re: (Score:2)
Then again, I have to hold down the power switch until it takes effect while booting, so maybe ACPI isn't involved and it's me that needs to give their head a shake.
Anyone know for sure?
Re: (Score:2)
queazocotal has it right. ACPI prepares the hardware and tells the kernel where to find it.
Of course on recent hardware EFI is taking over part of that. EFI is significantly more bloated than traditional ACPI BIOS.
Re: (Score:2)
It is.
It's one of the primary means that the kernel (of whatever OS) works out what hardware it's actually running on, and what it should setup.
ACPI, PCI* configuration registers, and friends are all pretty much required in order to boot a random system successfully.
Re: (Score:2)
Besides, ACPI is complete overkill for booting.
Agree. I've written bootloader code and kernel drivers. All the bootloader really has to do is get the kernel in memory somehow and jump to it. Why can't you boot directly into the kernel you ask ? One reason is size; on many (embedded) systems, there are only a few Kb available for an executable on boot. The other is that the bootloader doesn't not change easily (it needs reflashing or is in some kind of ROM), allowing you to easily change the kernel.
Re: (Score:3)
ACPI is n
Re: (Score:2)
I do not think that anyone has a problem with interrupt routing tables or ACPI documenting how hardware should be poked. It could be laid out a little simpler perhaps, but that is mostly bikeshedding.
One of the problems is that ACPI suddenly yanks the CPU out from under you and executes its own proprietary code, and the kernel or user space can do absolutely nothing about it.
Re: (Score:2)
Re: (Score:2)
It also contains the code executed in System Management Mode (SMM) which may handle tasks like legacy emulation and thermal control.
Re: (Score:1)
Point totally MISSED! The firmware running in the bios should be OPEN SOURCE - as in Coreboot. Modern PCs today don't NEED the bios of old as the hardware drivers get replaced anyway - with more open source.
Furthermore, the whole UEFI fiasco could have been eliminated if we had a simple SWITCH on a pc to ALLOW writing to flash only when the user decides to update the bios - and I'm talking about a switch connected to the VLSI flash controller that can not be circumvented by software. A whole lot cheaper.
Ope
Re: (Score:2)
The reference implementation of UEFI is open source, and some vendors use it as a basis for their firmware.
Unfortunately, most Coreboot-using devices are tied down and do not allow non-interactive booting with custom firmware (if they allow custom firmware at all).
Re:Precisely how... (Score:4, Informative)
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.
Re: (Score:2)
It is true that the kernel is expected to load and run the ACPI bytecode in a trusted context... but your assumption that the BIOS is gone after the OS bootloader runs is inaccurate. SMM [wikipedia.org] keeps BIOS code code resident forever and running at a higher privilege level than your OS kernel. And its impossible for your kernel to see what SMM is doing unlike ACPI which is pretty easy to inspect,
Your BIOS already owns the platform and getting rid of ACPI won't change that, it will just make it more difficult to fi
Re: (Score:2)
I'm not as worried about ACPI from that standpoint as Shuttleworth is. I am worried about the way it is generally buggy and only actually tested on the latest Windows so often. Of course, ACPI should not be used as an excuse to make hardware incompatible with standards.
I find SMM more concerning since it can obviously be used to produce a really nasty and hard to detect rootkit. At least ACPI has to reveal itself and offers the possability of running it in a sandbox..
I have no sympathy whatsoever for any at
Re: (Score:2)
He said "get rid of proprietary firmware".
He didn't say get rid of all firmware.
There is a difference.
Open source firmware can be audited to see if the spooks are getting their hands on your data... not so with the proprietary stuff.
Source codes, legos, meccanos (Score:4, Funny)
Well I call for an end to spurious pluralization, so there!
Re: (Score:3)
You don't have to.
Just don't lock your implementation away and let people actually use it
Re:Silly Rabit (Score:4, Insightful)
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?
Re: (Score:2)
Yes, it's called Slackware.
Re: (Score:3)
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.
Re: (Score:2)
I love Zipslack... still use it on a positively ancient Dell CP (Pentium MMX) laptop. It's handy when all I want to do is type and don't need to be hearing the fan (which hasn't worked since ever and that isn't an issue anyway as the processor barely gets warm).
Re: (Score:2)
Is there a reference framework for *anything* in Linux?
For graphics there's KMS and DRI and Gallium. For audio there's ALSA. For printing there's CUPS. For scanning there's SANE. Etc.
Re: (Score:2)
Yeah, most of those popped into my head one second after I hit "send"(!)... but speaking from my own experience, I've never been able to get a Winprinter working under CUPS (maybe I'm being 'tarded about it). As to graphics, I wasn't even going to pick up the whip if it wasn't an ATI/AMD or NVidia chip (OK, the drivers are proprietary for both, but I'm not bitter - I even managed to get Beryl running on an upgraded Rage Pro). Trying to get anything near "accelerated" on any other graphics chip was for me, l
Winprinter (Score:2)
but speaking from my own experience, I've never been able to get a Winprinter working under CUPS (maybe I'm being 'tarded about it).
That depends on how you define "Winprinter". There used to be a concept of a "GDI printer" (or a "QuickDraw printer" during the classic Mac OS days), which relies on a rasterizer running on a PC to create a bitmap in some proprietary format and send it to the printer. More generally, they're called "non-PostScript printers", and they work fine under CUPS provided the manufacturer is friendly to the CUPS community. I bought my HP OfficeJet 4500 for exactly that reason: official support for printing and scann
Re: (Score:2)
tried several bottom-shelf Lexmark inkjets, a couple of the Canon portables (BJ-10e and a BJC-80) and an HP Deskjet 320 as well. Ended up hooking up a Brother HL1030 (laser with manufacturer-supplied CUPS driver) and a HP Officejet 6210 MFD (ran through HPLIP), the other gear is gathering dust and spider colonies in a closet somewhere - can't even give the bloody things away...
Translated (Score:1)
"We at ubuntu ran into problems working with firmware type X and want to get rid of it and need an excuse, playing on fears tends to work, so let's use that"
Re: (Score:2)
I can't see this happening. (Score:4, Funny)
Make Ubuntu work properly first (Score:1)
Re: (Score:1)
But fixing bugs is hard!! Canonical is too busy code-churning for boring stuff like bug-fixing.
Re: (Score:3)
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".
What RMS has been saying all along. (Score:5, Insightful)
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.
On the subject of Troy (Score:2)
I've been to Troy, there is not much left
Funny thing is, that's less due to Achaeans and more to Schliemann's "excavations". ;-)
(BTW, when did Shuttleworth decide to grow a kinkled beard?)
Starts with one generic enough (Score:2)
And if people start buying from that brand over rivals (or having country legislation forbidding not open enough and/or so backdoored hardware) it may move others to do the same.
Also, if a "hidden" functionality is exposed in major brands using that executable code to perform malware-like activities that brands should be punished in security aware circles. That won't reach the majority of people, but will be an start.
Possesion (Score:3)
So how did RMS posses Shuttleworths body?
Re:Possesion (Score:5, Funny)
So how did RMS posses Shuttleworth's body?
There's an obscure clause deep down in the GPL ...
Re:Possesion (Score:4, Insightful)
It's part of the GPLv666 under the "Demonic Possession" section if you use the "or any later version" clause. I hear Stallman wrote the original in blood, he couldn't find any open source ink. And you really don't want to know how the toe jam is involved.
Re: (Score:1)
And how does Stallman expect me to acquire the blood I need to produce the copy of the license I must distribute?
If there's something worse than vendor lock-in, it's Free Software preacher lock-in.
Charles Stross? Is that you? (Score:3)
Re: (Score:2)
A trojan in his ACPI firmware?
Some context from a hardware perspective. (Score:5, Informative)
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-... [srlabs.de]
http://www.youtube.com/watch?v... [youtube.com] (rooting SD cards)
http://www.youtube.com/watch?v... [youtube.com] (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:Some context from a hardware perspective. (Score:4, Informative)
There are many cellphones where there is an independent CPU running the cellular radio. This CPU runs a proprietary OS that runs has write access to all memory and can actually override the main CPU. In theory the radio CPU and OS could actually overwrite memory on the fly and redirect the kernel in completely transparent ways.
Re: (Score:2)
I believe it's nearly all phones, if not all of them.
Re: (Score:2)
I believe so as well but without reviewing every possible phone I wasn't comfortable making that prediction. I know almost every major SOC that produces radio chips does this because of fear that people would tamper with radio power levels but it's a major security hole that I'm sure is being exploited by groups like the NSA.
Re: (Score:2)
Yes.
More context (Score:2)
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.
An OS can cope with hostile peripherals: (Score:2)
In fact Qubes assumes they are hostile to a great extent already.
As long as one trusts the BIOS and other critical boot-time elements (i.e. ACPI), you have a very good shot at maintaining security with a system like Qubes and this is why Qubes users are expessing a lot of interest in Coreboot (open BIOS).
(Of course, one must also trust the CPU and chipset, but these are often provided by the same vendor which reduces the trust issue down to one party. And we're not even talking firmware or software here: It
Re: (Score:2)
Shuttleworth wrote ... (Score:2)
In ye olden days, a manufacturer would ship Windows, which could not be changed
What the hell is he talking about?
This is about ARM 64 bit Servers (Score:4, Informative)
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... [businesswire.com]
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.
Re: (Score:3)
Responding to my own post. Mark explained himself on Google plus (can't link to it directly but look for Jon Masters post about annoying a billionaire) :
"SBSA did not specify ACPI or any other crapware, and we were happy to support a standards-based approach. I think it's a poor effort if we can't achieve the goal of standards in a more modern, secure, open way."
So it appears that he supported one standardization effort, but it didn't specify ACPI. I don't know what the truth is as the relevant documents ar
Re: (Score:2)
https://plus.google.com/106265... [google.com]
Re: (Score:2)
Yes, there are many fears of what a government could do to gain access. There is no way to avoid it currently. Saying ACPI has the potential for problems doesn't add anything new to the conversation that's been going on for years.
I'm guessing someone just informed him what his company agreed to, or he's gone a bit crazy.
Because "Open Source" isnt an NSA vector (Score:1)
Remember GnuTLS
Re: (Score:2)
That ship sailled in the early 90's (Score:2)
No escaping proprietary firmware now. I would hazard a guess that a laptop purchased today has firmware or firmware libraries from over 1000 teams.
You don't see them, because most are stored in roms and flash, and your OS doesn't need to know about them...
The train left the station in the 2000s (Score:2)
Escaping proprietary firmware.... http://www.coreboot.org/Welcom... [coreboot.org]
in a good mood (Score:1)
he's seen the light. (Score:1)
Wow, is it true? This is the guy that was all about willingly making it easy for folk to install proprietary drivers for everything to ease adoption of Ubuntu. I remember all the forum discussions about that. Has he finally had a change of heart? RMS is likely having a moment of grim satisfaction right now.
Chrome OS > OS X (Score:2)
Most laptaps these days are sold with OSX actually
Citation needed that over 50 percent of laptops are MacBooks. Last year freaking Chrome OS outsold OS X [ibtimes.com] (source: Google macbook laptop market share).