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

61–70 of 138 posts

Re: Intel deprecates SGX on Core series processors

#61

Post by grumpyprole »

jcranmer wrote: post #51
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?

Not a hardware architect, but my spitballing as a compiler writer: Transactional memory is one of those things that constantly sounds like it's a good idea in theory, but it doesn't live up to those ideas in practice. One of the issues with hardware transactional memory is the challenge of spurious aborts or otherwise running up against hardware limits as to how big transactions can be. Another (as far as I'm aware)…

Having used GHC Haskell's software transactional memory features to build a concurrent service with caching, I do think there are significant practical benifits. To program threaded code without needing to worry about global reasoning of fine-grained locking is a godsend. Transactional memory solves the issue of writing composable code that works on shared mutable state. Task libraries do not solve this problem.

Of course retrofitting such a feature into C/C++ in a satisfactory manner might not be possible. But the practical benifits are real.

Re: Intel deprecates SGX on Core series processors

#62

Post by melchebo »

eightysixfour wrote: post #59
Uptrenda wrote: post #49

Many moons ago, I wrote a prototype on Azure's 'confidential computing' VMs that demonstrated how a computer could 'prove' to another that it was running certain code using 'attestations.' I thought it was cool as hell, and honestly thought that if such a technology held up you could build many interesting things with it. Potentially, it would have had many use-cases in the DeFi industry, privacy-preserving computati…

It is gone now, but IIRC Microsoft was working on a blockchain for inter-enterprise settlement that ran in the secure enclave. It had extremely high throughput and all of the parties could “trust” that the code running was the same, so they were all following the same rules. Neat concept, they killed it before ever sharing source code.

https://techcommunity.microsoft.com/t5/it-transformation/mic...

Re: Intel deprecates SGX on Core series processors

#63

Post by inter_netuser »

onedognight wrote: post #57

SGX is used by Signal’s server[0] to allow an open source trust-Intel / trust-their-hardware, but no one else based private contact discovery. [0] https://signal.org/blog/private-contact-discovery/

AKA: "share your contacts with the NSA only"

Re: Intel deprecates SGX on Core series processors

#64

Post by snvzz »

femto wrote: post #56

Also the note at the bottom of that page: that they are doing away with AVX-512. A bit sad for those who need to squeeze maximum performance out of a CPU. (I gather it lives on in Xeon and Zen 4.)

Doesn't x86-64v4 require it?

This throws upside down the whole x86-64 levels concept. What a mess.

Re: Intel deprecates SGX on Core series processors

#65

Post by snvzz »

Can't wait to move on to RISC-V, where vendors can do their experiments in custom extensions without disturbing anyone.

Only that which is solid and the board can agree on becomes a ratified specification. The instruction counts are still sane[0], despite it is not missing anything of significance which ARM or x86-64 have anymore, as of the group of extensions that were ratified late 2021.

[0]. https://en.wikipedia.org/wiki/RISC-V#Design

Re: Intel deprecates SGX on Core series processors

#66

Post by tome »

eightysixfour wrote: post #59
Uptrenda wrote: post #49

Many moons ago, I wrote a prototype on Azure's 'confidential computing' VMs that demonstrated how a computer could 'prove' to another that it was running certain code using 'attestations.' I thought it was cool as hell, and honestly thought that if such a technology held up you could build many interesting things with it. Potentially, it would have had many use-cases in the DeFi industry, privacy-preserving computati…

It is gone now, but IIRC Microsoft was working on a blockchain for inter-enterprise settlement that ran in the secure enclave. It had extremely high throughput and all of the parties could “trust” that the code running was the same, so they were all following the same rules. Neat concept, they killed it before ever sharing source code.

Are you thinking of https://en.m.wikipedia.org/wiki/Confidential_Consortium_Fram...?

It is alive and the source code is shared.

Re: Intel deprecates SGX on Core series processors

#67

Post by janwas »

NavinF wrote: post #58
femto wrote: post #56

Also the note at the bottom of that page: that they are doing away with AVX-512. A bit sad for those who need to squeeze maximum performance out of a CPU. (I gather it lives on in Xeon and Zen 4.)

Meh, the few workloads that benefit from AVX-512 would be better off on a GPU. Also note that it wasn’t well received 2 years ago. Example: https://news.ycombinator.com/item?id=23809335

That's a bold claim. What are your sources? The two latest things I worked on, JPEG XL and quicksort, see a 1.4 and 1.6x speedup from AVX-512. That's on SKX and includes the much-maligned throttling. On a system level, I doubt moving those to GPU is helpful.

Re: Intel deprecates SGX on Core series processors

#68

Post by mrweasel »

snvzz wrote: post #65

Can't wait to move on to RISC-V, where vendors can do their experiments in custom extensions without disturbing anyone. Only that which is solid and the board can agree on becomes a ratified specification. The instruction counts are still sane[0], despite it is not missing anything of significance which ARM or x86-64 have anymore, as of the group of extensions that were ratified late 2021. [0]. https://en.wikipedia.o…

Wouldn’t those who cannot afford to make their own chips still be beholden to changes and business desicions of they suppliers, regardless of the underlying architecture?

What would be the difference between deprecating SGX on Intel and a similar technology on a RISC-V based chip?

Re: Intel deprecates SGX on Core series processors

#69

Post by Sirened »

nyanpasu64 wrote: post #54
DSingularity wrote: post #31

Earlier quoted context omitted.

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 w…

Why is Intel wrong for trying to solve software problems in hardware, while ARM/CHERI are celebrated for being ahead in trying to solve memory safety in hardware using pointer upper-bit tagging and now CHERI's provenance metadata (performing fine-grained bounds checks on every single pointer dereference, rather than just following instructions without performing extra work)?

I think it's less a criticism of trying to solve problems in hardware vs the _kinds_ of problems they're focusing on.

While CHERI is, from a pure theory standpoint, something that is perfectly avoidable with proper programs (i.e. memory unsafety _is_ efficiently avoidable in software), we ended up needing it we made the wrong choice in software too long ago to turn back (nobody is rewriting the Linux kernel anytime soon). In this way, CHERI is a good optimization because it does something we cannot _practically_ solve in software. ARM-PA plays a similar role in that hardware CFI can be made irrelevant by a) not having memory safety issues b) software CFI, but neither have really worked out in practice and it's cheap and efficient in hardware, so it's a worthwhile tradeoff.

Stuff like Intel TSX and ARM TME are sort of at the other end. Transactional memory is _super_ cool and it's been a common thread throughout architecture papers for the past twenty years. The thing is, we've never had transactional memory in commodity hardware (and nobody buried their heads in the sand about not having it like we did with memory safety) so all our software found decent work arounds eventually. TSX/TME does do what it says, the issue is just that it's not quite good enough when compared to existing software techniques and so the actual added value (cache noise and the resulting spurious aborts included) made it a less good deal. When adding the cost to both update software and the likely strongly polynomial (?) hardware cost of transaction support as core count grows (this is why ARM's Exclusive Monitor performs SO bad on systems with 64+ cores and why they added new atomics just to avoid the monitor), it just doesn't work anymore.

Re: Intel deprecates SGX on Core series processors

#70

Post by IshKebab »

snvzz wrote: post #65

Can't wait to move on to RISC-V, where vendors can do their experiments in custom extensions without disturbing anyone. Only that which is solid and the board can agree on becomes a ratified specification. The instruction counts are still sane[0], despite it is not missing anything of significance which ARM or x86-64 have anymore, as of the group of extensions that were ratified late 2021. [0]. https://en.wikipedia.o…

I don't see why you think RISC-V would make any difference. It's still totally possible to get official or de facto RISC-V extensions that turn out to be a bad design and get abandoned.

Just because it is too young for that to have happened yet doesn't mean it can't.

Post reply on HN