If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
@GraysonPeddie
Maybe you want to read the article again. I think that is the part where Mark Shuttleworth calls for an end to ACPI (italics in original):
Arguing for ACPI on your next-generation device is arguing for a trojan horse of monumental proportions to be installed in your living room and in your data centre. I’ve been to Troy, there is not much left.
On the topic, I think Mark Shuttleworth is completely right. I would go even further and say that UEFI (a horribly complex specification, whose implementations clock in at dozens of MB of code) should be placed right next to ACPI on the list of things to be abolished.
Operating systems have been able to be biosless, one day I hope we have an open computing platform however with intel incorporating more and more drm it's likely we are going in the opposite direction. Even AMD seems to be headed that way.
It's always possible to reject DRM support. Example: AMD knows that any DRM code let into the Linux ecosystem will be instantly cracked. They still open-sourced their UVD for recent cards-by finding and stripping out the DRM support. The cards support Blu-ray DRM that we don't use, but can be run in Linux with that support disabled or removed.
If a DRM'ed CPU or other device comes out that refuses to run other software (example" Windows Surface w/ Windows rt) we can refuse to buy it. It's harder to buy computers for Linux than it was a couple years ago, but the supply of good used hardware grows and grows. For a platform not used for something like video editing, any board with a PCI-e slot supporting an AMD Athlon X2 or better/Core2 duo/quad or better, amounts to a lot of hardware circulating on ebay, from the dumpster, surplus auctions, you name it. For video editing, a Core 2 Quad or Phenom X4 is the minimum, for gaming add an r600 or RadeonSI class ATI/AMD card.
Had UEFI been hard-locked against us to the point that a "bus pirate" was needed to remove the locking code, you'd see a lot of bus pirates sold, like modchips for gaming consoles are sold legal or otherwise. As Linux gets harder to install in newer systems, the value of the immediatley previous systems in the used market will climb, and fewer of those systems will be discarded outright. The last generation of hardware that we can use will be the best ever produced for our purposes and can be stockpiled.
Due to the uncertain future of the computer industry, I do not discard any computer hardware capable of running DSL (Damned Small Linux).
Alan Cox has been complaining about ACPI for quite a while now. Welcome to the party, Mr. Shuttleworth.
Check this out from the ACPI article on Wikipedia:
"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.[8]"
2001! Again, welcome Shuttleworth.
More stuff:
"The fact that it takes more code to parse and interpret ACPI than it does to
route traffic on the internet backbones should be a hint something is badly
wrong either in ACPI the spec, ACPI the implenentation or both."
-- Alan Cox
"With the current ACPI code in my test boxes it seems to be no worse than
APM, unfortunately it would be hard to be worse."
- Alan Cox on the ACPI mailing list
Oh and this one is good too:
"The fact that ACPI was designed by a group of monkeys high on LSD, and is
some of the worst designs in the industry obviously makes running it at
_any_ point pretty damn ugly."
@GraysonPeddie
Maybe you want to read the article again. I think that is the part where Mark Shuttleworth calls for an end to ACPI (italics in original):
Arguing for ACPI on your next-generation device is arguing for a trojan horse of monumental proportions to be installed in your living room and in your data centre. I’ve been to Troy, there is not much left.
On the topic, I think Mark Shuttleworth is completely right. I would go even further and say that UEFI (a horribly complex specification, whose implementations clock in at dozens of MB of code) should be placed right next to ACPI on the list of things to be abolished.
I suppose it'd be nice to see a working example of that as I did read the article entirely.
"Arguing for ACPI on your next-generation device is arguing for a trojan horse..."
I want proof or I can include a video card which also contains executable firmware that needs to be banned as well. How do you know Mark is right? How do you know that?
Perhaps a video will show me proof of a working example. (Sigh) I don't know...
EDIT: Oh, I didn't read the rest of the thread... Hold on a minute...
Many hardware suppliers use closed firmware to diversify their products, based on the same chipset.
They even tell you that this is one crucial pillar of the business.
It's not hard to see that they simply won't change this - unfortunately.
I agree with the "utopia" reference to a certain extent, but that isn't everything.
I think the manufacturers that deploy products that use ACPI have to share the bulk of the blame for the insecurity issues. Very few ACPI implementations that I have seen do not kick out errors in "dmesg" during the boot of even very very recent kernels (=> 3.12). I have seen cases where ACPI instructions point to non-existent portions of code, where ACPI instructions point to variables outside the range, etc. Basically the manufacturers are sloppy; it's the "gee wiz it compiles and boots up so ship it out before XYZ gets their feature out there" mentality.
Please notice that I haven't poked at low paid programmers. Low pay does not always equate to poor quality; poor quality control equates to poor quality code.
And for those curious about ACPI code, try out the "iasl" disassembler on Linux. Copy over the ACPI tables as found in "/sys/firmware/acpi/tables" to a safe "working" directory, then start disassembling them using "iasl". Granted the output of most of those tables is virtually incomprehensible to another other than an ACPI programmer with a well documented ACPI programming reference guide, but you can look at the resulting code.
Last edited by NotMine999; 17 March 2014, 03:20 PM.
@GraysonPeddie
Maybe you want to read the article again. I think that is the part where Mark Shuttleworth calls for an end to ACPI (italics in original):
Arguing for ACPI on your next-generation device is arguing for a trojan horse of monumental proportions to be installed in your living room and in your data centre. I?ve been to Troy, there is not much left.
On the topic, I think Mark Shuttleworth is completely right. I would go even further and say that UEFI (a horribly complex specification, whose implementations clock in at dozens of MB of code) should be placed right next to ACPI on the list of things to be abolished.
UEFI is a useless but glamous GUI interface to the system BIOS for the "point & click" crowd.
For the "point & click" crowd: Geez people. Try using a keyboard...quick, easy, works every time unless you have one with billions of added buttons for doing who knows what.
I want proof or I can include a video card which also contains executable firmware that needs to be banned as well. How do you know Mark is right? How do you know that?
Yes, that needs to be banned as well. I highly recommend Peter Stuge's (of CoreBoot fame) talk at 30C3 "Hardening hardware and choosing a #goodBIOS". An IOMMU can mitigate the threat from malicious PCI devices in theory, but not always in practice.
Comment