Shuttleworth: ACPI, firmware and your security

Posted Mar 17, 2014 14:21 UTC (Mon) by bronson (subscriber, #4806)
In reply to: Shuttleworth: ACPI, firmware and your security by bersl2
Parent article: Shuttleworth: ACPI, firmware and your security

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