|
|
Subscribe / Log in / New account

Shuttleworth: ACPI, firmware and your security

Mark Shuttleworth argues against the use of ACPI in "next-generation devices" on the basis that it is a huge security hole. "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."

to post comments

Shuttleworth: ACPI, firmware and your security

Posted Mar 17, 2014 13:52 UTC (Mon) by bersl2 (guest, #34928) [Link] (8 responses)

The only problem is that whatever firmware replaces it will have the same issues, only less standardized. The fact is, hardware and firmware are just as bad as user- and kernel-land software when it comes to not-working and being insecure (and probably worse, considering that most of it is closed-design).

Shuttleworth: ACPI, firmware and your security

Posted Mar 17, 2014 14:21 UTC (Mon) by bronson (subscriber, #4806) [Link] (6 responses)

But whatever firmware replaces it can be vastly SMALLER than ACPI, both in scope and lines of code. And that's a big step in the right direction.

Back in the 90s I remember being blown away at how Linux basically kicks the BIOS to the curb at its earliest opportunity and tries to do everything itself. That's way more effort! Are these guys nuts?

Not at all. Turns out that worked out really, really well.

Shuttleworth: ACPI, firmware and your security

Posted Mar 17, 2014 16:39 UTC (Mon) by jwarnica (subscriber, #27492) [Link] (3 responses)

The BIOS is the PC pretending very, very hard to be a PC from 1983. Of course avoiding that is a good thing.

Shuttleworth: ACPI, firmware and your security

Posted Mar 18, 2014 9:51 UTC (Tue) by etienne (guest, #25256) [Link] (2 responses)

A PC from 1983 can easily load two files (kernel + initrd) from a hard disk and put them where you want in memory, display possible messages in case of error or multiple choices (in a language and a font you like), handle the keyboard and the mouse. There is no need to multitask/multiprocess there.
Relying on BIOS to describe the hardware is obviously not a way forward, current hardware has properties which do not fit in the description structures designed in 1983.

Shuttleworth: ACPI, firmware and your security

Posted Mar 25, 2014 13:33 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

What description structures designed in 1983? The 1983-era BIOS didn't describe anything! The busses weren't self-describing, nothing was.

The description structures are mostly from the 90s (PCI, the bootloader protocol, DMI, and ACPI all got their start in that era, as did the thankfully-forgotten and halfwitted descriptive bits in APM).

Shuttleworth: ACPI, firmware and your security

Posted Mar 25, 2014 15:57 UTC (Tue) by etienne (guest, #25256) [Link]

> The 1983-era BIOS didn't describe anything!

Describe what you need to get to the next step: load two files in memory and run Linux.
For that, you need to know how many hard disk there is and few information on how to read them, you need to be able to display stuff in case of error, and you may need access to the keyboard/mouse if there are different solutions the user may choose.
I agree those interfaces have evolved over time in the BIOS since 1983, but backward compatibility was a major concern; you can have full graphic display and mouse support, CD/DVD reads, USB disks and mouse/keyboard on current PC (with basically the same interface).
What you really do not want to do is to have a real operating system at this level, querying the PCI, DMI and ACPI to detect how to read two files and display a possible error message, before running Linux which will redo the same querying in its own way.
A PC already probe once keyboard, screen and disks at boot (to display the BIOS setup and load the first sector of a disk), Linux will probe itself anyway all the information needed to run mutiprocessor with highly optimsed drivers, there is no need to probe in the bootloader.

Shuttleworth: ACPI, firmware and your security

Posted Mar 17, 2014 20:08 UTC (Mon) by yuhong (guest, #57183) [Link]

Well, every protected mode OS had to do the same thing.

Shuttleworth: ACPI, firmware and your security

Posted Mar 25, 2014 13:23 UTC (Tue) by nix (subscriber, #2304) [Link]

Except for SMI... and this new wonderful thing allowing people to inject microcode into the CPU, which will of course only ever be tested on Windows, or, if you're very lucky, one or two major distributions and one single kernel running $vendor's horrible binary-only module lump.

(Oh, and malware authors. They'll love this. Finally they can write their own SMIs! *Those* will be well-tested and nigh-undetectable.)

Shuttleworth: ACPI, firmware and your security

Posted Mar 17, 2014 20:04 UTC (Mon) by drag (guest, #31333) [Link]

I am a big fan of getting rid of most of the firmware, use the bootloader to do the basic initialization of the storage to get to the kernel and initrd loaded... and then having a configuration table that describes the hardware to the kernel so it knows how to run the power management features.

Shuttleworth: ACPI, firmware and your security

Posted Mar 17, 2014 14:17 UTC (Mon) by mgross (guest, #38112) [Link] (2 responses)

After reading his post I'm not sure he was talking of ACPI or uEFI. Still There needs to be some platform agent to provide for a cryptographic root of trust. I'm pretty sure that'll be more than just "declarative" execution for that.

Further ACPI enumeration of platform devices is declarative. It is true that ACPI does include interpreted code if the platform vendor chooses to use it, mostly for abstraction power state control so that drivers don't need to know schematic details on so many gpio pins. Or, to enable your laptop keyboards crazy function buttons, brightness, work with a common driver that mostly just works for some laptops. But, still those are only accessible through kernel drivers.

I think a more proper call to action is for the ACPI AML code be easier to audit and fix in a trusted manner buy device owners. (FWIW I'd extend it to the rest of the platform FW as well.)

But, ACPI bashing seems too easy these days and when bashing it one should be more specific on what sucks about it.

Shuttleworth: ACPI, firmware and your security

Posted Mar 17, 2014 16:43 UTC (Mon) by pabs (subscriber, #43278) [Link]

Mark appears to be railing against ACPI/UEFI on ARM when he says "Arguing for ACPI on your next-generation device is...". ACPI/UEFI on ARM was recently announced as the only way you will get RHEL on an ARM server:

https://plus.google.com/+JonMasters/posts/j5Vdu1LKv3b

Shuttleworth: ACPI, firmware and your security

Posted Mar 17, 2014 17:00 UTC (Mon) by exadon (guest, #5324) [Link]

What sucks is the missing transparency, you never know what's really going on. So the idea is to reduce the BIOS/ACPI/UEFI part to a minimum, that would be kernel loading and hardware discovery. Everything else should be handled by in-kernel drivers.

Shuttleworth: ACPI, firmware and your security

Posted Mar 17, 2014 17:05 UTC (Mon) by agrover (guest, #55381) [Link]

ACPI is a move away from secret firmware - it still lets the platform define platform-specific behavior -- which is an ongoing requirement -- but instead of actually calling into the firmware, it's actually the OS performing a series of operations defined by the firmware. This at least lets us SEE what is going on, either by runtime hooks into the AML interpreter, or by decompiling the bytecode in the ACPI DSDT. The time that the OS really loses control is when the BIOS enters SMM mode (which yes, can be triggered from ACPI). That's when you really have no idea what the firmware is doing.

Shuttleworth: ACPI, firmware and your security

Posted Mar 17, 2014 17:25 UTC (Mon) by yuhong (guest, #57183) [Link]

I believe that ARM SBSA is targeted at only servers, where even HP don't restrict access to firmware updates that solve security bugs.

ACPI has 99 problems, but security ain't one

Posted Mar 19, 2014 15:32 UTC (Wed) by psusi (guest, #95157) [Link]

ACPI is not a good attack vector since it is rather limited in what it can do, and can easily be filtered/blocked by the OS. If you can control the bios of a modern Intel CPU, then you can insert code that will run in system management mode and be able to do anything it wants without the OS knowing or having a way to stop it.

Shuttleworth: ACPI, firmware and your security

Posted Mar 21, 2014 10:04 UTC (Fri) by oliv3r (guest, #86764) [Link]

what bugs me here is,

a few months ago, Mark pretty much said that the focus wasn't on blob-less phones (ubuntu-touch)

That seems to me to be a 180 degree change of heart.


Copyright © 2014, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds