lkml.org 
[lkml]   [2001]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRE: ACPI fundamental locking problems
On Tue, 3 Jul 2001, Grover, Andrew wrote:

> We're depending on vendors (aka the BIOS) for all the ACPI tables, as well
> as every other piece of a priori data we need to boot the OS.

And this is the part that I find terrifying.
The minute we rely on BIOS vendors, they seem to find wonderful new
ways to screw things up royally.

> Could I please ask that you at least show me a system where this is a
> problem before throwing out all the work we've done on ACPI because of this
> technical nit?

Currently, with what we extract from BIOS space, we can
blacklist/whitelist according to DMI entries. With ACPI providing AML
code that's executed in kernel space, there's no telling what could
happen.

The whole "black box, you don't need to know how this works, just call it"
approach is scary. With ACPI having access to IDE taskfile commands, the
possibilities for all sorts of evil exist. Just when we thought the CPRM
nightmare was over, we have the BIOS feeding us IDE commands to throw
at drives with vendors telling us "Trust it, it's ok, really."

Maybe I'm overly paranoid, but I'm sure I'm not the only one who feels
this way.

regards,

Dave.

--
| Dave Jones. http://www.suse.de/~davej
| SuSE Labs

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:56    [W:0.065 / U:0.928 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site