Hacker News Reader

Comment by Unklejoe | Hacker News Reader

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

View on HN

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

The 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!

> 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-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-v... [in German]

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

It'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?

Intel seems to gate their management features through the chipsets instead, with vPro as the primary user-accessible interface being limited to business lines.

> 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/

AFAIU SGX has nothing to do with the ME. It's entirely in the CPU and MMU. SGX is more like ARM's TrustZone, except it can be utilized by multiple, independent pieces of unprivileged code. SGX is pretty slick. The only real problem is that 1) Intel has done a horrible job of educating developers, 2) Intel's PKI scheme for remotely verifying authenticity of an enclave (e.g. for DRM schemes) requires huge on-going license payments to Intel, and 3) they don't seem keen on rolling it out across their entire processor line-up. All three cases have been and will continue to be serious impediments to uptake because of the confusion they create. Those impediments are likely to keep SGX niche and underutilized.

Thanks, it seems you are right. I thought that the ME plays some role in SGX setup but I can't find a single source for that now. Apparently it's all done with special instructions implemented in microcode.

The 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.

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

Yes, 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.

Hmm, 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.

It'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.

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

> Intel ME is used by Linux quite heavily (rather than talking directly to the embedded controller)

Are you sure? Links or commit IDs?

Here'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/me... [2]: https://en.wikipedia.org/wiki/Host_Embedded_Controller_Inter...

HECI is same thing as MEI (see your [1]) and, despite the misleading name, it's unrelated to the EC.

Ah okay, I stand corrected. Thanks.

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

Shh, you're not supposed to say that out loud. You don't wanna be labeled a conspiracist, do you?

I would be happy for AMD to release the hw spec, allowing an open source PSP implementation.

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

No, 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)

Reply on news.ycombinator.com