The reason is that SGX doesn't do remotely the same thing that AMT and ME do. Code that uses SGX doesn't gain privileges it didn't have (in fact, it loses privileges even compared to normal usermode code). It can be scheduled/killed by the OS the same as any other user code, and the feature can be disabled wholesale via firmware (the processor will not shutdown after 30 minutes like it does when ME is prevented from running). The code running in the enclave is also not encrypted; only data it generates at runtime is, so you can inspect it and decide whether you want to run it just fine. Kernels can't even use it directly, so I'm not sure how SGX helps anybody "make all the decisions for you".

In fact, SGX is probably the only way to get some semblance of a defense against compromised ME and SMM code. There's even a number of open source projects that use it (e.g. [0]). To be even more dramatic, not every acronym Intel comes up with is Pure Evil.

[0]: https://github.com/ayeks/TresorSGX

SGX, if they allow arbitrary code to be signed, is amazing. It enables remote trust. You could execute jobs "in the cloud" without anyone being able to see your data. You could write a known-correct coin tumbler or trading platform.

If it does only get locked to a few code authors, that would be a tremendous shame.

If Intel is the one source of ultimate trust, why not just run your secure whatever on Intel's servers? Seems a lot less complex than jumping through all these SGX hoops.

companies that make the bios were* the other sources of "ultimate trust". why not let them...

*then came uefi.

hoop-jumping never a problem with the i.t. market. more complexity is fine so long as managed by someone else. only the sales pitch needs to be simple.

why is it unfathomable that users could only trust themselves and other users? continual push toward more complexity helps keep users from ever believing this is achievable.

Yeah it's will bring new amazing spyware and ransomware on millions of PCs.

Can you explain how, exactly? Spyware would need to call out to system APIs to do anything useful, and that's not something that can be done inside an enclave.

Sure, it'd let you be a bit sloppier with randomware, not needing public key crypto to make it all work. Not really a huge deal.

Yes I can. In past there was many cases when normal software and even distributed drivers contained different kind of malware. After some point someone find it and it's become detectable, there was scandal and way to remove it. Also there was very serious risk that if some company put backdoor into their software it's will be found and company will be sued at least.

If something like SGX become publicly available then a lot of proprietary software and content manufacturers going to use it for DRM purposes. So efficiently it's will be everywhere.

Now imagine that every company can put sleeping backdoor in their software that can't be found by reverse engineering. Then they can activate it on demand for purposes of industrial espionage. Or they can simply ship own version of backdoor to ever customer and then pretend it's was some "bug" when someone detected it's activity.

I think you might not understand SGX's capability. It's just a compute kernel. So if they're taking data from your system, that's still very visible. And if they are sending data, that's also visible. So, sure, it's handy to hide logic. So the WannaCry thing, you'd be able to see it does DNS queries, but not how it determined a certain outcome based on the inputs. But you can't hide, for instance, a keylogger.

I perfectly understand what you pointing to, but problem of black box running in every piece of software is massive. Anyone could use it to implement remote backdoor in software and then pretend it's just a DRM that talking with licensing server.

Yeah it's could be detected when it's start to be active, but it's doesn't have to. It's could be idle on PC for years undetected just waiting for remote command, trigger or special payload just for you.

PS: Also fact that secure enclave itself can't access system API mean nothing because half of software already have interpreters in it as well as frameworks for every possible activity bad or good.

It's not a black box. SGX code is unencrypted even at runtime, and as long as its running that code has to remain present and unencrypted. You can detect it at any time, not just when it starts up.

A bit too late response, but anyway. There is already apps that use SGX to safely work with DRM or private keys. If there is a way keep keys secret what would stop anyone from implementing interpreters that will keep code secret?

Or plausible deniability.

SGX https://en.wikipedia.org/wiki/Software_Guard_Extensions

SGX is the ultimate DRM. Once SGX programs talk directly to monitors that support some HDCP like protocol, it will be the end of ad/tracker blockers. Web pages will run in SGX land.

The ultimate DRM is a system that runs unencrypted code with unencrypted inputs/outputs (i.e. trivially simulated) with an attestation mechanism for providing some evidence that the output is in fact from that algorithm? The most DRM-ish thing I can think of doing with that is making sure that e.g. your browser runs whatever script the server sends, except you can feed it fake data (it can't communicate with the outside world except through code you control) and you can view and modify the code and run it in parallel outside SGX. Hardly ultimate.

Technology isn't intrinsically good or evil. It's how it's used, like the death ray.