Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel deprecates SGX on Core series processors

edc.intel.com

Post reply on HN
Print view View original

21–30 of 138 posts

Re: Intel deprecates SGX on Core series processors

#21

Post by nickelpro »

dataflow wrote: post #19

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?

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

Re: Intel deprecates SGX on Core series processors

#22

Post by dataflow »

nickelpro wrote: post #21
dataflow wrote: post #19

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?

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?

Re: Intel deprecates SGX on Core series processors

#24

Post by rektide »

lawl wrote: post #18
marcan_42 wrote: post #13

Earlier quoted context omitted.

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…

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

Re: Intel deprecates SGX on Core series processors

#26

Post by kibwen »

marcan_42 wrote: post #13
kibwen wrote: 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…

Indeed, it remains to be seen whether or not SGX2 will be trustworthy; the proof is in the pudding. However, other vendors have their own solutions to the same problem, and least AMD's approach is radically different, so one hopes that at least one of them will stand up to scrutiny.

Re: Intel deprecates SGX on Core series processors

#27

Post by derefr »

kibwen wrote: post #7
josephcsible wrote: post #2

Good riddance. (For those unaware, basically the only use-case of SGX was hardware-enforced DRM.)

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?

Re: Intel deprecates SGX on Core series processors

#28

Post by hedora »

dataflow wrote: post #19

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 always been kind of useless. They got repeated feedback that they had to document what would cause deterministic spurious rollbacks (usually bad cache interactions within the same transaction causing lines to spill), so that applications could be written without the slow (non hardware assist) fallback path.

Oh well. Maybe some other company will build hardware transactions in a way that takes developer feedback into account.

Crosspoint DIMMs had an analogous problem. There was no way to pin a cache line for updates, so that it couldn’t spill to persistent storage mid page update. Some cool workarounds came out of the research community, but, in the end, that technology is dead on arrival too.

Re: Intel deprecates SGX on Core series processors

#29

Post by my123 »

dataflow wrote: post #19

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?

All of TSX is present on Intel server processors. Just gone from client.

Re: Intel deprecates SGX on Core series processors

#30

Post by tux3 »

derefr wrote: post #27
kibwen wrote: 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?

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 Intel CPU won't sign it like you need it to)

Post reply on HN