ACPI Stuff (was PCI IRQs with I/O APIC)

[embryo2]

Note that I'm planning to not use ACPI's AML - as far as I'm concerned it's a security problem at worst (e.g. "malicious AML" injected before OS boots), a stability problem at best (e.g. buggy AML) and an overcomplicated mess at all times.

It's a mess, but the security part is easily circumvented by calculating a CRC after the first boot and writing it in a signed file on a flash drive, which is also required for CRC of the BIOS code and the OS stuff. It means instead of a simple way you still prefer the hardest possible without a real rationale behind it.

[alexg]

I have a question, for processors which use platform controller hub aren't the mappings from PCI interrupt pins to physical pins specified in the Device Interrupt Route Registers of the chipset configuration registers?
I didn't take time to investigate this because all the PCI devices I'm interested in are MSI capable. See http://www.intel.com/content/dam/www/pu ... asheet.pdf sections 10.1.26 - 10.1.34 for details.

Edit: I just read section 5.10 of the PCH specification and table 5-16 makes me believe by default IO APIC entries 16 - 19 correspond to #INTA -> #INTD and the way the internal devices are re-routed is described through the Interrupt Route Registers.

[Brendan]

Hi,

Note that I'm planning to not use ACPI's AML - as far as I'm concerned it's a security problem at worst (e.g. "malicious AML" injected before OS boots), a stability problem at best (e.g. buggy AML) and an overcomplicated mess at all times.

It's a mess, but the security part is easily circumvented by calculating a CRC after the first boot and writing it in a signed file on a flash drive, which is also required for CRC of the BIOS code and the OS stuff.

So the OS takes a CRC of the malicious AML when the OS is installed; and then whenever the AML changes (firmware is updated, BIOS settings are changed, etc) the OS stops working?

It means instead of a simple way you still prefer the hardest possible without a real rationale behind it.

A bare AML interpreter probably isn't that hard to implement on its own, but that's just the tip of the iceberg. To use AML properly you have to tell it that the OS is a recent version of Windows (otherwise the firmware/AML suppresses various features), and when you tell AML the OS is a recent version of Windows the OS has to behave like a recent version of Windows (which is extremely difficult/undocumented). Basically, writing my own equivalent of ACPICA is an extremely bad idea.

Porting ACPICA would require a C compiler that understands my executable file format (and is able to generate my byte-code); and for normal software I have no intention of ever supporting C; and I do want the OS to be self hosting one day. This means that to port ACPICA I'd mostly have to write a C compiler that would only ever be used for ACPICA and nothing else. That's also an extremely bad idea.

By providing motherboard drivers I can include features that ACPI doesn't support, and in that way (if a motherboard driver exists) the OS can be superior to everything else. For one example, the motherboard driver can reconfigure the physical address space (and get rid of things like the "legacy ROM" areas). For another example; I plan to include (simplified) 3D models of all hardware (including the motherboard) so that people can see exactly where different PCI and RAM slots are (for hardware upgrades, faults, etc). If the OS detects that RAM at physical address 0x1234567 is faulty then it should be able to correctly identify which RAM module in which slot needs to be replaced (where figuring out the relationship between physical address and RAM module is excessively difficult without a motherboard/chipset driver to start with) and should then be able to show a maintenance person where that RAM module is so they don't accidentally replace the wrong RAM module.

Note that this also means being able to supporting old hardware well; including old hardware with old AML that doesn't include features that were introduced in later versions of ACPI, and including ancient hardware that doesn't support ACPI at all.

For a variety of purposes (embedded systems, high-end HPC, etc) I also want to support "boot from ROM" where the firmware is the OS's boot loader and boot files (kernel, drivers, etc). In this case providing motherboard drivers means that whoever creates a "boot from ROM boot loader" doesn't have to bother with ACPI, AML and some of the SMM stuff.

Don't forget that I could implement a kind of "motherboard driver builder" utility that auto-converts ACPI's AML into initial source code for a motherboard driver; where to create a motherboard driver a programmer would start by using this utility to get all the boilerplate out of the way, and would then double check and tweak the auto-generated code, and then fill in things that AML doesn't support. Also don't forget that (if I find out later that I have no choice) nothing would really prevent me from having a "generic motherboard driver" that does use AML internally, and having that as a fall-back for cases where there's no (more suitable) motherboard driver.

Finally; there's marketing. By proudly claiming "doesn't rely on ACPI/AML" most people (who don't have any idea what AML is or what it does) will assume that there's something wrong with AML and therefore something wrong with other OSs. It doesn't matter much if there is or isn't anything wrong with AML. The fact that it's easy to find/show cases where AML has been a problem for other OSs just makes it easier to convince people that "doesn't rely on ACPI/AML" is a good thing (and convince people that there is something wrong with other OSs). Even just a brief look at the ACPI Wikipedia page is probably enough to convince the majority of people that "doesn't rely on ACPI/AML" is a good thing (e.g. "In November 2003, Linus Torvalds—author of the Linux kernel—described ACPI as "a complete design disaster in every way". In 2001, other senior Linux software developers like Alan Cox expressed concerns about the requirements that bytecode from an external source must be run by the kernel with full privileges, as well as the overall complexity of the ACPI specification. In 2014, Mark Shuttleworth, founder of the Ubuntu Linux distribution, compared ACPI with Trojan horses.").


Cheers,

Brendan

[kzinti]

Here is an interesting article on what Brendan is talking about:

http://www.ssi.gouv.fr/uploads/IMG/pdf/article_acpi.pdf

Section 3 "Security Issues with ACPI" is especially interesting.

Basically if you use ACPI, you are screwed. If you are not, you are screwed. Great stuff.

[Brendan]

Hi,

I have a question, for processors which use platform controller hub aren't the mappings from PCI interrupt pins to physical pins specified in the Device Interrupt Route Registers of the chipset configuration registers?
I didn't take time to investigate this because all the PCI devices I'm interested in are MSI capable. See http://www.intel.com/content/dam/www/pu ... asheet.pdf sections 10.1.26 - 10.1.34 for details.

These registers determine which PCI IRQs are used by devices that are built into the PCH (and tell you nothing about devices plugged into PCI slots).

Edit: I just read section 5.10 of the PCH specification and table 5-16 makes me believe by default IO APIC entries 16 - 19 correspond to #INTA -> #INTD and the way the internal devices are re-routed is described through the Interrupt Route Registers.

It's relatively common (sort of) for chipset to connect #INTA -> #INTD to IO APIC input 16 to 19; but nothing requires or guarantees this.

Note that what you're looking at is not a "PCH specification" that applies to all chipsets and all manufacturers. It's a datasheet that only applies to a relatively small number of PCH chips made by Intel. Basically; this information is completely useless, unless you're writing a chipset specific (or motherboard specific) driver specifically for motherboards that use a PCH covered by that specific datasheet.


Cheers,

Brendan

[embryo2]

So the OS takes a CRC of the malicious AML when the OS is installed; and then whenever the AML changes (firmware is updated, BIOS settings are changed, etc) the OS stops working?

If you want trusted computing then you must buy trusted hardware. Where's the AML's place in the picture of missed efforts?

A bare AML interpreter probably isn't that hard to implement on its own, but that's just the tip of the iceberg. To use AML properly you have to tell it that the OS is a recent version of Windows (otherwise the firmware/AML suppresses various features), and when you tell AML the OS is a recent version of Windows the OS has to behave like a recent version of Windows (which is extremely difficult/undocumented).

Can you be more specific on it? What part of AML behaves in an unspecified manner? I mean the ACPI specification. If your parser detects something non standard, then who in the world insists you should use such an inconsistent part of the ACPI data?

Basically, writing my own equivalent of ACPICA is an extremely bad idea.

Is it the conclusion you have managed to come to after the Windows specific behavior of AML cornered you into an inescapable trap? Is this trap really inescapable? Or the escape costs on par with writing a lot of motherboard drivers?

Porting ACPICA would require a C compiler that understands my executable file format (and is able to generate my byte-code);

Why? As far as I know there's a call convention defined in the specification. Can you create a structure in memory, change stack pointer and call the ACPICA stuff without any knowledge of C?

and I do want the OS to be self hosting one day.

Then you can create your own AML interpreter. Does it cost more than a thousand of motherboard drivers?

By providing motherboard drivers I can include features that ACPI doesn't support, and in that way (if a motherboard driver exists) the OS can be superior to everything else. For one example, the motherboard driver can reconfigure the physical address space (and get rid of things like the "legacy ROM" areas).

Is the legacy ROM area configurable on all motherboards? And how long it will take to collect the information about such a kind of configuration (which is not implemented even by the motherboard vendor)?

For another example; I plan to include (simplified) 3D models of all hardware (including the motherboard) so that people can see exactly where different PCI and RAM slots are (for hardware upgrades, faults, etc). If the OS detects that RAM at physical address 0x1234567 is faulty then it should be able to correctly identify which RAM module in which slot needs to be replaced (where figuring out the relationship between physical address and RAM module is excessively difficult without a motherboard/chipset driver to start with) and should then be able to show a maintenance person where that RAM module is so they don't accidentally replace the wrong RAM module.

Nice idea. But what's wrong with the AML here? How the AML prevents you from gathering spatial data for a motherboard? I don't know if the RAM module information is provided by the AML, but at least I see the device configuration objects and things like NUMA nodes location information. So, if the required information is provided by the AML, then what a point in refusing to use it (and collecting it yourself)?

Note that this also means being able to supporting old hardware well; including old hardware with old AML that doesn't include features that were introduced in later versions of ACPI, and including ancient hardware that doesn't support ACPI at all.

Well, the old hardware adds a bit to your information collection efforts. The old hardware manufacturers didn't know the way you can find new features in the ancient things. But you, of course, do know it. Are you serious?

For a variety of purposes (embedded systems, high-end HPC, etc) I also want to support "boot from ROM" where the firmware is the OS's boot loader and boot files (kernel, drivers, etc). In this case providing motherboard drivers means that whoever creates a "boot from ROM boot loader" doesn't have to bother with ACPI, AML and some of the SMM stuff.

Is it now about a new BIOS vendor arrival? But have you explored the market before such a journey? It differs a bit from the OS market.

Don't forget that I could implement a kind of "motherboard driver builder" utility that auto-converts ACPI's AML into initial source code for a motherboard driver; where to create a motherboard driver a programmer would start by using this utility to get all the boilerplate out of the way, and would then double check and tweak the auto-generated code, and then fill in things that AML doesn't support.

Do you mean your "double check and tweak" solves the security issue with the untrusted hardware? A hundred pages of cryptic text is really helpful here.

Also don't forget that (if I find out later that I have no choice) nothing would really prevent me from having a "generic motherboard driver" that does use AML internally, and having that as a fall-back for cases where there's no (more suitable) motherboard driver.

It would be wise to create the "fall-back" driver and after some time just to forget about the world-wide contest "let's try to find a hardware information".

By proudly claiming "doesn't rely on ACPI/AML" most people (who don't have any idea what AML is or what it does) will assume that there's something wrong with AML

It's much simpler to claim "doesn't rely on Windows", for example. The effect will be even better.

Even just a brief look at the ACPI Wikipedia page is probably enough to convince the majority of people that "doesn't rely on ACPI/AML" is a good thing

Well, again it's easier to point to something like this piece of information about everything and nothing in particular and claim "you shouldn't use Brendan's firmware, just because you are unable to read a few pages from the wiki". And yes, there also is the part about security risks (for the very informed part of the users who make decisions after reading ACPI wiki article).

[Brendan]

Hi,

So the OS takes a CRC of the malicious AML when the OS is installed; and then whenever the AML changes (firmware is updated, BIOS settings are changed, etc) the OS stops working?

If you want trusted computing then you must buy trusted hardware. Where's the AML's place in the picture of missed efforts?

I don't understand your question (I get a parse error for "the picture of missed efforts").

Security and trustworthiness can never be perfect; and the goal is always to improve security and trustworthiness (regardless of what the hardware is).

A bare AML interpreter probably isn't that hard to implement on its own, but that's just the tip of the iceberg. To use AML properly you have to tell it that the OS is a recent version of Windows (otherwise the firmware/AML suppresses various features), and when you tell AML the OS is a recent version of Windows the OS has to behave like a recent version of Windows (which is extremely difficult/undocumented).

Can you be more specific on it? What part of AML behaves in an unspecified manner? I mean the ACPI specification. If your parser detects something non standard, then who in the world insists you should use such an inconsistent part of the ACPI data?

Just grab an AML disassembler (there's one in virtually every Linux distro) and take a look at your own (real not virtual) computer's AML. Look for anything that depends on the "\_OS" object.

I found a random AML disassembly here if you couldn't be bothered. If you look at this you'll find a method called "OSFL" that contains a few lines like "If (MCTH (\_OS, "Microsoft Windows NT"))" and "If (MCTH (\_OS, "Microsoft WindowsME: Millennium Edition"))" and "If (\_OSI ("Windows 2001"))". These checks end up setting a variable called OSVR to different values (depending on what the OS told ACPI it is), and this OSVR variable is returned by the method. Then you'll notice that this "OSFL" method is called from all over the place in lines like "If (LEqual (OSFL (), 0x00))". Also note that if AML doesn't recognise the "OS name" that the OS provides (e.g. because the OS said "Linux" or "Ubuntu" or "BCOS" or "Embryo's OS") you end up with "OSVR = 0x00" and severely reduced functionality.

Note that it's not just the "\_OS" name, there's also "_OSI" (Operating System Interfaces") which takes an OS defined string (representing a certain feature/interface) that an OS uses to ask ACPI if a certain (OS specific) feature is supported.

Essentially, the behaviour of most of the AML changes depending on what the OS says it is; and these differences in behaviour depend on what Microsoft felt like doing and are not documented anywhere (that I know of). This is why it took a team of Intel developers about 10 years to get ACPICA to work properly (even though they probably could've done the "AML interpreter" alone in less than 6 months). It's also why OSs that aren't Windows have to lie to ACPI and say they are a version of Windows (so they don't end up with "minimal functionality AML").

Basically, writing my own equivalent of ACPICA is an extremely bad idea.

Is it the conclusion you have managed to come to after the Windows specific behavior of AML cornered you into an inescapable trap? Is this trap really inescapable? Or the escape costs on par with writing a lot of motherboard drivers?

You can't avoid the "Windows specific behaviour" trap. With a lot of work you could figure out the Windows specific behaviour; but you'd have to do that for each different "OS name" Microsoft uses (in the past, now, and in the future) and each "_OSI" OS defined string that Microsoft define.

Porting ACPICA would require a C compiler that understands my executable file format (and is able to generate my byte-code);

Why? As far as I know there's a call convention defined in the specification. Can you create a structure in memory, change stack pointer and call the ACPICA stuff without any knowledge of C?

If I could compile ACPICA (with a compiler that will never exist) and link it to something else (with a linker that will never exist); then calling it would be mostly trivial.

and I do want the OS to be self hosting one day.

Then you can create your own AML interpreter. Does it cost more than a thousand of motherboard drivers?

Again, the AML interpreter alone is just the tip of the iceberg (almost completely useless without a huge amount of other code, plus a whitelist/blacklist, plus "replacement AML" for all the known buggy computers).

Your comparison is like comparing an over-priced turd sandwich to a reasonably priced porterhouse steak. The steak might (or might not) be a little more expensive, but who wants to eat turd?

By providing motherboard drivers I can include features that ACPI doesn't support, and in that way (if a motherboard driver exists) the OS can be superior to everything else. For one example, the motherboard driver can reconfigure the physical address space (and get rid of things like the "legacy ROM" areas).

Is the legacy ROM area configurable on all motherboards? And how long it will take to collect the information about such a kind of configuration (which is not implemented even by the motherboard vendor)?

For all "modern" (since about 1995) 80x86 motherboards the legacy ROM area/s used by devices (e.g. video card, etc) can be converted to normal RAM. The legacy ROM area used by BIOS itself can too, but doing that is too risky (without some extensive testing) because you can't be sure if the BIOS' SMM code relies on it under certain conditions. You can also get rid of the "legacy VGA" area, but often the RAM underneath is locked for "SMM only" (and that can't be changed) so getting rid of "legacy VGA" area doesn't help. In some cases (e.g. if other RAM is used for SMM and the legacy BIOS area isn't called from SMM) you can convert the physical address space so that you've got a single unfragmented slab of RAM at 0x00000000 with none of the typical junk in the first 1 MiB. Of course all of this requires chipset/motherboard specific knowledge (and isn't supported by ACPI/AML). Note that when combined with a "boot from ROM boot loader" you don't have to worry so much about SMM (because the firmware is yours and not "unknown") and can do a better job.

For Intel's chipsets it's typically well documented by their datasheets. For other manufacturers it can be hard to get documentation (and in that case I'd just skip it). The OS would also need to do some other things to make it work properly (reprogram MTRRs so the RAM is cached properly, add the recovered RAM to its physical memory manager so it can be used, etc).

For another example; I plan to include (simplified) 3D models of all hardware (including the motherboard) so that people can see exactly where different PCI and RAM slots are (for hardware upgrades, faults, etc). If the OS detects that RAM at physical address 0x1234567 is faulty then it should be able to correctly identify which RAM module in which slot needs to be replaced (where figuring out the relationship between physical address and RAM module is excessively difficult without a motherboard/chipset driver to start with) and should then be able to show a maintenance person where that RAM module is so they don't accidentally replace the wrong RAM module.

Nice idea. But what's wrong with the AML here? How the AML prevents you from gathering spatial data for a motherboard? I don't know if the RAM module information is provided by the AML, but at least I see the device configuration objects and things like NUMA nodes location information. So, if the required information is provided by the AML, then what a point in refusing to use it (and collecting it yourself)?

For everything that AML doesn't support, AML doesn't support it. This means that (if you want to do things that AML doesn't support, like determine the relationship between physical addresses and RAM modules, or like providing 3D models) you have to provide motherboard specific info and/or code regardless of whether you use AML or not. If you're providing motherboard drivers regardless of whether you use AML or not, then there isn't as much reason to bother with AML in the first place.

Note that this also means being able to supporting old hardware well; including old hardware with old AML that doesn't include features that were introduced in later versions of ACPI, and including ancient hardware that doesn't support ACPI at all.

Well, the old hardware adds a bit to your information collection efforts. The old hardware manufacturers didn't know the way you can find new features in the ancient things. But you, of course, do know it. Are you serious?

I don't understand your question.

For a 20 year old motherboard (e.g. from before ACPI existed), it's no different to writing a motherboard driver for a new motherboard - you can still get information from the datasheet, still support whatever features the hardware supports (without bothering with older interfaces like APM), still create a 3D model, etc.

For a variety of purposes (embedded systems, high-end HPC, etc) I also want to support "boot from ROM" where the firmware is the OS's boot loader and boot files (kernel, drivers, etc). In this case providing motherboard drivers means that whoever creates a "boot from ROM boot loader" doesn't have to bother with ACPI, AML and some of the SMM stuff.

Is it now about a new BIOS vendor arrival? But have you explored the market before such a journey? It differs a bit from the OS market.

Normally I provide a "firmware development kit" with working example code for Bochs; so that (eventually) if someone wants to write a "boot from ROM boot loader" they only need to worry about writing/modifying any motherboard/chipset specific things that are needed before the OS starts. Of course the OS does things like (re)configuring PCI buses and bridges itself so "boot from ROM boot loader" firmware doesn't have to bother with any of that, and the OS would have a "motherboard driver" so that the "boot from ROM boot loader" firmware doesn't have to bother with any of that either.

Don't forget that I could implement a kind of "motherboard driver builder" utility that auto-converts ACPI's AML into initial source code for a motherboard driver; where to create a motherboard driver a programmer would start by using this utility to get all the boilerplate out of the way, and would then double check and tweak the auto-generated code, and then fill in things that AML doesn't support.

Do you mean your "double check and tweak" solves the security issue with the untrusted hardware? A hundred pages of cryptic text is really helpful here.

I wouldn't expect anyone to use source code auto-generated by a "clever" utility without bothering to check it. I wasn't planning to provide a hundred pages of cryptic text (and have no idea where you got a silly idea like that from). It'd generate normal source code, with normal/descriptive function names, and with comments (like "// Code to determine IO APIC input from PCI slot" and "// Add code to support FOO here!"), etc.

Also don't forget that (if I find out later that I have no choice) nothing would really prevent me from having a "generic motherboard driver" that does use AML internally, and having that as a fall-back for cases where there's no (more suitable) motherboard driver.

It would be wise to create the "fall-back" driver and after some time just to forget about the world-wide contest "let's try to find a hardware information".

No. As soon as I provide a "generic motherboard driver" I destroy any hope that people will ever bother to write motherboard drivers that don't suck, and the OS will suck forever.

Even just a brief look at the ACPI Wikipedia page is probably enough to convince the majority of people that "doesn't rely on ACPI/AML" is a good thing

Well, again it's easier to point to something like this piece of information about everything and nothing in particular and claim "you shouldn't use Brendan's firmware, just because you are unable to read a few pages from the wiki". And yes, there also is the part about security risks (for the very informed part of the users who make decisions after reading ACPI wiki article).

Not sure how your comment is supposed to make any sense at all. I'm not providing any firmware (other than for open source emulators where it's easier); and if I was providing firmware then people would be choosing between an existing proprietary blob that came with their computer and firmware provided by the same person that wrote the OS they're using (who they must've trusted already or they wouldn't be using the OS in the first place).


Cheers,

Brendan

[Rusky]

It would be interesting to see how much windows-specific functionality typical AML actually depends on, as opposed to just the OS name. It may turn out to be easier to reverse-engineer that than it would be to figure things out from scratch, since there's probably even less documentation available in the latter case.

[kzinti]

It would be interesting to see how much windows-specific functionality typical AML actually depends on, as opposed to just the OS name. It may turn out to be easier to reverse-engineer that than it would be to figure things out from scratch, since there's probably even less documentation available in the latter case.

It's actually pretty bad. Basically firmwares change their behaviour based on what the OS says it is. The reason vendors do this is to ensure that their motherboard works with major OSes when released (and that basically means Windows, Linux and maybe FreeBSD / Fedora). They will hard code things in their ACPI tables until it works to their satisfaction, and then ship it.

More details here:

Why Linux claims to be Windows: http://mjg59.livejournal.com/85923.html

ACPI, kernels and contracts with firmware: https://mjg59.dreamwidth.org/32369.html

[Rusky]

Sure, I get the mechanism through which the problem manifests. I'm looking more for specific examples of its extent. The only thing resembling specifics in those posts are "backlights" and "HPET," but I could have guessed those from "ACPI." Do we have any databases of what Linux maintainers have reverse engineered and what they haven't, for example?

[Schol-R-LEA]

@embryo2 - The very fact that you are using marketing catchphrases such as 'Trusted Computing', 'Cloud Computing', and 'Managed Code' as if they had technical meaning indicates to me that you don't really know anything about those phrases or what they imply.

This is especially evident here, because 'Trusted Computing' isn't a term in computer security at all; security is all about not trusting anything until it has been independently verified by some means separate from it's source, and continuing to re-check things to make sure that nothing is getting inserted from some uncontrolled (or even unknown) channel.

It is especially ridiculous to discuss 'Trusted Computing' in this context, since in practice the term really translates to 'block any OS other than the one we have created/licensed from running' and 'only run software the hardware and OS vendors do not see as a threat to their business'. The whole point of 'Trusted Computing' is to lock down the system, and open source software - especially hobbyist software - is not in that picture at all.

To put it bluntly, if Trusted Computing were actually universal, your beloved Java wouldn't be allowed to run on the next generation of hardware and software at all - and that includes on Oracle's own Linux distro, since their whole purpose in purchasing Sun was to dismantle those parts of their technology which were a threat to Oracle's bottom line (MySQL and StarOffice, primarily - while they have kept a remnant of MySQL alive for existing users, they have made it clear that it is just as a way to redirect those clients back into the Oracle herd), and the only reason they haven't dropped Java into the memory hole is because they get a small amount of revenue from the Certification testing garbage (and believe me, having passed one of those certification tests myself, I can tell you right now that they are utterly meaningless as a gauge of a programmer's ability).

Mind you, 'Unbreakable Linux' itself is primarily designed as an attempt at co-opting FOSS by trying to get the customers to rely on the parts that aren't free, and an utterly failed attempt at that, but I've pointed to enough skyclad monarchs for one day.

[embryo2]

If you want trusted computing then you must buy trusted hardware. Where's the AML's place in the picture of missed efforts?

I don't understand your question (I get a parse error for "the picture of missed efforts").

It means you need to do something to ensure that millions PCs are sold not with the purpose to distribute a secret rootkit and to track personally you with it. To ensure it you can convert the AML into the ASL form and read it carefully. It is an example of an effort required. But if you aren't bothered with such efforts, then how AML can help you or hurt you? It can't. Because it have no connection with your will to spend some time on required efforts.

Just grab an AML disassembler (there's one in virtually every Linux distro) and take a look at your own (real not virtual) computer's AML. Look for anything that depends on the "\_OS" object.

_OS and _OSI things are used by vendors to circumvent some hacks the big boys sometime use. It's not the intention of the _OS and _OSI to lie to you. A vendor just must to implement something in a non standard way if Microsoft wants it. But the standard is aware of such behavior and gives vendors a back door for their products to be compatible. And there's no intention to limit somehow other OSes by the means of _OS or _OSI. Vendors implement different ways to achieve the same result for Microsoft and for other OSes. The only problem with such approach is the testing efforts required. In case of Microsoft a vendor has almost unlimited testing support (hundreds millions of users will test it), while in case of "generic OS" the tests are performed only by the vendor's testing lab. It means there could be bugs and even some missed functionality (due to project timelines and easyness of low priority problem fixing postponement). But it doesn't mean the difference between "a Microsoft way" and "generic OS way" of implementing hardware features must be too serious. And the outcry of some bloggers is mostly due to the "it's unfair to be big!" emotional thinking.

You can't avoid the "Windows specific behaviour" trap. With a lot of work you could figure out the Windows specific behaviour; but you'd have to do that for each different "OS name" Microsoft uses (in the past, now, and in the future) and each "_OSI" OS defined string that Microsoft define.

I can use generic approach. If I meet some serious problem, then I can think about some hacks like tracing the Windows specific behavior. But while there's no information about how great is the difference - it's just a kind of panic if you decide that it's better to implement a thousand motherboard drivers than just to select the generic approach. The standard way most probably will lead to the lesser amount of efforts spent. And it is very probable that the difference will represent itself in the range from 2 to 3 orders of magnitude.

If I could compile ACPICA (with a compiler that will never exist) and link it to something else (with a linker that will never exist); then calling it would be mostly trivial.

Do you mean it's too hard for you to build the ACPICA on a Linux PC?

Again, the AML interpreter alone is just the tip of the iceberg (almost completely useless without a huge amount of other code, plus a whitelist/blacklist, plus "replacement AML" for all the known buggy computers).

What is the purpose of the "huge amount of other code"? What is the purpose of the whitelist/blacklist? How big is the problem with buggy computers?

Essentially, you are claiming, that the cost of dealing with buggy computers is higher than the cost of gathering low level information for all the mentioned buggy computers plus all not mentioned bug free computers followed by the thousand driver development efforts. And the "thousand driver development efforts" include the efforts spent on development the AML for all mentioned and not mentioned computers.

What is bigger, a key or the the door and the lock you are going to replace because of "too dirty" key?

For all "modern" (since about 1995) 80x86 motherboards the legacy ROM area/s used by devices (e.g. video card, etc) can be converted to normal RAM.

Do you mean the normally workable areas of RAM are hidden and replaced with the memory mapped registers and ROM? And it is implemented in a standardized manner?

If it is the case then you can obtain some megabyte of additional memory (in contrast with tenths of gigabytes available). But at what cost? At the cost of collecting the information for thousands of motherboards? Followed by the time, required for the implementation of the thousands of drivers.

For Intel's chipsets it's typically well documented by their datasheets. For other manufacturers it can be hard to get documentation (and in that case I'd just skip it).

Well, now you have limited the scope to the Intel's motherboards only. But do you know this - Intel discontinues mainboard development?

And do you know the market share of the produced Intel motherboards? It's not exciting.

For everything that AML doesn't support, AML doesn't support it.

I'm sorry for not being ACPI expert, but your claim "just trust me" is of little help to me.

Well, the old hardware adds a bit to your information collection efforts. The old hardware manufacturers didn't know the way you can find new features in the ancient things. But you, of course, do know it. Are you serious?

I don't understand your question.

It means with the old hardware in question you are required to develop even more motherboard drivers. And to find even more information. And to do it in such a manner that modern standards won't be affected (a special code for old hardware in addition to the already large code for the new hardware). And to somehow maintain your leading edge over the Windows you just need to implement more feature than was available for Windows in the old hardware. You should be creative and find ways to squeeze some resemblance of the modern hardware behavior from the old motherboards (or do you want two OSes, one for new hardware and one for the old?).

For a 20 year old motherboard (e.g. from before ACPI existed), it's no different to writing a motherboard driver for a new motherboard - you can still get information from the datasheet, still support whatever features the hardware supports (without bothering with older interfaces like APM), still create a 3D model, etc.

Would the information be always available and your time were unlimited, then yes - it would be possible to redefine the world. But I'm afraid that not all conditions are present.

Normally I provide a "firmware development kit" with working example code for Bochs; so that (eventually) if someone wants to write a "boot from ROM boot loader" they only need to worry about writing/modifying any motherboard/chipset specific things that are needed before the OS starts.

The kit is an interesting idea. But do you mean the hardest part (information and implementation) should be performed by the others? It's not the attractive case for the majority of developers.

Do you mean your "double check and tweak" solves the security issue with the untrusted hardware? A hundred pages of cryptic text is really helpful here.

I wouldn't expect anyone to use source code auto-generated by a "clever" utility without bothering to check it. I wasn't planning to provide a hundred pages of cryptic text (and have no idea where you got a silly idea like that from). It'd generate normal source code, with normal/descriptive function names, and with comments (like "// Code to determine IO APIC input from PCI slot" and "// Add code to support FOO here!"), etc.

I suppose you know that reading the ASL is not a very hard exercise. And even if there's no comments like "it is for PCI, stupid!" it's still perfectly readable and the amount of efforts required to understand it's logic is not essentially bigger, than the efforts required to understand your auto-generated code.

And you can note an interesting thing - while the ASL is available for virtually every Linux user, they still are concerned with the rootkits and everything alike. May be there is something wrong with your reasoning?

Also don't forget that (if I find out later that I have no choice) nothing would really prevent me from having a "generic motherboard driver" that does use AML internally, and having that as a fall-back for cases where there's no (more suitable) motherboard driver.

It would be wise to create the "fall-back" driver and after some time just to forget about the world-wide contest "let's try to find a hardware information".

No. As soon as I provide a "generic motherboard driver" I destroy any hope that people will ever bother to write motherboard drivers that don't suck, and the OS will suck forever.

You are too quick to change your mind towards the hardest stance possible.

[embryo2]

@embryo2 - The very fact that you are using marketing catchphrases such as 'Trusted Computing', 'Cloud Computing', and 'Managed Code' as if they had technical meaning indicates to me that you don't really know anything about those phrases or what they imply.

May be. But the words "trusted" and "computing" (hopefully) have relatively standard meaning. So, what's wrong in using the combined meaning of the words? Is it just a marketing problem?

security is all about not trusting anything until it has been independently verified by some means separate from it's source, and continuing to re-check things to make sure that nothing is getting inserted from some uncontrolled (or even unknown) channel.

And that's why I suggested the CRC and signed file with it on a flash drive that a user always can hold very close to himself. The case of hacked hardware is missed here, but I hope that people concerned with such a threat can afford to pay for a guard for the hardware (and for the system of monitoring the guard with another guard who is also always monitored and so on).

It is especially ridiculous to discuss 'Trusted Computing' in this context, since in practice the term really translates to 'block any OS other than the one we have created/licensed from running' and 'only run software the hardware and OS vendors do not see as a threat to their business'. The whole point of 'Trusted Computing' is to lock down the system, and open source software - especially hobbyist software - is not in that picture at all.

It's possible for a hobbyist to create a trusted flash drive and to let it to check a system before OS (Windows, for example) can start. The case with infected BIOS, unfortunately, requires some additional hardware to check the BIOS before it can act maliciously. But it's not very expensive hardware.

To put it bluntly, if Trusted Computing were actually universal, your beloved Java wouldn't be allowed to run on the next generation of hardware and software at all

The world just can't afford the cost of the "universal" trusted computing. It means there always be things like Java.

that includes on Oracle's own Linux distro, since their whole purpose in purchasing Sun was to dismantle those parts of their technology which were a threat to Oracle's bottom line (MySQL and StarOffice, primarily - while they have kept a remnant of MySQL alive for existing users, they have made it clear that it is just as a way to redirect those clients back into the Oracle herd), and the only reason they haven't dropped Java into the memory hole is because they get a small amount of revenue from the Certification testing garbage (and believe me, having passed one of those certification tests myself, I can tell you right now that they are utterly meaningless as a gauge of a programmer's ability).

Mind you, 'Unbreakable Linux' itself is primarily designed as an attempt at co-opting FOSS by trying to get the customers to rely on the parts that aren't free, and an utterly failed attempt at that, but I've pointed to enough skyclad monarchs for one day.

While such conspiracy in fact had taken some place it is still limited by the unpredictability of the market. Oracle or Microsoft or whatever haven't predicted the emergence of Google with it's Windows rival, for example. They just react accordingly. And it means new emerging world is possible and it knows the exact form of the reaction it will meet (so, it is armed).

[Schol-R-LEA]

@embryo2 - The very fact that you are using marketing catchphrases such as 'Trusted Computing', 'Cloud Computing', and 'Managed Code' as if they had technical meaning indicates to me that you don't really know anything about those phrases or what they imply.

May be. But the words "trusted" and "computing" (hopefully) have relatively standard meaning. So, what's wrong in using the combined meaning of the words? Is it just a marketing problem?

The problem is that the words aren't being used in the standard manner, but instead are being used as a label for something unrelated, and the creators of the term are counting on people missing that and assuming that it is meant to be using the conventional definitions of the words. It's a fairly typical form of deception similar to the use of the term 'natural flavoring' in food labels - most 'natural flavoring' is called that because it uses the same esters or flavinoids that give some fruit or vegetable a flavor or odor, but the chemicals actually used are often synthesized ones rather than extracts; they can get away with this only because the terms 'natural' and 'flavoring' have no legal definition, and that's all that matters in a deceptive practices case.

In both cases, the combination of the two words is being presenting as having one meaning, but actually have a different meaning (or none at all), and are used in a way such that most people won't notice the verbal sleight-of-hand.

Consider this: what are 'Grape-Nuts'? Grape seeds? Some sort of nut? No, it is just a trademarked name for a brand of granola, and it has neither grapes nor nuts in it, but because it is being used as a label rather than a description, the US courts ruled that the term was not fraud because it was just a name rather than a statement of the product's properties. That doesn't mean that the name doesn't imply a level of healthfulness that it doesn't actually possess.

[Schol-R-LEA]

I mentioned 'Cloud Computing', which brings up another form of deceptive descriptions: putting a new name on something established and presenting it as something innovative. All that 'working on the cloud' really means is 'accessing an offsite backup remotely', which has been around since the 1980s. While the technology of 'cloud computing' has been refined greatly since then, most of the changes are in the internetworking infrastructure (i.e., have more to do with the demand for streaming porn than with business uses), the degree of redundancy (i.e., having several copies in physically separated server farms) and the degree of automation; under the web front ends, it's the same old process. It is just barely justifiable in that it refers to a new set of uses for the technology, but it isn't a technical term.

Both of these deceptive practices apply the term 'Managed Code', which not only is just a collection of established techniques, said collection is not really about 'managing' anything - as I have pointed out before, the original purpose for 'managed code' as used by Microsoft was to wean the Windows software base off of its reliance on the x86 platform, which they assumed was at a dead end and would lose most of its market share by 2005 or so as it got replaced by Itanium and various competing RISC designs. Similarly, 'Java Everywhere' was originally aimed at making it easier for customers to switch from PCs (and Vaxen, since DEC was still a going concern when the Oak project was started in 1991) to Sun workstations, by cutting the applications' ties to the hardware platform. Funny, neither of those things actually worked out, did they?