4 ms·
One thing that kind of bothers me is that I keep seeing people justify this decision by mentioning that AMD may be using third party source code which they do n
by Unklejoe 9y ago
One thing that kind of bothers me is that I keep seeing people justify this decision by mentioning that AMD may be using third party source code which they do not have the license to release.
My issue with that is that I don’t see how it prevents AMD from releasing a super stripped down (essentially disabled), but still closed source version of the firmware. There may very well be a valid justification for not doing so - I just don’t know.
An even better approach would be to allow the system to run without the firmware at all. If I remember correctly, some Intel machines will run for 30 minutes without the firmware, but will shut down after the time elapses. If true, that at least proves that it’s not essential for system operation.
In the case of Intel, surely they could have disabled this 30 minute timer on the consumer CPUs (just like how they disable ECC support).
- cyphar 9y agoI think the justification is economic. They don't remove it because it's not clear that there is a market for not having ME. The reason (I think) they remove ECC support is that people are willing to pay extra for it, so they remove it so you are forced to pay extra. If they removed ME in consumer CPUs, they wouldn't sell any more consumer CPUs and their enterprise management system wouldn't be any more popular. There are also some additional problems. Intel ME is used by Linux quite heavily (rather than talking directly to the embedded controller) which means that certain things can become quite flaky. I have Coreboot on my X220 with me_cleaner, and my machine seems to freeze randomly (it's definitely not the 30-minute timer, I just think it's IO being deadlocked for some reason). While your machine may appear to work without ME, there are almost certainly features that won't work.
- jonathanstrange 9y agoThe interesting question is whether someone could reverse-engineer this and publish everything they find freely on the Internet? It surely can't be easy, but just imagine someone would do that, maybe even be so irresponsible as to publish exploits! That could become a nightmare for AMD and Intel!
- wolfgke 9y ago> It surely can't be easy, but just imagine someone would do that, maybe even be so irresponsible as to publish exploits! That could become a nightmare for AMD and Intel! Something similar happened just a few months ago: It all started with this article: > http://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/ http://semiaccurate.com/2017/05/01/remote-security-exploit-2... which was considered as sensationalist. Just a few days later facts appeared in less sensationalist language: > https://www.heise.de/security/meldung/Sicherheitsluecke-in-vielen-Intel-Systemen-seit-2010-3700880.html https://www.heise.de/security/meldung/Sicherheitsluecke-in-v... [in German] > https://www.heise.de/ct/artikel/Tipps-zur-Intel-ME-Sicherheitsluecke-SA-00075-3704454.html https://www.heise.de/ct/artikel/Tipps-zur-Intel-ME-Sicherhei... [in German] An analysis of the bug source: > https://www.tenable.com/blog/rediscovering-the-intel-amt-vulnerability https://www.tenable.com/blog/rediscovering-the-intel-amt-vul... --- What finally happened: A set of firmware updates was released by Intel to the hardware vendors. These were installed by careful admins and users. After this the story mostly got forgotten. So the bug source was indeed probably a nightmare for Intel - but the public did not really care for it except for some nerds.
- pjc50 9y agoIt's quite easy to build CPUs which have features disabled at manufacturing by one-time fuses, or laser fuses. Also there is undoubtedly a (maybe small) bin of CPUs which have failed QA only because of a fault in the management engine. Back in the days of the 486SX/DX, it was far more normal to sell processors with features disabled for less money. Why don't AMD and Intel want to monetise their management features?
- detaro 9y agoIntel seems to gate their management features through the chipsets instead, with vPro as the primary user-accessible interface being limited to business lines.
- qb45 9y ago> Why don't AMD and Intel want to monetise their management features? They do, most machines don't have remote management firmware and chipset features installed. As for why the ME is present on all hardware - it would be a shame if your consumer CPU couldn't securely decode super-4K-full-ultra-HD videos, right? Besides DRM, I think the ME is also used for SGX. Intel(R) Software Guard Extensions (Intel(R) SGX) is an Intel technology for application developers seeking to protect select code and data from disclosure or modification. Maybe Intel wants to create some "ecosystem" of software utilizing SGX (because vendor lock in) and for that they want as large hardware base as possible. That's just a guess, I haven't read Intel docs and IDK if any off-the-shelf SGX software exists yet, but I have seen similar ideas in some AMD PSP PDFs. edit: FWIW, Intel Wikivertisement on SGX: The introduction of SGX has a large impact on the security industry. It shifts how security is being achieved and lowers the attack surface area of projects. One example of SGX used in security was a demo application from wolfSSL using it for cryptography algorithms. One example of a secure service built using SGX is Fortanix's key management service. This entire cloud based service is built using SGX servers and designed to provide privacy from cloud provider. An additional example is Numecent using SGX to protect the DRM that is used to authorize application execution with their Cloudpaging application delivery products. The last one seems like something that could benefit from SGX on end-user devices: https://www.numecent.com/cloudpaging/ https://www.numecent.com/cloudpaging/
- mseebach 9y agoThe economic pressure to fix this, if it happens, will come from the enterprise side: Some large, cyber-security-conscious (that should be all of them, but alas) customer moving towards a policy that bans unauditable MEs with DMA.
- cyphar 9y agoBut those same enterprises like being able to manage their employee's laptops using Intel's management system (which is why Intel ME has its backdoor features).
- mseebach 9y agoYes, of course. There are plenty of legitimate uses of a management platform. But they also like (or should like...) to be sure they're the only ones who can do so.
- adrianratnapala 9y agoHmm, I admit this is an anecodate rather than a statistic, buut, 100% of large corporations that I know of which have an opinion on these things (all one them) laugh Intel's AMT and are glad they have done what they can to disable the firmware (they can do more than you or I can do). Giant corporations are perfectly capable of controlling their own laptops.
- cyphar 9y agoIt's quite clear that people are buying Intel's management systems, which use Intel AMT and Intel ME. So you're right that it's just an anecdote, because it doesn't explain why people are buying those products.
- mtgx 9y ago> I think the justification is economic. They don't remove it because it's not clear that there is a market for not having ME. Yes, especially when you stand to lose billions of dollars in contracts with the DoD by removing the remotely exploitable ME from processors. It's probably that kind of economic loss.
- qb45 9y ago> Intel ME is used by Linux quite heavily (rather than talking directly to the embedded controller) Are you sure? Links or commit IDs?
- cyphar 9y agoHere's the kernel documentation about the Intel MEI driver (Management Engine Interface) which describes the /dev/mei node that allows you to manage AMT and other things on your local machine[1]. And HECI[2] also goes through Intel ME. So anything that uses either of those things requires Intel ME, and Linux provides support for both. I also believe that I've read somewhere that the reason you need to use tools that talk directly to the EC to modify things like battery levels with coreboot (as opposed to the "standard" tools used on stock machines) is because of the lack of those interfaces for Linux. I may be mistaken about the latter, but it is definitely true there are useful things that Linux does provide support for (and might use internally, I'm not sure). [1]: https://www.kernel.org/doc/Documentation/misc-devices/mei/mei.txt https://www.kernel.org/doc/Documentation/misc-devices/mei/me... [2]: https://en.wikipedia.org/wiki/Host_Embedded_Controller_Interface https://en.wikipedia.org/wiki/Host_Embedded_Controller_Inter...
- Carley34 9y agoMy Uncle Henry recently got an almost new gold Audi RS 5 Convertible just by some part time working online at home... > see it here>>>>>>>>>>>http://www.joinmate2.Com http://www.joinmate2.Com
- zyx321 9y ago>There may very well be a valid justification for not doing so - I just don’t know. Is there even any question at this point? The NSA doesn't want them stripping out their backdoors. Remember when Intel 'accidentally' managed to screw up a simple string comparison in a way that would conveniently allow remote access without password?
- timonovici 9y agoShh, you're not supposed to say that out loud. You don't wanna be labeled a conspiracist, do you?
- alerighi 9y agoNo, because the firmware is in some part written in a ROM inside the CPU (for security reason, at least the part that has to verify and load the rest of the firmware from the external flash memory), so there is no way to replace it or even disable it (if there is a way, you could see it as a potential backdoor, and also an attacker could disable the firmware and bypass secure boot for example)
- deleted 9y ago[deleted]
- digikata 9y agoI would be happy for AMD to release the hw spec, allowing an open source PSP implementation.
- eip 9y ago> AMD may be using third party (NSA) source code which they do not have the license to release Which is why it can't/won't be disabled.