ACPI, firmware and your security
Monday, March 17th, 2014ACPI comes from an era when the operating system was proprietary and couldn’t be changed by the hardware manufacturer.
We don’t live in that era any more.
However, we DO live in an era where any firmware code running 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.
If you read the catalogue of spy tools and digital weaponry provided to us by Edward Snowden, you’ll see that firmware on your device is the NSA’s best friend. Your biggest mistake might be to assume that the NSA is the only institution abusing this position of trust – in fact, it’s reasonable to assume that all firmware is a cesspool of insecurity courtesy of incompetence of the worst degree from manufacturers, and competence of the highest degree from a very wide range of such agencies.
In ye olden days, a manufacturer would ship Windows, which could not be changed, and they wanted to innovate on the motherboard, so they used firmware to present a standard interface for things like power management to a platform that could not modified to accommodate their innovation.
Today, that same manufacturer can innovate on the hardware and publish a patch for Linux to express that innovation – and Linux is almost certainly the platform that matters. If Windows enters this market then the Windows driver model can evolve to give manufacturers this same ability to innovate in the Windows world, where proprietary unverifiable blobs are the norm.
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 centre. I’ve been to Troy, there is not much left.
We’ve spent a good deal of time working towards a world where you can inspect the code that is running on any device you run. In Ubuntu we work hard to make sure that any issues in that code can be fixed and delivered right away to millions of users. Bruce Schneier wisely calls security a process, not a product. But the processes for finding and fixing problems in firmware are non-existent and not improving.
I would very much like to be part of FIXING the security problem we engineers have created in our rush to ship products in the olden days. I’m totally committed to that.
So from my perspective:
- Upstream kernel is the place to deliver the software portion of the innovation you’re selling. We have great processes now to deliver that innovation to users, and the same processes help us improve security and efficiency too.
- 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. We have work to do to improve it, and we need to recognise the importance of being able to fix declarations over the life of a product, but we must not introduce blobs in order to short cut that process.
Let’s do this right. Each generation gets its turn to define the platforms it wants to pass on – let’s pass on something we can be proud of.
Our mission in Ubuntu is to give the world’s people a free platform they can trust. I suspect a lot of the Linux community is motivated by the same goal regardless of their distro. That also means finding ways to ensure that those trustworthy platforms can’t be compromised elsewhere. We can help vendors innovate AND ensure that users have a fighting chance of privacy and security in this brave new world. But we can’t do that if we cling to the tools of the past. Don’t cave in to expediency. Design a better future, it really can be much healthier than the present if we care and act accordingly.
March 17th, 2014 at 5:11 pm
I believe that ARM SBSA is targeted at only servers though.
March 17th, 2014 at 5:22 pm
Where even HP don’t restrict access to firmware updates that solve security bugs.
March 17th, 2014 at 7:50 pm
Compare and contrast:
http://www.businesswire.com/news/home/20140129006200/en/ARM-Ecosystem-Collaborates-Deliver-Initial-Server-Platform
“ARM-based servers have the potential to transform the datacenter ecosystem back into a dynamic, innovative market,” said Christian Reis, vice president, Hyperscale Computing, Canonical. “We see the SBSA effort removing barriers to adoption by providing a framework for system implementation that any technology supplier can easily understand and follow. Canonical fully supports this effort and is committed to SBSA compliance for our Ubuntu Server product family.”
I think there’s some background missing here. And I’m betting dollars to donuts Jon Masters is involved somewhere.
March 17th, 2014 at 9:05 pm
While I strongly applaud this call; where was this idea when Ubuntu touch crowdfundying was happening? I believe hearing that there was going to be no guarantee for open firmwares or anything. Why not a call for open firmwares then?
March 18th, 2014 at 2:40 am
I can’t agree more with your post. Thank you for stating this, and thank you for working towards this goal. I hope that other Free Software companies such as RedHat can help throw their weight around to help you get there.
I hope that your work extends to motherboard firmware, hard drive firmware, RAID controller firmware, IPMI/management firmware, and firmware for every other chip that ever gets shipped.
Cheers
James
March 18th, 2014 at 3:12 am
I am a BIOS engineer with >10 years of experience in the field. I think you have a misunderstanding of what ACPI is. ACPI has two parts, one is simply static data tables describing the system (harmless), and the other is some interpreted bytecode (mostly harmless). The bytecode is very limited compared to say, Java.
In order for the bytecode to access hardware, the bytecode must describe the hardware resource to the OS. Then the OS can then choose if it wishes to prohibit access. For example the Microsoft ACPI interpreter prohibits certain hardware resources such as the RTC from being touched by the byte code. Also keep in mind that the ACPI interpreter is just another driver within the OS.
It possible you confused ACPI with SMI. System Management Mode is a different ballgame.
March 18th, 2014 at 4:50 am
This url is cited in:
http://news.softpedia.com/news/Mark-Shuttleworth-Talks-About-the-ACPI-Security-Plague-and-Solutions-to-Fix-It-432531.shtml
Whether they publish my comment is uncertain, so:
“Paragraphs 2 & 3 on Snowden; so had to check your source … which had only one sentence on this topic. Then googled further: Linus has had many statements on the Wintel plot (ACPI) to undermine Linux, which is what I had understood before reading your version of history.
If you read Linux forums, ACPI has succeeded in preventing easy installation of Linux.”
Chief Information Officer Retired, 1984
Australian Capital Territory
March 18th, 2014 at 8:52 pm
While you worry about ACPI, I worry about the trend towards proprietary firmware in 802.11ac devices. These devices MUST share with other devices on the same spectrum, must do solid encryption, and must not waste valuable bandwidth – in addition to being updateable to handle new threats and new features (like bufferbloat fixes) and to retain kernel compatibility long term.
The profusion of blobs in the wireless world is legion – only one driver, for the ath9k (wireless-n) is reasonably open.
I hope some chipmaker sees opportunity in releasing open firmware for 802.11ac.
March 19th, 2014 at 6:34 am
I concur with Mark, firmware (BIOS, ACPI, UEFI and others) are a huge security risk and Snowden has shown that intelligence agencies are using this to their advantage. Stallman may seem on the lunatic fringe by only buying a laptop with FOSS firmware but he’s actually ahead of the curve.
March 19th, 2014 at 3:25 pm
ACPI has its fair share of problems ( mostly on the bios implementers side ), but security is not one of them. In fact, things are often the reverse of what you describe: the ACPI implementation is broken, and system vendors ship windows patches to make things work right, leaving Linux in the cold. The OS has to choose to execute AML code, and it is rather limited in what it can do, so it is not a very interesting attack vector. If you control the bios of a modern intel system you can insert code to run in system management mode that can do anything at all, and entirely without the OS’s knowledge or consent.
March 19th, 2014 at 9:33 pm
@CantSay
Yes, you’re correct, the real issues are a little deeper than simply saying “ACPI is a problem”. My post was aimed at our values – do we value a quick fix that repeats the past (starting with ACPI but moving quickly to UEFI and other x86 configurations) or do we value taking a little time to build it in a better-by-design, more defensible way?
March 20th, 2014 at 5:06 am
So you’re saying the status quo is one giant hack. I agree, the round trips that data takes, referring specifically to WMI, is ridiculous. The EC needs to go also. There should only be one chip on the board that has access to everything and can be programmed to do anything.