The evidence is overwhelmingly against them (the sabotage is plainly visible in their own code)
I pretty thoroughly debunked this in the original discussion, but it seems once people have decided someone's out to get them they're immune to all forms of logic and reason.
The short version is, you can't assume that the presence of a table for Linux is evidence of malice. It probably came from AMI that way (dummy tables for Windows and Linux), and they just put their hardware info into the Windows section. Being lazy they didn't bother to fix the Linux section since hey, the boss says they don't support Linux!
Stupid yeah, especially since they could just remove the check altogether if they didn't want to have 2 different tables. On purpose? I suppose it's possible, but the evidence doesn't prove anything.
The code that the original poster said was put there to "deliberately crash the kernel" did nothing of the sort. The OP didn't know the first thing about ACPI and was talking out his ass -- there was nothing wrong or against the spec in the fragments he posted. Most likely a dumb mistake (one that wouldn't have even been caught by compiler warnings since it looked to be a timing bug) exposed subtle differences in the Linux ACPICA.
Search for my post in the other thread of you want the technical details of it all.
Ideally, there would be an official "ACPI certification" offered by ISO or some not-for-profit third party, and both the vendors and Microsoft would have to comply.
I'd even settle for Intel, since they wrote the reference ACPICA implementation (which happens to be used by Linux).
Might be tough though, since MS is an ACPI parter and would presumably oppose such a certification. I wonder who, if anyone, has control of the name and trademarks.
Yes, but fortunately MS isn't the only partner in ACPI, and Bill Gates doesn't get the final word on it.
Look at the state of things. Intel, who did a fairly large chunk of the work on ACPI, wrote the reference interpreter. Intel's interpreter is what is used in Linux, FreeBSD, and several other operating systems. Intel periodically releases updates and fixes to make sure that it correctly supports the published ACPI specification.
MS has their own hacked together interpreter that's fairly broken. The only MS-specific ACPI extensions I know of are implemented in separate tables like WHEA, and not in the DSDT.
The bottom line are, BIOS writers are lazy and often the tables they produce don't meet the ACPI specification. If it boots windows, it's good enough and it goes out the door. I'm all for campaigning for standards support, but making unfounded accusations and attacking their support reps isn't the way to do it.
Grep for "mutes", if you want to. Tell me, why the fuck would a machine need its serial ports (IO port range from 0x3f8, about the oldest hardware on a PC, present from before the IBM XT) disabled on Linux and not on Windows?
TFA is wrong about this. Re-read TFA. See my post here. Verify by reading the ACPI spec if you wish.
It's 3e8, not 3f8. It's the second parameter to Acquire() which is a timeout. 3e8 = 1000 = 1 second. There's nothing inherently wrong with that statement in an ASL. The fact that it crashes if you don't change it is likely an artifact of some more complex synchronization problem and subtle differences between ACPI implementations.
Furthermore, the Windows side of the ACPI code checks repeatedly that it is indeed running on Windows. And not from any information provided by the ACPI interpreter, oh no: they poke the hardware as a sort of a secret handshake. This is clearly written with intent to prevent Linux from impersonating Windows to the ACPI code.
Evidence?
All I see on the matter is an assertion posted by the original author of the thread. The only code excerpts he provides shows a match against _OS. Hardly a secret handshake. Given that he doesn't seem to understand what Acquire() does (one of the more basic ASL operators), I don't have much confidence in his knowledge of ACPI or his ability to analyze the dump.
He also adds an _OSI("Linux") section in his revised code, which will never be evaluated since Linux lies and doesn't identify itself in _OSI. Might as well just remove the whole section.
No, it allegedly has a bunch of checks for Linux strewn about in random places which then give bad data upon detecting Linux.
The only person claiming that is the original poster in that thread, whose correspondence with Foxconn and the (!) FTC is instantly accusatory and full of assumption. It's almost as if he started with the premise that Foxconn was actively breaking Linux to be anticompetitive and looked for evidence to support it.
I'd have to see a full DSDT dump to be sure, but from the excerpts posted it looks like "active checking" is just matching against _OS instead of using _OSI, which is a mistake a naive BIOS writer unfamiliar with the spec could easily make. It doesn't help the issue that Linux lies about its identity in _OSI.
The "redundant checks" seem to be present for the Windows code path too, and look more to me like bad spaghetti code copied and pasted multiple places.
I also take issue with
Find and replace all seven occurences of Acquire (MUTE, 0x03E8) and replace with Acquire (MUTE, 0xFFFF), it appears they're trying to crash the kernel by locking a region of memory that shouldn't be locked, but without access to their source code comments, I can only speculate, this tells it to lock a memory address that is always reserved instead.;)
It's obviously not trying to crash the kernel, that's not how Acquire() works. The second parameter is a timeout, not a memory address. 3E8 hex = 1000 decimal. The BIOS writer was trying to acquire a mutex with a 1 second timeout.
Changing it to 0xFFFF makes it wait forever, which could potentially cause worse problems as execution will get stuck if the mutex is already held. Multithreaded synchronization is a very tricky problem, and I'm not surprised to see they got it wrong. Without examining the code it's impossible to say what effect TheAlmightyCthulu's changes have, if they're correct or if they merely mask the problem.
Saying they're trying to deliberately crash the kernel is a bit ridiculous.
But then again I'm a BSD guy, so I don't start out with a chip on my shoulder and assume everyone's out to get me. Have seen a ton of shoddy BIOSes in my time though.
These errors only mean that he's stuck using APM in place of ACPI.
Good luck using things like oh, multiple cores, without ACPI. A lot of boards I've seen recently don't ship working MPS info, and half the time they don't even have correct routing in $PIR.
If they didn't support Linux, and were not incompetent, they would remove the OS check altogether and just use the "Windows" table for everything. This is probably already what happens for other unsupported OSes that are not Windows or Linux, such as FreeBSD.
If Windows, it sends the good tables. If Linux, it sends the deliberately faulty ones.
It's still more likely incompetence than conspiracy. Most motherboard manufacturers don't write their own BIOS - they buy a stock one from AMI/Award and make a few changes for their particular board.
What they most likely did was update the DSDT tables handed out to Windows to reflect their hardware, but didn't bother changing the others. So for Linux (and perhaps Win9x) it just has the generic tables that came with the BIOS, which of course don't work for their particular board.
Of course, a BIOS even having per-OS tables is indicative of poor design, since being OS-independent is kinda the whole point of ACPI. That's more of an issue with whoever wrote the BIOS in the first place, though.
While they're probably not out to actively sabotage Linux, it's still poor customer service to refuse to fix it and claim that everything is working fine. Sadly, getting most board manufacturers to fix their broken DSDT tables (and there are a lot out there) is akin to pulling teeth.
...but more dangerous content/extentions like exe's, zips, tar.gz's, bz2, py, and iso's py?!?!?!
What I find interesting that pl is not listed, even though it's clearly more dangerous. You're a lot more likely to have an aneurysm while trying to read perl code than python.
God did it... now let's see why, and what rules he put into place. Not to mention the 'how' aspect. If God exists it doesn't logically preclude the possibility of evolution as a means of creation (all-knowing = knew exactly how it would turn out from the start). Only stubborn belief in the infallible truth of a book, written by humans let's not forget, stands in the way of progress.
In other words, if God didn't want us to be trying to determine our origins and the way that the universe works, questioning everything along the way, why would he give us such strong curiosity about it?
* nothing can get inbetween the line of sight of a pointer and the wiimote Given that wiimotes are relatively cheap, I wonder if this could be worked around by using multiple wiimotes from different angles and reconciling the data in software.
Actually the NT kernel is decently designed, and kernel-level exploits in Windows have been fairly rare (though there have been a few).
It's the Win32 layer and all the random services that run as SYSTEM (half of them OEM junk or stupid things like scanner drivers) that have had the most problems.
Don't run the game as an admin. Then it can't open the raw partitions (which it shouldn't be trying anyway). Copy the files over (wow doesn't need to be "installed" per se), change permissions on the directory, login as your unprivileged user.
I've also been a little suspicious of warden, so I run wow on XP as a separate normal (what's called "limited" in the home version) user. It was "installed" as a user, runs as a user, and applies the updates as a user just fine. Just took a little tweaking of some directory permissions beforehand, but only on its own program directory -- nothing under %SYSTEMROOT% or crap like that. I'm 100% certain that warden can't access anything other than the completely empty user account wow runs under.
I put "installed" in quotes because my preferred method for installing wow is to just copy the whole directory over from another machine. On my FreeBSD box the installer doesn't work in wine anyway, so that's the easiest method to get it loaded. Works fine, no registry settings or anything. It runs under a (separate) unprivileged user there too.
I don't know why the updates don't work in Vista as a normal user. I assume it has something to do with Vista's bizarre security model where file permissions don't seem to mean what they should on certain magic directories (i.e. Program Files). Turning off UAC may help.
I'd also like to give a shout out to both the WoW and City of Heroes dev teams for supporting OpenGL as a graphics option (the only option in the latter). Doing that makes them run quite well under wine due to avoiding the Direct3D emulation layer. I have to admit I was floored when I tried it. I've never managed to get anything more complicated than calc.exe to successfully run under wine before, but both of those games run flawlessly with almost no effort on my part.
If you think the whole world revolves around you, quit staring at the GPS display while driving. I have my GPS set to always display north as up, thank you very much.
The whole world does translate around me, however.
Source quench is an ICMP message, similar to destination unreachable but less severe. It's a way for a host to tell another host (or router) that it's sending data too fast for it to process and should back off. It was an early attempt at preemptive traffic control to throttle back before something has to start dropping packets.
There's not a whole lot of equipment that sends them, but pretty much every OS I've come across honors the messages to some extent. I don't know if the cheap NAT routers that many people use pass them along or not, though NAT in general tends to be fairly broken when it comes to ICMP.
If a man in the middle were to spoof ICMP source quench packets that looked like they came from either of the p2p nodes that were communicating, the effect would be that they would start sending data more slowly to each other. The connection would still be open, they just wouldn't transmit as fast as they could.
After reading the article it became clear that what Comcast is doing is much more evil. They're setting RST flags on packets (or maybe spoofing new packets in the right segment range with it set), which causes the entire connection to abort rather than just be slowed down. It could cause a lot of grief if their filter misidentifies something as p2p and starts shutting down the connections, as apparently happens to Lotus Notes traffic.
That last link has some good packet dumps of it happening.
Slashdot Mirror
The evidence is overwhelmingly against them (the sabotage is plainly visible in their own code)
I pretty thoroughly debunked this in the original discussion, but it seems once people have decided someone's out to get them they're immune to all forms of logic and reason.
The short version is, you can't assume that the presence of a table for Linux is evidence of malice. It probably came from AMI that way (dummy tables for Windows and Linux), and they just put their hardware info into the Windows section. Being lazy they didn't bother to fix the Linux section since hey, the boss says they don't support Linux!
Stupid yeah, especially since they could just remove the check altogether if they didn't want to have 2 different tables. On purpose? I suppose it's possible, but the evidence doesn't prove anything.
The code that the original poster said was put there to "deliberately crash the kernel" did nothing of the sort. The OP didn't know the first thing about ACPI and was talking out his ass -- there was nothing wrong or against the spec in the fragments he posted. Most likely a dumb mistake (one that wouldn't have even been caught by compiler warnings since it looked to be a timing bug) exposed subtle differences in the Linux ACPICA.
Search for my post in the other thread of you want the technical details of it all.
What are the implications for things such as water purification, desalination, etc?
Seems like a fuel cell "battery" is just the tip of the iceberg.
Ideally, there would be an official "ACPI certification" offered by ISO or some not-for-profit third party, and both the vendors and Microsoft would have to comply.
I'd even settle for Intel, since they wrote the reference ACPICA implementation (which happens to be used by Linux).
Might be tough though, since MS is an ACPI parter and would presumably oppose such a certification. I wonder who, if anyone, has control of the name and trademarks.
Yes, but fortunately MS isn't the only partner in ACPI, and Bill Gates doesn't get the final word on it.
Look at the state of things. Intel, who did a fairly large chunk of the work on ACPI, wrote the reference interpreter. Intel's interpreter is what is used in Linux, FreeBSD, and several other operating systems. Intel periodically releases updates and fixes to make sure that it correctly supports the published ACPI specification.
MS has their own hacked together interpreter that's fairly broken. The only MS-specific ACPI extensions I know of are implemented in separate tables like WHEA, and not in the DSDT.
The bottom line are, BIOS writers are lazy and often the tables they produce don't meet the ACPI specification. If it boots windows, it's good enough and it goes out the door. I'm all for campaigning for standards support, but making unfounded accusations and attacking their support reps isn't the way to do it.
Grep for "mutes", if you want to. Tell me, why the fuck would a machine need its serial ports (IO port range from 0x3f8, about the oldest hardware on a PC, present from before the IBM XT) disabled on Linux and not on Windows?
TFA is wrong about this. Re-read TFA. See my post here. Verify by reading the ACPI spec if you wish.
It's 3e8, not 3f8. It's the second parameter to Acquire() which is a timeout. 3e8 = 1000 = 1 second. There's nothing inherently wrong with that statement in an ASL. The fact that it crashes if you don't change it is likely an artifact of some more complex synchronization problem and subtle differences between ACPI implementations.
Furthermore, the Windows side of the ACPI code checks repeatedly that it is indeed running on Windows. And not from any information provided by the ACPI interpreter, oh no: they poke the hardware as a sort of a secret handshake. This is clearly written with intent to prevent Linux from impersonating Windows to the ACPI code.
Evidence?
All I see on the matter is an assertion posted by the original author of the thread. The only code excerpts he provides shows a match against _OS. Hardly a secret handshake. Given that he doesn't seem to understand what Acquire() does (one of the more basic ASL operators), I don't have much confidence in his knowledge of ACPI or his ability to analyze the dump.
He also adds an _OSI("Linux") section in his revised code, which will never be evaluated since Linux lies and doesn't identify itself in _OSI. Might as well just remove the whole section.
No, it allegedly has a bunch of checks for Linux strewn about in random places which then give bad data upon detecting Linux.
The only person claiming that is the original poster in that thread, whose correspondence with Foxconn and the (!) FTC is instantly accusatory and full of assumption. It's almost as if he started with the premise that Foxconn was actively breaking Linux to be anticompetitive and looked for evidence to support it.
I'd have to see a full DSDT dump to be sure, but from the excerpts posted it looks like "active checking" is just matching against _OS instead of using _OSI, which is a mistake a naive BIOS writer unfamiliar with the spec could easily make. It doesn't help the issue that Linux lies about its identity in _OSI.
The "redundant checks" seem to be present for the Windows code path too, and look more to me like bad spaghetti code copied and pasted multiple places.
I also take issue with
Find and replace all seven occurences of Acquire (MUTE, 0x03E8) and replace with Acquire (MUTE, 0xFFFF), it appears they're trying to crash the kernel by locking a region of memory that shouldn't be locked, but without access to their source code comments, I can only speculate, this tells it to lock a memory address that is always reserved instead. ;)
It's obviously not trying to crash the kernel, that's not how Acquire() works. The second parameter is a timeout, not a memory address. 3E8 hex = 1000 decimal. The BIOS writer was trying to acquire a mutex with a 1 second timeout.
Changing it to 0xFFFF makes it wait forever, which could potentially cause worse problems as execution will get stuck if the mutex is already held. Multithreaded synchronization is a very tricky problem, and I'm not surprised to see they got it wrong. Without examining the code it's impossible to say what effect TheAlmightyCthulu's changes have, if they're correct or if they merely mask the problem.
Saying they're trying to deliberately crash the kernel is a bit ridiculous.
But then again I'm a BSD guy, so I don't start out with a chip on my shoulder and assume everyone's out to get me. Have seen a ton of shoddy BIOSes in my time though.
These errors only mean that he's stuck using APM in place of ACPI.
Good luck using things like oh, multiple cores, without ACPI. A lot of boards I've seen recently don't ship working MPS info, and half the time they don't even have correct routing in $PIR.
If they didn't support Linux, and were not incompetent, they would remove the OS check altogether and just use the "Windows" table for everything. This is probably already what happens for other unsupported OSes that are not Windows or Linux, such as FreeBSD.
If Windows, it sends the good tables. If Linux, it sends the deliberately faulty ones.
It's still more likely incompetence than conspiracy. Most motherboard manufacturers don't write their own BIOS - they buy a stock one from AMI/Award and make a few changes for their particular board.
What they most likely did was update the DSDT tables handed out to Windows to reflect their hardware, but didn't bother changing the others. So for Linux (and perhaps Win9x) it just has the generic tables that came with the BIOS, which of course don't work for their particular board.
Of course, a BIOS even having per-OS tables is indicative of poor design, since being OS-independent is kinda the whole point of ACPI. That's more of an issue with whoever wrote the BIOS in the first place, though.
While they're probably not out to actively sabotage Linux, it's still poor customer service to refuse to fix it and claim that everything is working fine. Sadly, getting most board manufacturers to fix their broken DSDT tables (and there are a lot out there) is akin to pulling teeth.
You do realize that plants are much more efficient solar collectors than photovoltaic cells?
They're a lot easier to make too.
The problem is that trying to sell programming tools to programmers is kind of like trying to sell fish to a fisherman.
Sure, the lazy ones might buy it if it's cheap enough, but if the price is too high or the quality isn't worth it, they'll just write their own...
...but more dangerous content/extentions like exe's, zips, tar.gz's, bz2, py, and iso's py?!?!?!What I find interesting that pl is not listed, even though it's clearly more dangerous. You're a lot more likely to have an aneurysm while trying to read perl code than python.
http://en.wikipedia.org/wiki/Debt_of_Honor
(see the last paragraph)
One of many I'm sure
I like it -- the universe is just a giant bowl of particle soup conjured from chaos because God was hungry.
:)
Sounds like the start of a beautiful new religion
In other words, if God didn't want us to be trying to determine our origins and the way that the universe works, questioning everything along the way, why would he give us such strong curiosity about it?
Been a while since I've looked at anything on TV, is Spike still the CSI channel?
Actually the NT kernel is decently designed, and kernel-level exploits in Windows have been fairly rare (though there have been a few).
It's the Win32 layer and all the random services that run as SYSTEM (half of them OEM junk or stupid things like scanner drivers) that have had the most problems.
Don't run the game as an admin. Then it can't open the raw partitions (which it shouldn't be trying anyway). Copy the files over (wow doesn't need to be "installed" per se), change permissions on the directory, login as your unprivileged user.
No, it's just because Vista sucks.
I've also been a little suspicious of warden, so I run wow on XP as a separate normal (what's called "limited" in the home version) user. It was "installed" as a user, runs as a user, and applies the updates as a user just fine. Just took a little tweaking of some directory permissions beforehand, but only on its own program directory -- nothing under %SYSTEMROOT% or crap like that. I'm 100% certain that warden can't access anything other than the completely empty user account wow runs under.
I put "installed" in quotes because my preferred method for installing wow is to just copy the whole directory over from another machine. On my FreeBSD box the installer doesn't work in wine anyway, so that's the easiest method to get it loaded. Works fine, no registry settings or anything. It runs under a (separate) unprivileged user there too.
I don't know why the updates don't work in Vista as a normal user. I assume it has something to do with Vista's bizarre security model where file permissions don't seem to mean what they should on certain magic directories (i.e. Program Files). Turning off UAC may help.
I'd also like to give a shout out to both the WoW and City of Heroes dev teams for supporting OpenGL as a graphics option (the only option in the latter). Doing that makes them run quite well under wine due to avoiding the Direct3D emulation layer. I have to admit I was floored when I tried it. I've never managed to get anything more complicated than calc.exe to successfully run under wine before, but both of those games run flawlessly with almost no effort on my part.
I can't say for sure how many times it has to be returned before they pull it, other than that the number is > 1.
Whenever I have to visit Fry's I make sure to always check the box for the "Sticker of Shame" indicating that the product has been returned before.
The whole world does translate around me, however.
I, for one, welcome our humor-impaired crackhead moderator overlords.
Do your worst, my karma ain't going nowhere.
I, for one, welcome our giant super-intelligent mutant cockroach overlords.
Source quench is an ICMP message, similar to destination unreachable but less severe. It's a way for a host to tell another host (or router) that it's sending data too fast for it to process and should back off. It was an early attempt at preemptive traffic control to throttle back before something has to start dropping packets.
There's not a whole lot of equipment that sends them, but pretty much every OS I've come across honors the messages to some extent. I don't know if the cheap NAT routers that many people use pass them along or not, though NAT in general tends to be fairly broken when it comes to ICMP.
If a man in the middle were to spoof ICMP source quench packets that looked like they came from either of the p2p nodes that were communicating, the effect would be that they would start sending data more slowly to each other. The connection would still be open, they just wouldn't transmit as fast as they could.
After reading the article it became clear that what Comcast is doing is much more evil. They're setting RST flags on packets (or maybe spoofing new packets in the right segment range with it set), which causes the entire connection to abort rather than just be slowed down. It could cause a lot of grief if their filter misidentifies something as p2p and starts shutting down the connections, as apparently happens to Lotus Notes traffic.
That last link has some good packet dumps of it happening.