ACPI AML

[Brendan]

Hi,

My plan is to use SMBIOS to get the motherboard vendor and product strings (where available), and get the PCI host controller's vendor ID and device ID (where available), and the PCI to LPC bridge's vendor ID and device ID (where available); and combine these things to form a "motherboard identifier". I'm also going to calculate a checksum of the firmware's AML. Then I'm going to have a set of "motherboard drivers" (as native code), where the OS uses the AML checksum and "motherboard identifier" to determine which motherboard driver to use. If there is no motherboard driver the OS will fall back to a "legacy mode" where there's no power management, etc (although it'd be possible to have a generic motherboard driver based on something like ACPICA that does use AML as a fall back, where "legacy mode" is used if there's no AML).

But diversity of such approach is really great! I'm afraid you would end up with a set of about dozen motherboard drivers multiplied by a dozen AML firmware versions. And it will never be close to the diversity of the real world, where we can find thousands of motherboards multiplied by thousands AML firmware versions. It means you almost always will fall back to "legacy mode".

You'd have "many to one mappings" where any number of different motherboard identifiers get mapped to the same motherboard driver.

May be it is better just to use ACPICA without serious attempts to organize all existing hardware?

That option isn't strictly excluded (e.g. you could have a generic motherboard driver based on ACPICA that the OS uses if nothing better is available). However, for my OS (and not necessarily anyone else's) I wouldn't want to encourage that (for my OS, I'd rather people have "legacy mode" and a reason to write "better than ACPI/AML" motherboard drivers, instead of giving them "good enough to destroy the motivation for better").

I was also considering moving all the ACPI code to userspace to be able to limit it where possible. Not going to be too useful though without VT-d as you can't abstract out device access to hardware at all, so any malicious AML code could still write to any actual memory through a device... so no security benefits there...

Only secure way to use AML is to not actually use it. What's the alternative?

There are no alternatives that allow you to safely use untrusted (potentially buggy and/or malicious) code for the motherboard. You are going to have to trust the code you use (regardless of whether it's native code designed for your OS, or the firmware's AML that was only ever tested on Windows and ACPICA).


Cheers,

Brendan

[Owen]

Note: Even if you don't trust the AML code, you still have to trust the SMM code, which exhibits more power.

Basically, trust the AML code (because you have to, and the hardware vendor is able to screw you over in millions of different ways anwyay), but absolutely do minimize its exposure to untrusted code (i.e. assume its full of security holes, therefore it should only be possible to interact with it from other trusted code or down narrow paths, such as "I'd like the machine to suspend now")