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

[embryo2]

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

But who has problems because of it? If some creative marketer has invented a new slogan then what? Should all other people change their understanding of the words used by the marketer?

It's mostly the business problem how to convince people not to ask something that is obvious from the meaning of the combination of words. And if the problem solved by an invention of a new meaning of a phrase then such phrase become "vendor specific" in the areas where a particular business works. But in all other areas the meaning never changes.

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.

Everybody can use a very simple approach here - if you want to use a product of a business then you just must to find a lot of information about the product in whatever form it is delivered by the business (including vendor specific combinations of words and the perverted meaning of such combinations). But if you do not want the product (as is the case when we talk here about trusted computing) then why in the hell we should restrict our understanding by the marketing invented perverted meaning?

All that 'working on the cloud' really means is 'accessing an offsite backup remotely'

It's not correct meaning.

There is data and there is processing. The clouds today use the processing part very extensively. Of course, there is still some data which is transferred between a server and a client, but it's nowhere close to the backup on many cloud platforms. For example - is a web server just a backup of something? But cloud based sites today are everywhere.

And if you look at it a bit more thoroughly then you can see more functions beneath the data and processing. It's the storage, the networking, the maintenance, the service and the processing functions. And clouds perform all the mentioned functions, but in a different degree for each particular cloud. So, the raw data storage service with some networking, processing and a bit of maintenance is very different in comparison with the contemporary clouds, heavily relied on the service and processing parts. It's an enterprise back-end today with all related infrastructure, development and maintenance activities. The file storage for non-business users takes a very small part in the whole picture.

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.

In fact there is new meaning in the new approach which just needs a name. They managed to invent the "cloud computing". One can disagree, but would there be no "cloud computing" then we still be in need for a name. And the new name (as is the case for the old one) also will cause another wave of disagreement. But is there disagreement or not - we still need a name for new thing.

Funny, neither of those things actually worked out, did they?

It's a process. It works in the long term. But some particular steps can become a failure. And the process leaves them behind and replaces them with new steps. And finally some step manages to get a success. But next the process of another player takes the lead and after a few failures replaces the old winner with another one. And so on.

[Schol-R-LEA]

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.

In fact there is new meaning in the new approach which just needs a name. They managed to invent the "cloud computing". One can disagree, but would there be no "cloud computing" then we still be in need for a name. And the new name (as is the case for the old one) also will cause another wave of disagreement. But is there disagreement or not - we still need a name for new thing.

I would say you are putting the cart before the horse - the term 'cloud computing' in it's current form was coined by Oracle marketdroids first (back in 2000, IIRC, before most of the services you are talking about really existed - the term 'cloud' as a metaphor for the Internet had appeared a lot earlier, but there was no consistent use until then), and the the new uses were pushed into the umbrella of that term afterwards - but debating this is clearly getting nowhere. I will leave you, Rusky, Brendan, and OnlyOneMac to your penis-measuring contest and bow out.

[Brendan]

Hi,

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.

It means I need to do whatever I can to defend against malicious hardware (because sooner or later you can guarantee there will be malicious hardware); even though it's impossible be 100% protected against malicious hardware.

It also means I need to do whatever I can to defend against malicious software. For example, if someone has "100% guaranteed and verified" trustworthy hardware, then the AML is still going to be in RAM and any software the runs before my OS boots can inject malicious code into the AML, and if the OS uses AML it has no real way of knowing if it's been tampered with. Of course UEFI secure boot could have been used to protect against software that runs before the OS boots, but that's far from trivial too.

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.

In my opinion there's only really 4 choices:

• Have an OS that sucks (no power management, poor support for IO APICs, no way to turn computer off, doesn't support laptop backlight control, etc) because it doesn't use AML and doesn't provide any alternative
• Have an OS that doesn't use AML and does provide alternative/s (e.g. motherboard drivers)
• Have an OS that is a security and stability disaster because it assumes the AML is neither malicious nor buggy even tough the AML may be malicious and/or buggy
• Have an OS that uses AML, but also has tries to mitigate the risk (e.g. check if a hash of the AML is in a white-list of "known good" hashes, and some way to guarantee that the white list is trustworthy and hasn't been tampered with).

For these, two of the choices aren't good choices for my project (partly because it's a distributed system and needs much stronger defences than a normal desktop/server OS because of that).

The time needed just to support AML is massive all by itself. The additional time needed to mitigate the risks of using AML isn't small either. In a comparison between "OS doesn't use AML and provides alternatives/motherboard drivers" and "OS uses AML and tries to mitigate the risk" the difference in time needed isn't very much, and the "motherboard drivers" approach has multiple other benefits that justify any additional time.

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.

Regardless of what the intention was; the fact remains that in practice firmware developers do disable most functionality/features unless the OS says it's (a version of) Windows and says it supports the interfaces defined by Microsoft for Windows. In practice there is only "Microsoft's way" or "crippled and unstable way".

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.

The difference will be "there are no laptop where everything works properly on your OS" vs. "for 99% of laptops everything works on Windows".

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?

I mean "self hosting" (being able to build everything for the OS on the OS itself). I mean that as soon as I'm able I'm going to wipe Linux off of every computer I own (and install my OS instead) and never touch Linux for the rest of my life.

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.

I'm saying the effort involved in writing an AML interpreter, working around the ""Windows specific behaviour" trap and mitigating the security/stability problems is a massive amount of work to end up with a "no better than what every other OS has already" failure.

I'm saying the total effort involved in writing motherboard drivers is more in theory (to support all motherboards); but I'll only bother with a few of the most common motherboards (and let volunteers do others later) and so it's actually far less work for me in practice; and that "more total work in the long run" is justified by the "better than what every other OS has" advantage.

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?

I mean that (for BIOS systems) PCI device ROMs are copied to RAM (in the legacy area starting at 0x000C0000) and then that RAM is set to "read only" in the memory controller (and this is a required part of the relevant specifications for PCI device ROMs); but the memory controller is chipset specific and you need chipset specific code to be able to change that RAM back to "read write" in the memory controller.

Essentially; 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 by chipset specific code.

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 this one specific case, I'd expect to gain between 128 KiB and 256 KiB of RAM for almost zero cost (because I'm going to need motherboard drivers for multiple other reasons anyway).

To be more correct; I'm saying "the sum of all the benefits justifies the effort" and you're saying "each individual benefit in isolation doesn't justify the effort all by itself". We're both right; it's just that "the sum of all benefits" is what matters and "each individual benefit in isolation" is mostly irrelevant.

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.

No, I'm not limiting the scope. Think of it like this:

• if full information is available the motherboard driver can support 100% features
• if only chipset information is available the motherboard driver can support 90% of features
• if no information is available (e.g. just a disassembly of the AML and nothing else) the motherboard driver can only support 60% of features
• if the OS used AML alone (no motherboard driver) it'd only support 50% of features (which is worse than every single "with motherboard driver" case)

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.

Who cares? Intel mostly make chips and chipsets (and provide the datasheets for their chips and chipsets); and this is the information needed.

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

The interface that motherboard drivers provide will be exactly the same regardless of whether the computer supports ACPI or not. It makes no difference to the rest of OS.

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.

That's faulty logic.

I don't need to write all the drivers. I have to provide an OS, interfaces and tools that are impressive enough to encourage other people to write drivers. Note that this applies to all drivers (e.g. video card drivers, sound card drivers, network card drivers, and motherboard drivers).

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.

It's not something the majority of developers would do. It's something that companies would pay developers to do for specific "hardware+software" products. For example, if you were a company planning to manufacture 1 million smart watches that run my OS, then (instead of spending time writing generic firmware for the hardware) you might implement a "boot from ROM boot loader" to reduce development time and reduce costs and improve boot times.

Note that I have toyed with the idea of providing custom designed boxes one day. For example, I could write the "boot from ROM boot loader" for one cheap Atom board, then sell a small range of "cluster extenders" (where people can buy a little box from me and plug it into their LAN to add processing power or storage space or more users to their existing computers).

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?

The utility would generate a "bare bones" motherboard driver, where maybe 25% of the code is generic "customisable" functionality (stubs, etc), 50% is code to deal with the interface between the motherboard driver and the OS, and 25% is auto-converted from AML.

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?

The package is available; but most people have no idea what AML is and never install the package, and the small number of users who understand AML have better things to do than reading their AML every time they boot to see if it's been tampered with.

Something is wrong with the assumption that users should have to care.

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.

I haven't changed my mind at all - if I find out later that I have no choice, then I can provide a "generic motherboard driver" even though I want to avoid that as much as possible.


Cheers,

Brendan

[BrightLight]

After reading all this, I think it's better just to stick to the PIC rather than the I/O APIC, lol.
Although I want an AML interpreter so I can use my laptop's battery and control the display brightness...
In general, I think ACPI's design is terrible and overcomplicated.

[Antti]

Note that I have toyed with the idea of providing custom designed boxes one day. For example, I could write the "boot from ROM boot loader" for one cheap Atom board, then sell a small range of "cluster extenders" (where people can buy a little box from me and plug it into their LAN to add processing power or storage space or more users to their existing computers).

This idea might be worth keeping around. I think something like this would be a good way to leap off the usual software-only path. I mean this way you could really show people the scalability of your OS and, in general, it would help you in every way when trying to create something that is not just a hobby thing.

I can provide a "generic motherboard driver" even though I want to avoid that as much as possible

I am a little bit skeptical when it comes to this "motherboard driver" thing but not competent enough to say whether the AML is really that much a problem in practice. What I do want to say is that your way seems offer more choices and that is an advantage. As a detail, making this possible is likely to increase the overall modularity of the system even if there never will be "native motherboard drivers" for more than just "BCOS-logo" hardware.

[embryo2]

I would say you are putting the cart before the horse - the term 'cloud computing' in it's current form was coined by Oracle marketdroids first (back in 2000, IIRC, before most of the services you are talking about really existed - the term 'cloud' as a metaphor for the Internet had appeared a lot earlier, but there was no consistent use until then), and the the new uses were pushed into the umbrella of that term afterwards

If it is the case then yes, in 2000 the term was meant just a marketing push and nothing more. But somehow the name has survived the time and what is the reason not to use it today? For example, who cares what meaning had the name Idaho in the times of indians? However, the knowledge of a meaning can be interesting and insightful, so thanks for the roots, traced back to the year of 2000.

I will leave you, Rusky, Brendan, and OnlyOneMac to your penis-measuring contest and bow out.

Your contribution was useful and it's a pity for us to see you folding out.

Discussion polishes knowledge and trains one's brain.

[embryo2]

@Brendan

Now your proposal is more clear and in essence it means you trade the AML related efforts for the direct hardware management where the required information is available and you have enough time to do it.

Generally, it means you prefer a narrow, but more flexible start. And you expect it to pay more because of importance of the flexibility. But you can underestimate the value of a market share while overestimating the value of flexibility. The history knows a lot of technically superior things that haven't got the market share and almost nobody now can remember them.

It means I need to do whatever I can to defend against malicious hardware (because sooner or later you can guarantee there will be malicious hardware); even though it's impossible be 100% protected against malicious hardware.

And how do you plan to deal with the malicious hardware?

if someone has "100% guaranteed and verified" trustworthy hardware, then the AML is still going to be in RAM and any software the runs before my OS boots can inject malicious code into the AML, and if the OS uses AML it has no real way of knowing if it's been tampered with.

Here the first thing is to deal with a signature of the computer ROMs. Most important here is the content of the BIOS ROM. For the ROM's content to be the same after the time you are not at home it is required to read the ROM's data with a ROM reader hardware and check it's signature. Next you can insert a USB drive and load a verifier from it. The verifier checks the rest (other ROMs and at least the disk to boot from). It is not required to do a hardware ROM test every time because most of the time your work is not so secure. But sometime it would be interesting to verify the BIOS's ROM and to find if something is changed. It's not too tedious and time consuming to check it once a month, for example. So, your fear of the malicious AML can be relaxed with such a simple procedure.

Regardless of what the intention was; the fact remains that in practice firmware developers do disable most functionality/features unless the OS says it's (a version of) Windows and says it supports the interfaces defined by Microsoft for Windows. In practice there is only "Microsoft's way" or "crippled and unstable way".

But how's the Linux still alive? Are they reverse engineer the Windows all the time? And do it even for the server market, where Windows has less than 30% share?

And can you present a kind of proof for the "do disable most functionality/features" claim? I mean the word "most" is a bit dubious here.

The difference will be "there are no laptop where everything works properly on your OS" vs. "for 99% of laptops everything works on Windows".

Even for laptop market it's still an exaggeration.

Think of it like this:

• if full information is available the motherboard driver can support 100% features
• if only chipset information is available the motherboard driver can support 90% of features
• if no information is available (e.g. just a disassembly of the AML and nothing else) the motherboard driver can only support 60% of features
• if the OS used AML alone (no motherboard driver) it'd only support 50% of features (which is worse than every single "with motherboard driver" case)

It's interesting how have you managed to calculate the 50% for the AML alone case? But why the Windows just ignores the other 50%? And if you are speaking about "generic OS", then still it is very interesting where the 50% have come from. Only from your experience with a few laptops? And knowing your AML dislike I suppose you haven't thoroughly studied the ways your laptops work with the AML. Because it's "just a mess" and you see it almost as a religious war.

It's something that companies would pay developers to do for specific "hardware+software" products. For example, if you were a company planning to manufacture 1 million smart watches that run my OS, then (instead of spending time writing generic firmware for the hardware) you might implement a "boot from ROM boot loader" to reduce development time and reduce costs and improve boot times.

First, one million watches project costs are measured in tenths of millions of $. And do you think a company would risk the tenths of millions just to try your OS?

The company first will look at the marker share of your OS. And most probably it would notice that there is Android and almost nothing else. And your OS will be in the end of the "nothing else" list. It means the first thing you want to do is to create the market share. And it is possible only if you can attract a lot of users/developers. And even if it is the case, the how would you (or attracted developers) obtain the information for the 99% of the laptops? Or do you hope to attract a lot of users with an example of only one laptop, that works with your OS?

I could write the "boot from ROM boot loader" for one cheap Atom board, then sell a small range of "cluster extenders" (where people can buy a little box from me and plug it into their LAN to add processing power or storage space or more users to their existing computers).

It's better not to be so self confident. The hardware market is another thing you haven't worked in. The price/value analysis of your "Atom" thing would show you it can't compete against established things like routers, servers and other stuff.

Something is wrong with the assumption that users should have to care.

Then why they should care about your OS features? They should care or else your claim of a secure OS is just a bluff.

[Brendan]

Hi,

It means I need to do whatever I can to defend against malicious hardware (because sooner or later you can guarantee there will be malicious hardware); even though it's impossible be 100% protected against malicious hardware.

And how do you plan to deal with the malicious hardware?

I plan to deal with malicious hardware in whatever way/s I can. This includes:

• Admin is responsible for ensuring the computer is OK (authorising the hardware) before installing the OS on it
• During boot, OS's boot code disables all PCI devices it can and sets up IOMMUs (if present) as "most restrictive possible"; to make it harder for hardware to tamper with the OS's boot code and kernel. Then (if possible) tries to establish a dynamic root of trust (e.g. using AMD's "skinit" instruction).
• If possible, OS uses TPM and its static root of trust and/or the dynamic root of trust for remote authentication; and stores the local file system encryption key in TPM; so if the firmware, boot loader, etc is tampered with the OS can't access any (local or remote) data until the admin checks the computer and authorises it again.
• If present, using IOMMU to restrict which areas of RAM devices can access after boot
• All of the OS's boot code and kernels are digitally signed (self-signed by the hardware owner's key); and (if possible) that's used in conjunction with UEFI secure boot (if possible) to make it hard for anything to tamper with the OS's boot code, kernel, etc.
• Starting from boot loader, all the boot code allocates all pages used, and this will be "randomised"; to make it hard to guess which physical pages most of the boot code and the kernel ends up using (like "Address Space Layout Randomisation", but for the physical address space instead of for virtual address spaces).
• If possible some types of hardware interfaces (e.g. Intel's Thunderbolt) will be disabled or restricted (require admin's permission to enable).
• All networking between computers in the cluster will be encrypted by sending kernel (before kernel tells network card driver to send packets) and decrypted by receiving kernel (after kernel gets the packs from network card driver); so network card drivers, network cards, and anything on the network (e.g. switches, etc) can't tamper with data between computers.

Of course all of this doesn't guarantee the OS is secure. For example, for about $35 you can buy a USB key logger chip and it's impossible (as far as I know) for the OS to detect it (and if you install it properly inside a keyboard, impossible for admin or users to detect it without pulling apart the keyboard).

Note: When hardware owner creates the "signed OS installer" they'll also set an intended security level; and if the hardware owner wants no security or weak security then some of the things I've listed above will be disabled to improve performance (e.g. encrypted networking) or to make it easier for admin (e.g. no "re-authentication"). For example, if the cluster is only used for games, or if there's enough physical security anyway (e.g. the cluster is locked in a building surrounded by armed soldiers), then maybe there's no need for the OS itself to be secure.

if someone has "100% guaranteed and verified" trustworthy hardware, then the AML is still going to be in RAM and any software the runs before my OS boots can inject malicious code into the AML, and if the OS uses AML it has no real way of knowing if it's been tampered with.

Here the first thing is to deal with a signature of the computer ROMs. Most important here is the content of the BIOS ROM. For the ROM's content to be the same after the time you are not at home it is required to read the ROM's data with a ROM reader hardware and check it's signature. Next you can insert a USB drive and load a verifier from it. The verifier checks the rest (other ROMs and at least the disk to boot from). It is not required to do a hardware ROM test every time because most of the time your work is not so secure. But sometime it would be interesting to verify the BIOS's ROM and to find if something is changed. It's not too tedious and time consuming to check it once a month, for example. So, your fear of the malicious AML can be relaxed with such a simple procedure.

The first problem here is that something can (temporarily) modify the OS's code (e.g. modify the code that calculates the checksum) and make everything seem correct when its not. The second problem is that the AML itself can be modified after it's been checked but before its used. The third problem is that if you're only checking once per month an attacker can change the AML to create a security hole, then (e.g.) steal or modify whatever they want, then change everything back to how it was so that there's nothing to find when you check.

Regardless of what the intention was; the fact remains that in practice firmware developers do disable most functionality/features unless the OS says it's (a version of) Windows and says it supports the interfaces defined by Microsoft for Windows. In practice there is only "Microsoft's way" or "crippled and unstable way".

But how's the Linux still alive? Are they reverse engineer the Windows all the time? And do it even for the server market, where Windows has less than 30% share?

For desktop/server, Linux tells the AML that it is a version of Windows. For smartphone there's no ACPI in the first place.

And can you present a kind of proof for the "do disable most functionality/features" claim? I mean the word "most" is a bit dubious here.

I already did. See the this post where I found a random AML disassembly and showed how the OS name effects almost everything.

Think of it like this:

• if full information is available the motherboard driver can support 100% features
• if only chipset information is available the motherboard driver can support 90% of features
• if no information is available (e.g. just a disassembly of the AML and nothing else) the motherboard driver can only support 60% of features
• if the OS used AML alone (no motherboard driver) it'd only support 50% of features (which is worse than every single "with motherboard driver" case)

It's interesting how have you managed to calculate the 50% for the AML alone case? But why the Windows just ignores the other 50%? And if you are speaking about "generic OS", then still it is very interesting where the 50% have come from. Only from your experience with a few laptops? And knowing your AML dislike I suppose you haven't thoroughly studied the ways your laptops work with the AML. Because it's "just a mess" and you see it almost as a religious war.

That 50% is everything Windows and AML doesn't support; like the 3D model of the motherboard, being able to determine which RAM module contains a physical address, being able to change how the memory controller set up the physical address space, and whatever else I can think of between now and whenever I finish the final draft of (the first version of) the OS's official "motherboard driver" specification.

It's something that companies would pay developers to do for specific "hardware+software" products. For example, if you were a company planning to manufacture 1 million smart watches that run my OS, then (instead of spending time writing generic firmware for the hardware) you might implement a "boot from ROM boot loader" to reduce development time and reduce costs and improve boot times.

First, one million watches project costs are measured in tenths of millions of $. And do you think a company would risk the tenths of millions just to try your OS?

This doesn't make any sense. Obviously a company would try my OS on other hardware (e.g. a general purpose PC) before deciding to use the OS for any product. They might even build a prototype that just boots from BIOS or UEFI before they decide to implement a "boot from ROM boot loader" for their hardware.

What I was trying to say is that normal developers (e.g. for normal "generic white box PC" computers) wouldn't write a "boot from ROM boot loader" at all (and that it's something that would only be used for some specific "hardware+software" products, if the company making the product feels like it).

I could write the "boot from ROM boot loader" for one cheap Atom board, then sell a small range of "cluster extenders" (where people can buy a little box from me and plug it into their LAN to add processing power or storage space or more users to their existing computers).

It's better not to be so self confident. The hardware market is another thing you haven't worked in. The price/value analysis of your "Atom" thing would show you it can't compete against established things like routers, servers and other stuff.

It's better to consider every possibility (including the "Hey, what if the OS actually is successful one day?" possibility); instead of allowing pessimism to create a self-fulfilling prophecy of failure ("I probably won't succeed, therefore I won't try, therefore I'm guaranteed to fail").

A small Atom board (with RAM, CPU, NIC, etc), case, power supply, etc would probably cost $150 in materials. With the right software (e.g. "boot from ROM" loader, motherboard driver, NIC driver, video/GPU driver, etc) that ensures everything works perfectly (and there's no "doesn't work because there's no driver for something" hassles); I could sell them for $200 each, and at that price I can imagine companies and schools buying 20+ at a time to switch entire offices/classrooms over (to take advantage of the OS's features).

Something is wrong with the assumption that users should have to care.

Then why they should care about your OS features? They should care or else your claim of a secure OS is just a bluff.

If you buy a TV, or microwave oven, or toaster, do you expect to have to waste "X hours per month" trying to keep the piece of crud working properly? Of course not - you plug it in and expect it to work; and if you have to waste "X hours per month" trying to maintain it then you throw it in the trash where it belongs.

If a user has to manually inspect the AML on every computer every month, then it's completely unacceptable, and in that case the only honest advice I can provide is that the OS is a massive joke that needs to die.


Cheers,

Brendan

[embryo2]

I plan to deal with malicious hardware in whatever way/s I can. This includes:

• Admin is responsible for ensuring the computer is OK (authorising the hardware) before installing the OS on it

It means it's enterprise only solution.

• During boot, OS's boot code disables all PCI devices it can and sets up IOMMUs (if present) as "most restrictive possible"; to make it harder for hardware to tamper with the OS's boot code and kernel. Then (if possible) tries to establish a dynamic root of trust (e.g. using AMD's "skinit" instruction).
• If possible, OS uses TPM and its static root of trust and/or the dynamic root of trust for remote authentication; and stores the local file system encryption key in TPM; so if the firmware, boot loader, etc is tampered with the OS can't access any (local or remote) data until the admin checks the computer and authorises it again.

The IOMMU and TPM are the things that just can be declared as required for an enterprise system. So, no "if present" question would emerge.

But I suppose it's much better to identify the threats instead of inventing protection measures.

I suppose the threats are:

• Hardware can save your data
• Hardware can save your data
• ...

So, we should prevent it from accessing the data. But how to do it in case of a keyboard? It can be possible if we split our data into some useless encrypted pieces. An HDD can be partitioned with RAID 5, for example, into 10 disks (for example), so the attacker, who had access to one disk can get too little to obtain the entire piece of information. But now it's the problem how to hide the disks from an attacker? They can be distributed somewhere in the net. But how to distribute a keyboard? We can split it into one key parts, but next we should hide the parts from an attacker. May be it's better to always take some keys with you? Or is it better to find another way when the cost of your useless information will be less than the cost of obtaining it?

I suppose, for the first place, the problem is a bit exaggerated. And I suppose if an individual is watched with some secret service, then there's no way to afford the hardware and organizational measures required to protect the individual's information. At least it should be an extraordinary individual, because he should be able to enforce upon himself the hardest security rules.

• All networking between computers in the cluster will be encrypted by sending kernel (before kernel tells network card driver to send packets) and decrypted by receiving kernel (after kernel gets the packs from network card driver); so network card drivers, network cards, and anything on the network (e.g. switches, etc) can't tamper with data between computers.

Networking is a separate issue, unless you'll try to implement a distributed system. But even then the network related part is already studied at a good level.

Here the first thing is to deal with a signature of the computer ROMs. Most important here is the content of the BIOS ROM. For the ROM's content to be the same after the time you are not at home it is required to read the ROM's data with a ROM reader hardware and check it's signature. Next you can insert a USB drive and load a verifier from it. The verifier checks the rest (other ROMs and at least the disk to boot from). It is not required to do a hardware ROM test every time because most of the time your work is not so secure. But sometime it would be interesting to verify the BIOS's ROM and to find if something is changed. It's not too tedious and time consuming to check it once a month, for example. So, your fear of the malicious AML can be relaxed with such a simple procedure.

The first problem here is that something can (temporarily) modify the OS's code (e.g. modify the code that calculates the checksum) and make everything seem correct when its not.

Do you mean it can modify something while I'm not bothered with checking? But it's your third question.

The second problem is that the AML itself can be modified after it's been checked but before its used.

What entity can do that? The entity, that is already checked?

The third problem is that if you're only checking once per month an attacker can change the AML to create a security hole, then (e.g.) steal or modify whatever they want, then change everything back to how it was so that there's nothing to find when you check.

If I have a security concern and I know it's better to be safe then it's my fault if I haven't checked the system before I start to do my secure job.

For desktop/server, Linux tells the AML that it is a version of Windows.

Then why the ACPI specification lists the Linux as one of the possible _OS values? As is already said - there's server market and it uses different OSes.

See the this post where I found a random AML disassembly and showed how the OS name effects almost everything.

OS name effects something, but not everything. Yes, I see it, but it is required to analyze the meaning of the registers employed. I just don't know what the registers are responsible for on a machine from somewhere in the net.

But you can tell it strict - did you explored the area extensively? I mean have you managed to collect a relevant statistics for a representative set of machines?

That 50% is everything Windows and AML doesn't support; like the 3D model of the motherboard, being able to determine which RAM module contains a physical address, being able to change how the memory controller set up the physical address space, and whatever else I can think of between now and whenever I finish the final draft of (the first version of) the OS's official "motherboard driver" specification.

It's too courageous to claim the "twice as Windows can" goal. For now it's only 3D view and the 128kb of additional memory.

What I was trying to say is that normal developers (e.g. for normal "generic white box PC" computers) wouldn't write a "boot from ROM boot loader" at all (and that it's something that would only be used for some specific "hardware+software" products, if the company making the product feels like it).

Have you considered different platforms like ARM for the "specific" products? It adds another bunch of years to your efforts.

It's better to consider every possibility (including the "Hey, what if the OS actually is successful one day?" possibility); instead of allowing pessimism to create a self-fulfilling prophecy of failure ("I probably won't succeed, therefore I won't try, therefore I'm guaranteed to fail").

Ok, from now we suppose that your OS is winning and many people look at it with a great hope.

But

A small Atom board (with RAM, CPU, NIC, etc), case, power supply, etc would probably cost $150 in materials. With the right software (e.g. "boot from ROM" loader, motherboard driver, NIC driver, video/GPU driver, etc) that ensures everything works perfectly (and there's no "doesn't work because there's no driver for something" hassles); I could sell them for $200 each, and at that price I can imagine companies and schools buying 20+ at a time to switch entire offices/classrooms over (to take advantage of the OS's features).

After people look at the alternatives they often do some calculation. Like this - a Opteron processor's price is about 500-600$ (for cheapest in the 16 core series), it has 16 cores (each not worse than Atom's) and a system with the Opteron could cost about 1500-1600$. Now we can calculate the cost of both variants. For your variant it's 16*200=3200$, for the alternative it's just half of the former (1600$). So, you can see, that in the area of "additional processing power" your approach is not competitive. And I suppose if you calculate the price/value for the network routing area there also will be the same picture.

If a user has to manually inspect the AML on every computer every month, then it's completely unacceptable, and in that case the only honest advice I can provide is that the OS is a massive joke that needs to die.

If a user has the need to inspect the AML then it's completely acceptable for the user to take required actions. But if the user isn't bothered with the problem then, of course, he never will inspect the AML. The difference is in the need for security. Most people have a little need in it. And your OS will be of no value (except marketing) for them.

[Brendan]

Hi,

I plan to deal with malicious hardware in whatever way/s I can. This includes:

• Admin is responsible for ensuring the computer is OK (authorising the hardware) before installing the OS on it

It means it's enterprise only solution.

No it doesn't. It just means that the OS displays a message (like "Are you sure this computer is OK? [Yes][No]") when the OS is being installed, so that if the hardware is dodgy I can say "Hey, you said it was OK so don't blame me!".

• During boot, OS's boot code disables all PCI devices it can and sets up IOMMUs (if present) as "most restrictive possible"; to make it harder for hardware to tamper with the OS's boot code and kernel. Then (if possible) tries to establish a dynamic root of trust (e.g. using AMD's "skinit" instruction).
• If possible, OS uses TPM and its static root of trust and/or the dynamic root of trust for remote authentication; and stores the local file system encryption key in TPM; so if the firmware, boot loader, etc is tampered with the OS can't access any (local or remote) data until the admin checks the computer and authorises it again.

The IOMMU and TPM are the things that just can be declared as required for an enterprise system. So, no "if present" question would emerge.

Except the OS isn't intended for "enterprise only" so these features (IOMMU, TPM) might not be present.

I suppose the threats are:

• Hardware can save your data
• Hardware can save your data
• ...

So, we should prevent it from accessing the data. But how to do it in case of a keyboard? It can be possible if we split our data into some useless encrypted pieces. An HDD can be partitioned with RAID 5, for example, into 10 disks (for example), so the attacker, who had access to one disk can get too little to obtain the entire piece of information. But now it's the problem how to hide the disks from an attacker? They can be distributed somewhere in the net. But how to distribute a keyboard? We can split it into one key parts, but next we should hide the parts from an attacker. May be it's better to always take some keys with you? Or is it better to find another way when the cost of your useless information will be less than the cost of obtaining it?

I suppose, for the first place, the problem is a bit exaggerated. And I suppose if an individual is watched with some secret service, then there's no way to afford the hardware and organizational measures required to protect the individual's information. At least it should be an extraordinary individual, because he should be able to enforce upon himself the hardest security rules.

Or, how about the OS does whatever it can with the hardware it's given (and if it's not secure, then that's the admin's fault and not the OS's fault because the admin said it was OK)?

• All networking between computers in the cluster will be encrypted by sending kernel (before kernel tells network card driver to send packets) and decrypted by receiving kernel (after kernel gets the packs from network card driver); so network card drivers, network cards, and anything on the network (e.g. switches, etc) can't tamper with data between computers.

Networking is a separate issue, unless you'll try to implement a distributed system. But even then the network related part is already studied at a good level.

It is a distributed system.

Here the first thing is to deal with a signature of the computer ROMs. Most important here is the content of the BIOS ROM. For the ROM's content to be the same after the time you are not at home it is required to read the ROM's data with a ROM reader hardware and check it's signature. Next you can insert a USB drive and load a verifier from it. The verifier checks the rest (other ROMs and at least the disk to boot from). It is not required to do a hardware ROM test every time because most of the time your work is not so secure. But sometime it would be interesting to verify the BIOS's ROM and to find if something is changed. It's not too tedious and time consuming to check it once a month, for example. So, your fear of the malicious AML can be relaxed with such a simple procedure.

The first problem here is that something can (temporarily) modify the OS's code (e.g. modify the code that calculates the checksum) and make everything seem correct when its not.

Do you mean it can modify something while I'm not bothered with checking? But it's your third question.

No, I mean that if something outside the OS (firmware, boot manager, etc) is malicious, then it can disable all the checks in your code before your code is run. For a silly example, you might write "if( do_CRC_check() != PASSED) { abort_boot(); }" and it might get modified by the attacker so that it becomes "if( true == false ) { abort_boot(); }" before it's executed, so that the check never does anything.

The second problem is that the AML itself can be modified after it's been checked but before its used.

What entity can do that? The entity, that is already checked?

The firmware, the firmware's SMM code, any hardware device that has bus mastering/DMA, and malicious code that injected code into BIOS/UEFI functions that you call, a hyper-visor style root-kit, etc.

For desktop/server, Linux tells the AML that it is a version of Windows.

Then why the ACPI specification lists the Linux as one of the possible _OS values? As is already said - there's server market and it uses different OSes.

I'd assume they wanted to pretend that ACPI is "OS neutral" and just picked the first 5 OSs they could think of to slap into a table as examples. Maybe they were "overly optimistic" and thought firmware would actually bother supporting more than Windows when they wrote it. I don't know.

See the this post where I found a random AML disassembly and showed how the OS name effects almost everything.

OS name effects something, but not everything. Yes, I see it, but it is required to analyze the meaning of the registers employed. I just don't know what the registers are responsible for on a machine from somewhere in the net.

Do you still think that normal users (who aren't OS developers like us) are able to figure out if the ASL on their computer is/isn't secure?

But you can tell it strict - did you explored the area extensively? I mean have you managed to collect a relevant statistics for a representative set of machines?

I have no reason to extensively research the effects of OS name on AML - if I didn't want to avoid AML for multiple other reasons anyway; the fact that OS name does effect behaviour (on every AML disassembly I've seen in 10+ years) is enough to make me concerned about making my OS depend on AML on both current and future computers.

That 50% is everything Windows and AML doesn't support; like the 3D model of the motherboard, being able to determine which RAM module contains a physical address, being able to change how the memory controller set up the physical address space, and whatever else I can think of between now and whenever I finish the final draft of (the first version of) the OS's official "motherboard driver" specification.

It's too courageous to claim the "twice as Windows can" goal. For now it's only 3D view and the 128kb of additional memory.

You're right - I should be claiming 75% instead, because when I start researching all the possibilities I'm bound to find a huge number of things an OS could use a motherboard driver for that I haven't thought of yet.

What I was trying to say is that normal developers (e.g. for normal "generic white box PC" computers) wouldn't write a "boot from ROM boot loader" at all (and that it's something that would only be used for some specific "hardware+software" products, if the company making the product feels like it).

Have you considered different platforms like ARM for the "specific" products? It adds another bunch of years to your efforts.

I'll worry about ARM systems after I've got 80x86 working how I want it. Maybe they'll be properly standardised by then.

It's better to consider every possibility (including the "Hey, what if the OS actually is successful one day?" possibility); instead of allowing pessimism to create a self-fulfilling prophecy of failure ("I probably won't succeed, therefore I won't try, therefore I'm guaranteed to fail").

Ok, from now we suppose that your OS is winning and many people look at it with a great hope.

But

A small Atom board (with RAM, CPU, NIC, etc), case, power supply, etc would probably cost $150 in materials. With the right software (e.g. "boot from ROM" loader, motherboard driver, NIC driver, video/GPU driver, etc) that ensures everything works perfectly (and there's no "doesn't work because there's no driver for something" hassles); I could sell them for $200 each, and at that price I can imagine companies and schools buying 20+ at a time to switch entire offices/classrooms over (to take advantage of the OS's features).

After people look at the alternatives they often do some calculation. Like this - a Opteron processor's price is about 500-600$ (for cheapest in the 16 core series), it has 16 cores (each not worse than Atom's) and a system with the Opteron could cost about 1500-1600$. Now we can calculate the cost of both variants. For your variant it's 16*200=3200$, for the alternative it's just half of the former (1600$). So, you can see, that in the area of "additional processing power" your approach is not competitive. And I suppose if you calculate the price/value for the network routing area there also will be the same picture.

It depends what the system is being used for. You don't buy a 16-core Opteron server when you want a thin client, or a small NAS for your lounge room, or a small device you can plug into your laptop to get a little more processing power while you're travelling on a train.

After doing (inexpensive/versatile) little machines, if they sell reasonably well, high powered servers would probably be a logical next step.

If a user has to manually inspect the AML on every computer every month, then it's completely unacceptable, and in that case the only honest advice I can provide is that the OS is a massive joke that needs to die.

If a user has the need to inspect the AML then it's completely acceptable for the user to take required actions. But if the user isn't bothered with the problem then, of course, he never will inspect the AML. The difference is in the need for security. Most people have a little need in it. And your OS will be of no value (except marketing) for them.

I suspect the OS will have more features than just security and nothing else; and if someone wants (e.g.) a fault tolerant distributed system with low maintenance hassle they aren't going to complain if it happens to be more secure than they need.


Cheers,

Brendan

[Schol-R-LEA]

Discussion polishes knowledge and trains one's brain.

The brain isn't organ getting polished in this thread.

[gerryg400]

Discussion polishes knowledge and trains one's brain.

The brain isn't organ getting polished in this thread.

Co-incidentally that's precisely the thought I had when I first read that.

[Brendan]

Hi,

Discussion polishes knowledge and trains one's brain.

The brain isn't organ getting polished in this thread.

We've just found the winner of this topic's "least useful post" award.


Cheers,

Brendan

[Schol-R-LEA]

Hi,

Discussion polishes knowledge and trains one's brain.

The brain isn't organ getting polished in this thread.

We've just found the winner of this topic's "least useful post" award.

And yet it sums up most of the 'discussion' quite well, don't you think? Seriously, all of you need to rein in your egos a bit and start considering that maybe, just maybe, this should be about something other than proving that you're the smartest person in the room.

This isn't a damn contest, nor is it a life or death situation. I know that both you and embryo (among others, including me if I am being completely honest) have a delusion that you are somehow going to overthrow the status quo with your little toy OS, but seriously, get over yourselves.

Do you want to know why you cannot possibly succeed in what you are trying to accomplish? It's simple: worse really is better. The economics dictate that the products that fulfill the job with the least cost and the highest generation of paid labor (e.g., require the most technical support, the most administration effort, the most paid effort to be kept working in general) are the ones that succeed. Perfection is economically non-viable, because no one will be able to make a living from it - you simply will never get the necessary critical mass of experts who know the technology. Now, a lot of people think I am suggesting that there's some conspiracy, but I am not; this is not deliberate, it is just a factor of the market pressures involved. If you did succeed in doing what you mean to - and I have yet to see any indication that you are any further along in your system than I am in mine - you would be unable to get people behind you because it is too good.

[embryo2]

It just means that the OS displays a message (like "Are you sure this computer is OK? [Yes][No]") when the OS is being installed, so that if the hardware is dodgy I can say "Hey, you said it was OK so don't blame me!".

It should be something like this - "Are you sure? Read here A LOT about why you shouldn't be so sure." [yes][no][read A LOT]

Because users often unaware about how secure your OS could be.

Or, how about the OS does whatever it can with the hardware it's given (and if it's not secure, then that's the admin's fault and not the OS's fault because the admin said it was OK)?

I'm fine about the idea, but the time is crying. You can do it if your life is long enough and there will be no alternative solution, supported by big money.

Do you plan to finish it? Really?

The second problem is that the AML itself can be modified after it's been checked but before its used.

What entity can do that? The entity, that is already checked?

The firmware, the firmware's SMM code, any hardware device that has bus mastering/DMA, and malicious code that injected code into BIOS/UEFI functions that you call, a hyper-visor style root-kit, etc.

How they can do it? BIOS ROM was checked (including SMM), next ROM of every device is checked, hyper-visor is the user's problem, so, I consider it is also checked. The only unchecked thing is the hardware itself, but I suppose the cost of manufacturing a special hardware just to grab some of my porn movies is a bit too costly.

Do you still think that normal users (who aren't OS developers like us) are able to figure out if the ASL on their computer is/isn't secure?

Do you still think that normal users (who aren't OS developers like us) are able to figure out if your OS is really so secure? They can trust you or they can buy an anti-virus that claims it is ready for your OS (while does absolutely nothing except showing some attractive UI). Do you see the problem here? It's the trust. They should see your OS everywhere and hear comments from everywhere about your OS's highest possible security. And in turn it means there should be a market for your OS. A big market. And not a bunch of youtube videos.

You're right - I should be claiming 75% instead, because when I start researching all the possibilities I'm bound to find a huge number of things an OS could use a motherboard driver for that I haven't thought of yet.

You're on the right way. Keep thinking "high" and the moon will be your next stop.

It depends what the system is being used for. You don't buy a 16-core Opteron server when you want a thin client, or a small NAS for your lounge room, or a small device you can plug into your laptop to get a little more processing power while you're travelling on a train.

The niche for the travel time performance booster is too small. And if it would be big enough there will be a lot of variants, supported by big money (in contrast with your project).

After doing (inexpensive/versatile) little machines, if they sell reasonably well, high powered servers would probably be a logical next step.

It's better to look at the server market now.