Live data from Hacker News

Intel deprecates SGX on Core series processors

edc.intel.com

31–40 of 138 posts

Re: Intel deprecates SGX on Core series processors

#31

Earlier quoted context omitted.

Looks like it causes memory ordering issues [1] on the affected processors. You can turn the capability back on with a flag, but Intel warns this is "not for production use" [1]: https://cdrdv2.intel.com/v1/dl/getContent/604224

Wow, I see, thanks. Makes you wonder why they couldn't fix it instead—sounds like it was a fundamentally difficult problem to solve?

It is a fundamentally difficult problem to solve. On top of that, the costs grow exponentially with core count and processor scaling compounds.

If you look back at so many of the intel architectural extensions it is so hard NOT to draw the conclusion that Intel has a POOR understanding of where problems should be solved. They constantly try to solve problems which should be solved in software with hardware. This is why they are now an architectural generation behind AMD and why they are most likely going to lose the CPU market to Apple imitators.

Unless AMD can maintain its success despite the talent bleed it will start to face — the days of x86 are limited.

Re: Intel deprecates SGX on Core series processors

#33

The more interesting thing to me than SGX is that all of TSX-NI is deprecated? Not just HLE, but RTM too? Meaning there'll be no more software transactional memory at all?! Anyone able to shed any light on why they're doing this? Is it just security or is it just not worth it even regardless of that? Is there a chance they'll reintroduce it in some form, perhaps in other processor series?

"Anyone able to shed any light on why they're doing this?"

Same question here, As usual, no reasons are given (must admit I'm getting sick of these corporations failing to explain their actions). Right, I'm old enough to remember when companies used to issue detailed revisions sheets/documentation wherein they described what the changes were and the reason for them just as a matter of course.

(Even after being an unwilling member of the users' mushroom club for some 20/30 years, I'm still having difficulty adjusting.)

Re: Intel deprecates SGX on Core series processors

#34
post #7

Earlier quoted context omitted.

On consumer CPUs DRM may have been the only use case, and indeed good riddance. But on the server side it's possible for tenants to use these hardware features to run workloads that the hosts verifiably cannot modify or inspect. In other words, this lets you use AWS/GCP/Azure etc. while keeping both your data and your code competely opaque to Amazon/Google/Microsoft etc. Disclaimer: my job is to write the software th…

Of course, that requires tenants trust Intel's security. As a security researcher and given past showings from Intel, I wouldn't put much faith in SGX, even if they try to fix past flaws. SGX as a concept for tenant-provider isolation requires strong local attacker security, which is something off the shelf x86 has never had (not up to contemporary standards, ever) and certainly not in anything Intel has put out. The…

This paper convinced me it will be at least a decade before SGX or similar have any semblance of security:

https://www.usenix.org/system/files/conference/usenixsecurit...

The basic idea is that you can play with the clockspeed and voltage of one ARM core using code running on the other. They used this to make an AES block glitch at the right time. The cool part is that, even though the key is baked into the processor, and there are no data lines to read the key (other than the AES logic), this lets them infer the key.

Hmm. The paper is 5 years old. I still think we are a decade away.

Re: Intel deprecates SGX on Core series processors

#35
post #30
post #27

Earlier quoted context omitted.

How do you know that when your software calls SGX instructions from inside a VM, that it's actually getting the hardware CPU's SGX implementation, rather than an arbitrary software SGX instruction-shim implementation provided by the hypervisor?

The CPU has keys that you verify by asking Intel, is the short of it. Of course if you're inside the hypervisor and being software emulated, it could do anything to you. The idea is you verify enclaves remotely, so no other system would want to talk to your software emulator and share it secrets. You can mess with your local copy of the enclave, but then no one else will be able to verify it remotely (because the Int…

Exactly.

And the main limitation of this approach is that it's really hard to prevent breaking a single cpu from being a class break.

You manage with glitches or side channels (e.g. spectre for sgx) to steal the per cpu secrets, and then you setup an emulator that can obtain intel attestation, then suddenly any application that depends on the impossibility of an emulator faking that attestation is broken.

It's even harder for these DRM-focused SGX like solutions because they really need the attestation to be anonymous to avoid it being a massive tracking vector and privacy breach... while a more traditional hsm attestation would still identify the device and potentially allow limiting the impact of compromising a single one.

Re: Intel deprecates SGX on Core series processors

#36
post #24
post #18

Earlier quoted context omitted.

> Of course, that requires tenants trust Intel's security. I generally agree with you. But I recently realized there might be one usecase, and it's pretty much what signal is doing. They're processing address books in SGX so that they can't see them. I don't have much faith in the system because I don't trust SGX, of course. But there is one interesting aspect to this. If anyone comes knocking and tells them to start…

Secure enclave as legal defense is an interesting angle, thanks for sharing. It's become a moral cause to make a lot of big-data computing deniable, to be data-oblivious. This is a responsible way to build an application, is well-built security, and I like it a lot.

I think “responsible” is a bit too strong a word, when most of these computations could just run on the client.

I agree this work is important and enclaves are better than nothing though.

Re: Intel deprecates SGX on Core series processors

#37
post #30
post #27

Earlier quoted context omitted.

How do you know that when your software calls SGX instructions from inside a VM, that it's actually getting the hardware CPU's SGX implementation, rather than an arbitrary software SGX instruction-shim implementation provided by the hypervisor?

The CPU has keys that you verify by asking Intel, is the short of it. Of course if you're inside the hypervisor and being software emulated, it could do anything to you. The idea is you verify enclaves remotely, so no other system would want to talk to your software emulator and share it secrets. You can mess with your local copy of the enclave, but then no one else will be able to verify it remotely (because the Int…

How do you find out what CPU your VM is running on in a compute cloud, in order to ask Intel about it? You can't go to the data center and look at the serial number printed on the chip. It's probably negative-ROI for an IaaS vendor to have the ops staff at the DC to go do that as a customer service. And AFAIK there's nothing like a control-plane API for querying a hypervisor's hardware serial numbers in an IaaS-maintained inventory DB. So presumably, you have to... ask the VM itself. Maybe using something like the (long removed) CPUID instruction's "CPU serial number" output?

Presuming you can only learn the CPU's ID through through the VM itself, then an attacker with access to the hypervisor, plus at least one private key extracted from a sacrificial CPU of the same model, could just have the VM report the extracted-from CPU's serial number, and then use the respective extracted private key in their SGX enclave emulation. And this would check out with Intel.

Or, of course, a lot more simply, you could just make up your own keys instead of extracting any Intel keys, and then have the VM rewrite any Intel CPU root certs it finds in the VM's memory to be the attacker's certs instead (and any hashes of those certs be the hashes of the attacker's certs, etc.); such that messages signed by fake-SGX validate within the VM, and messages encrypted by fake-SGX decrypt within the VM, and messages encrypted by the VM decrypt within fake-SGX. In other words — don't keygen the user's workload; crack it. The SGX enclave is very rarely used in such a way where the component checking it is running on anything other than the same VM calling into it, so why bother worrying about what other untainted machines communicating with the enclave might see? That'd be like worrying about what more-sensible third-parties might tell your victim in a confidence scheme.

Re: Intel deprecates SGX on Core series processors

#39

The more interesting thing to me than SGX is that all of TSX-NI is deprecated? Not just HLE, but RTM too? Meaning there'll be no more software transactional memory at all?! Anyone able to shed any light on why they're doing this? Is it just security or is it just not worth it even regardless of that? Is there a chance they'll reintroduce it in some form, perhaps in other processor series?

TSX has never worked, and it seems a little over-ambitious in general. SGX has a few fatal flaws in its security model, and we have moved on to newer models there. The principle of tech debt applies to hardware as well as software, and I hope they come up with a new idea for transactional memory in future cores that actually works, and isn't so ambitious.

Re: Intel deprecates SGX on Core series processors

#40
post #27
post #7

Earlier quoted context omitted.

On consumer CPUs DRM may have been the only use case, and indeed good riddance. But on the server side it's possible for tenants to use these hardware features to run workloads that the hosts verifiably cannot modify or inspect. In other words, this lets you use AWS/GCP/Azure etc. while keeping both your data and your code competely opaque to Amazon/Google/Microsoft etc. Disclaimer: my job is to write the software th…

How do you know that when your software calls SGX instructions from inside a VM, that it's actually getting the hardware CPU's SGX implementation, rather than an arbitrary software SGX instruction-shim implementation provided by the hypervisor?

[deleted]
Post reply on HN