26 ms·

Intel deprecates SGX on Core series processors

130 points by thinkmassive 5y ago

josephcsible 5y ago
Good riddance. (For those unaware, basically the only use-case of SGX was hardware-enforced DRM.)
- stefan_ 5y ago
  The second use-case was MobileCoin, that cryptocoin scam Signal signed up for. Reflects well on their other crypto.
- teeray 5y ago
  I thought you could use it for HSM-type workloads too
  - thinkmassive 5y ago
    Like a third party’s HSM running locally on your computer, heh
    - teeray 5y ago
      No, like, you could use something like https://www.ego.dev/ https://www.ego.dev/ and have Vault or something that worked more like an HSM
    - lxgr 5y ago
      In other words, a smartcard :)
- kibwen 5y ago
  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 that makes this possible, and all our code is open-source and housed under the Linux Foundation's Confidental Computing Consortium: https://enarx.dev/ https://enarx.dev/ .
  - bpye 5y ago
    I'm sure you're already familiar, but for others, there is also AMD's SEV-SNP [0] and Intel's TDX [1] that solve similar problems. Azure has SEV-SNP VMs in preview [2] - full disclosure, I work at Microsoft and was involved in this :) [0] - https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthen... [1] - https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trust-domain-extensions.html https://www.intel.com/content/www/us/en/developer/articles/t... [2] - https://azure.microsoft.com/en-us/blog/azure-and-amd-enable-lift-and-shift-confidential-computing/ https://azure.microsoft.com/en-us/blog/azure-and-amd-enable-...
    - exfalso 5y ago
      In terms of security these technologies are (mostly) strictly worse than SGX, and there hasn't been nearly enough security research done on them. Also, the physical attack vectors remain (e.g. https://arxiv.org/abs/2108.04575 https://arxiv.org/abs/2108.04575). A small but interesting counterexample is x86 TSC: with SGX the MSR is modifiable by ring 0, with AMD SEV-SNP it is protected from the hypervisor. The real value of these newer technologies is not increased security, but rather increased usability. (Also, small sidenote: TDX relies on SGX.) I think the biggest contribution that cloud providers can bring to the table in the mid-term is mitigation of the physical attack vector. This would involve inserting themselves as a second root of trust in attestations (SEV has explicit support for this), which would mean that a real world attack would require collusion of multiple parties (pick 2 of Hardware vendor, Cloud provider, Software vendor).
  - marcan_42 5y ago
    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. They've demonstrated they don't have the culture nor security chops to actually engineer a system that could be trusted, IMO. Plus then there's all the microarchitectural leak vectors with a shared-CPU approach like that, and we know Intel have utterly failed there (not just Spectre; there was absolutely no excuse for L1TF and some of the others, and those really showed us just how security-oblivious Intel's design teams are). Right now, the x86 world would probably do well to listen to Microsoft, since their Xbox division managed to coax AMD into actually putting out secure silicon (they're one of the two big companies doing proper silicon security at the consumer level, the other being Apple and Google trying to catch up as a distant third). But given the muted response to Pluton from the industry, and the poor way in which this is all being marketed and explained, I'm not sure I have much hope right now...
- Jweb_Guru 5y ago
  Hardware-enforced anticheat (for certain kinds of games) is a pretty cool potential usecase.
- nullc 5y ago
  The usecase could have included all manner of useful pro-privacy and security usage-- but intel was extremely restrictive with access to the ability to use it in part because they expected to monetize the DRM usage.
- codethief 5y ago
  It's also used extensively by Signal (not just for MobileCoin, as a sibling comment suggests).
- Sesse__ 5y ago
  Interestingly enough, I believe there's now no official way of playing UHD-BR on modern Intel systems (ie. you'd have to use an AACS/BD+ crack), since all certified players needed SGX. I don't know what this means for 4K Netflix, if anything.
thinkmassive 5y ago
Looks like they deprecated the link since I first loaded the page. New link, same content: https://edc.intel.com/content/www/us/en/design/ipla/software-development-platforms/client/platforms/alder-lake-desktop/12th-generation-intel-core-processors-datasheet-volume-1-of-2/006/deprecated-technologies/ https://edc.intel.com/content/www/us/en/design/ipla/software...
thinkmassive 5y ago
They claim SGX support on Xeon is still “full steam ahead” https://community.intel.com/t5/Blogs/Products-and-Solutions/Security/Rising-to-the-Challenge-Data-Security-with-Intel-Confidential/post/1353141 https://community.intel.com/t5/Blogs/Products-and-Solutions/...
- kibwen 5y ago
  Specifically the next generation of SGX is pushing ahead, since a number of flaws were identified in the original design.
  - betterunix2 5y ago
    I'm taking bets on how long before the next generation is completely broken as well. It is only a matter of time, and the timeline is likely short.
    - ZiiS 5y ago
      Only having it on expensive chips will probably help as much as anything.
    - kibwen 5y ago
      The onus is on Intel to provide a solution that is sound. That said, there's no reason to assume that what they're doing is impossible, any more so than assuming that cryptography in general is impossible.
- no_time 5y ago
  Curious how there is no CSAM scare mongering when it's companies that need private storage of information.
  - judge2020 5y ago
    Societally, when some person or org uses a Xeon processor for CSAM distribution, nobody things "man I wish Intel stopped this". However, when it's Apple considering end-to-end encrypted iCloud Photos or iCloud backups, people (read: federal law enforcement) will blame Apple for allowing CSAM to proliferate locked away from law enforcement. edit: as for why this is bad, federal law enforcement have a lot more pull when seeking change in laws in congress. Maybe Apple would've had to implement a government backdoor into iPhone itself if they didn't pull the CSAM scanning stunt (and I imagine they knew the backlash was inevitable, which allowed them to use that backlash as reason to push back on either scanning or a backdoor).
dataflow 5y ago
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?
- nickelpro 5y ago
  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 https://cdrdv2.intel.com/v1/dl/getContent/604224
  - dataflow 5y ago
    Wow, I see, thanks. Makes you wonder why they couldn't fix it instead—sounds like it was a fundamentally difficult problem to solve?
    - DSingularity 5y ago
      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.
      - nyanpasu64 5y ago
        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)?
pjmlp 5y ago
I pity that MPX is gone as well, this makes x86/x64 lose to ARM in hardware memory tagging. While it was buggy, Intel doesn't seem keen in bringing in a replacement.
- DSingularity 5y ago
  The approach is fundamentally flawed.
  - pjmlp 5y ago
    MPX sure, that doesn't prevent bringing a new one, otherwise in a couple of years Intel/AMD will be the only ones left standing without hardware memory tagging support.
    - monocasa 5y ago
      I mean, having played with MPX for use in a JIT, it was slower than just manually bounds checking.
      - DSingularity 5y ago
        With less security guarantees too.
pvg 5y ago
related 400 comment thread from 3 months ago: https://news.ycombinator.com/item?id=29932630 https://news.ycombinator.com/item?id=29932630
userbinator 5y ago
Is the ME next? One can dream... that Intel will stop playing with all of this user-hostile "security" nonsense and focus on performance and power efficiency while also releasing all the detailed programming/design information publicly.
- stuu99 5y ago
  They aren't going to. The industry has been pushing for copyright enforcement built into the hardware and OS. Windows 10/11 is the first client-server OS, aka the ultimate security risk since you all have been stealing software from yourselves with the rise of mmo's and steam, there's ZERO reason for any piece of software to require an internet connection. Intel, MS, Sony and AMD are not going to give up on trusted computing. They want to remove control of our PC's to jack up software prices and force the public to pay for software and games. https://www.cl.cam.ac.uk/~rja14/tcpa-faq.html https://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
Syonyk 5y ago
Yup. SGX, TSX, all the interesting and complicated stuff seems to be getting deprecated after half a decade or more of "We got it! No, wait, we didn't... uh, this time we got it! Wait, crap, no... uh... but this time! Oh carp. Yeah, you know, screw it." After several of those "Release, revert" cycles, it ends up as a self fulfilling prophecy anyway - it's like the sentiment towards Google's new products you see often: "This, too, shall rapidly pass when they get bored." After you've seen TSX disabled on a few generation of chips, the motivation to put the work in to make something work with TSX just kind of evaporates, because you've no confidence that it'll actually work, or stay working, on hardware you want to run on. And because of the requirement to have a fallback path, TSX is a good bit more work, and, often, requires more complexity than a simple lock based approach that's good enough and simple to understand/validate. But my deeper concern is that it seems that nobody at Intel is capable of understanding all the interaction in the chip anymore - and SGX offers very strong evidence of this inability. SGX made the strong claim that, when deployed, a fully malicious ring 0 operating system could neither observe anything about the state of the compute happening in the enclave, nor modify the operation of that. They did various interesting things with how pages were swapped out to prevent replay attacks, and really did try to build it such that you couldn't mess with it. But they did these things at a high level, and didn't fully understand the nature of the chip. The L1TF (L1 Terminal Fault, also known as Foreshadow) attacks took advantage of the edge case L1 cache behavior to speculate out out anything that was in L1 cache, which included SGX enclave data. If I remember properly, because you could read out the stored register state as well as memory pages you faulted in, they demonstrated you could essentially single step a production SGX enclave with full register state and full memory state at every single instruction. Whoops. It's not hard to mitigate once you know the problem - just flush L1 entirely on exit. But Intel didn't know it was a problem, so they didn't do that. On the flip side, "influencing operation," there was Plundervolt. This involved the OS using an undocumented (grumble growl) MSR to reduce the voltage of the chip for improving efficiency of operation. However, the OS (that untrusted ring 0 thing...) has control over this register. And there aren't sane limits on it, such that the OS can drop the voltage enough that things like "multiply" and "AES operations" start faulting and glitching (silently), without being low enough that the chip stops functioning. Enter an enclave in this state, wait for multiply or AES to fault in the useful ways they will, and you've just influenced operation such that you can pull keys out. Whoops. Again, it's not hard to mitigate. Refuse to enter if the voltage isn't at stock settings (you can't just reset it on entry because it takes time for the VRMs to bring the voltage back up). But Intel didn't do this. The people who added this neat little efficiency hack and then kept it secret never rubbed the right way with the people in charge of the new flagship security features around the sort of adversarial thinkers who can ask "Now, wait a minute, what if I push this beyond sane bounds?" You can point at the other speculative stuff and claim it's not really a problem because architectural behavior is correct (I think that sort of reasoning is rubbish, when you can speculate your way past all security boundaries on the chip), but the SGX case, specifically, demonstrates that Intel didn't know about the problems or they would have taken the very simple mitigation steps. And that tells me that they can't reason about their chips as a whole. ... and that - hardware companies of the most critical components of the system not having a full understanding of how they operate - is scary. The foundation of everything is in an unknown state, and nobody knows how broken it is until some researchers go in and figure it out. More than once, after fixing the exact thing the researchers found, Intel has also had egg on their face of the "... so we found this very, very closely related, conceptually identical bug that they didn't fix with the last patches..." variety. It seems safe to say that there are university students and faculty who understand the security implications of Intel's design decision better than the people at Intel in charge of such things. We're running, very rapidly, out of "complexity runway." Everything, from the very chips on up, is so complex that nobody can reason about it, and the only solution to the very problems caused by complexity is, "Well, let's add more complexity to fix those problems." It's not the sort of thing that can go on forever. Anyway. </rant about the state of Intel>
Uptrenda 5y ago
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 computations, and so on. Looking a bit deeper though there were signs that placing all your trust in this technology was still a gamble. For example, the 'attestations' I spoke of earlier... were reports that had been signed by Intel's public key. You lose or hack that key and suddenly you can spoof reports. Then there were the hardware exploits which was the nail in the coffin. It's sad really because Intel SGX was some innovative shit. It would have enabled applications that just aren't possible with a conventional computing model. But it was too good to be true, unfortunately.
- eightysixfour 5y ago
  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.
  - melchebo 5y ago
    https://techcommunity.microsoft.com/t5/it-transformation/microsoft-s-blockchain-proposition/m-p/193682 https://techcommunity.microsoft.com/t5/it-transformation/mic...
  - tome 5y ago
    Are you thinking of https://en.m.wikipedia.org/wiki/Confidential_Consortium_Framework https://en.m.wikipedia.org/wiki/Confidential_Consortium_Fram...? It is alive and the source code is shared.
    - eightysixfour 5y ago
      I am! The “Coco” github from back in the day was killed so I thought it was gone.
muznar 5y ago
I wrote my graduate school thesis on Intel SGX. I was not a good student in grad school, my thesis was not some innovative thing but now it is completely useless. Edit: There is another comment linking an article from Intel saying SGX is full steam ahead in Xeon. Yay my thesis is not useless!
femto 5y ago
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.)
- NavinF 5y ago
  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 https://news.ycombinator.com/item?id=23809335
  - janwas 5y ago
    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.
    - ivegotnoaccount 5y ago
      Also, moving things to the GPU may be good for throughput but bad for latency depending on the workload, since offloading to GPU has a cost and data exchanges too.
      - femto 5y ago
        Agree. Real-time signal processing with feedback loops is a case in point.
      - rbanffy 5y ago
        > offloading to GPU has a cost and data exchanges too. This is bad with dGPUs over the PCIe bus, but not so much with GPUs that share a very fast memory bus with the CPU. In this case, the layout of the data may prove challenging to keep the same for when you use a CPU and a GPU.
    - 5y ago
onedognight 5y ago
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/ https://signal.org/blog/private-contact-discovery/
- inter_netuser 5y ago
  AKA: "share your contacts with the NSA only"
  - bawolff 5y ago
    Even if you dont believe in sgx, the nsa would still have to be in signal's servers somehow, in which case you are probably screwed anyways
    - ohthehugemanate 5y ago
      Edward Snowden is a public supporter and user of Signal. He's my canary in the coal mine. The moment the US three letter agencies get access to the data on Signal's servers, Snowden's dead. I feel comfortable in the resilience of their architecture as long as he's alive.
      - mhoad 5y ago
        This is an entire movie script you’ve made up in your mind. That isn’t how any of it works .
      - yosefk 5y ago
        Isn't Snowden alive because the US decided not to kill him? Doesn't sound like killing him is that hard
        mhoad 5y ago
        Nobody is coming to kill him. The scenario as a whole makes no sense when you think about it with even the most gentle level of scrutiny. His only danger at this point is jail.
snvzz 5y ago
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 https://en.wikipedia.org/wiki/RISC-V#Design
- mrweasel 5y ago
  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?
- IshKebab 5y ago
  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.
londons_explore 5y ago
I'm more sad about the deprecation if Hardware Lock Elision on that page... What was wrong with it? It seemed to offer such massive performance benefits for complex multithreaded code.
doppioandante 5y ago
What is the significance of this when looking at the fact that SGX support has been recently merged into linux main tree? I was waiting till next Ubuntu LTS to have qemu packaged with SGX support in order to reverse engineer my fingerprint sensor (which is match-on-host, and uses SGX under Windows).

130 points by thinkmassive 5y ago

josephcsible 5y ago

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

stefan_ 5y ago
The second use-case was MobileCoin, that cryptocoin scam Signal signed up for. Reflects well on their other crypto.
teeray 5y ago
I thought you could use it for HSM-type workloads too
- thinkmassive 5y ago
  Like a third party’s HSM running locally on your computer, heh
  - teeray 5y ago
    No, like, you could use something like https://www.ego.dev/ https://www.ego.dev/ and have Vault or something that worked more like an HSM
  - lxgr 5y ago
    In other words, a smartcard :)
kibwen 5y ago
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 that makes this possible, and all our code is open-source and housed under the Linux Foundation's Confidental Computing Consortium: https://enarx.dev/ https://enarx.dev/ .
- bpye 5y ago
  I'm sure you're already familiar, but for others, there is also AMD's SEV-SNP [0] and Intel's TDX [1] that solve similar problems. Azure has SEV-SNP VMs in preview [2] - full disclosure, I work at Microsoft and was involved in this :) [0] - https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthen... [1] - https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trust-domain-extensions.html https://www.intel.com/content/www/us/en/developer/articles/t... [2] - https://azure.microsoft.com/en-us/blog/azure-and-amd-enable-lift-and-shift-confidential-computing/ https://azure.microsoft.com/en-us/blog/azure-and-amd-enable-...
  - exfalso 5y ago
    In terms of security these technologies are (mostly) strictly worse than SGX, and there hasn't been nearly enough security research done on them. Also, the physical attack vectors remain (e.g. https://arxiv.org/abs/2108.04575 https://arxiv.org/abs/2108.04575). A small but interesting counterexample is x86 TSC: with SGX the MSR is modifiable by ring 0, with AMD SEV-SNP it is protected from the hypervisor. The real value of these newer technologies is not increased security, but rather increased usability. (Also, small sidenote: TDX relies on SGX.) I think the biggest contribution that cloud providers can bring to the table in the mid-term is mitigation of the physical attack vector. This would involve inserting themselves as a second root of trust in attestations (SEV has explicit support for this), which would mean that a real world attack would require collusion of multiple parties (pick 2 of Hardware vendor, Cloud provider, Software vendor).
- marcan_42 5y ago
  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. They've demonstrated they don't have the culture nor security chops to actually engineer a system that could be trusted, IMO. Plus then there's all the microarchitectural leak vectors with a shared-CPU approach like that, and we know Intel have utterly failed there (not just Spectre; there was absolutely no excuse for L1TF and some of the others, and those really showed us just how security-oblivious Intel's design teams are). Right now, the x86 world would probably do well to listen to Microsoft, since their Xbox division managed to coax AMD into actually putting out secure silicon (they're one of the two big companies doing proper silicon security at the consumer level, the other being Apple and Google trying to catch up as a distant third). But given the muted response to Pluton from the industry, and the poor way in which this is all being marketed and explained, I'm not sure I have much hope right now...
Jweb_Guru 5y ago
Hardware-enforced anticheat (for certain kinds of games) is a pretty cool potential usecase.
nullc 5y ago
The usecase could have included all manner of useful pro-privacy and security usage-- but intel was extremely restrictive with access to the ability to use it in part because they expected to monetize the DRM usage.
codethief 5y ago
It's also used extensively by Signal (not just for MobileCoin, as a sibling comment suggests).
Sesse__ 5y ago
Interestingly enough, I believe there's now no official way of playing UHD-BR on modern Intel systems (ie. you'd have to use an AACS/BD+ crack), since all certified players needed SGX. I don't know what this means for 4K Netflix, if anything.

thinkmassive 5y ago

Looks like they deprecated the link since I first loaded the page. New link, same content: https://edc.intel.com/content/www/us/en/design/ipla/software-development-platforms/client/platforms/alder-lake-desktop/12th-generation-intel-core-processors-datasheet-volume-1-of-2/006/deprecated-technologies/ https://edc.intel.com/content/www/us/en/design/ipla/software...

thinkmassive 5y ago

They claim SGX support on Xeon is still “full steam ahead” https://community.intel.com/t5/Blogs/Products-and-Solutions/Security/Rising-to-the-Challenge-Data-Security-with-Intel-Confidential/post/1353141 https://community.intel.com/t5/Blogs/Products-and-Solutions/...

kibwen 5y ago
Specifically the next generation of SGX is pushing ahead, since a number of flaws were identified in the original design.
- betterunix2 5y ago
  I'm taking bets on how long before the next generation is completely broken as well. It is only a matter of time, and the timeline is likely short.
  - ZiiS 5y ago
    Only having it on expensive chips will probably help as much as anything.
  - kibwen 5y ago
    The onus is on Intel to provide a solution that is sound. That said, there's no reason to assume that what they're doing is impossible, any more so than assuming that cryptography in general is impossible.
no_time 5y ago
Curious how there is no CSAM scare mongering when it's companies that need private storage of information.
- judge2020 5y ago
  Societally, when some person or org uses a Xeon processor for CSAM distribution, nobody things "man I wish Intel stopped this". However, when it's Apple considering end-to-end encrypted iCloud Photos or iCloud backups, people (read: federal law enforcement) will blame Apple for allowing CSAM to proliferate locked away from law enforcement. edit: as for why this is bad, federal law enforcement have a lot more pull when seeking change in laws in congress. Maybe Apple would've had to implement a government backdoor into iPhone itself if they didn't pull the CSAM scanning stunt (and I imagine they knew the backlash was inevitable, which allowed them to use that backlash as reason to push back on either scanning or a backdoor).

dataflow 5y ago

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?

nickelpro 5y ago
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 https://cdrdv2.intel.com/v1/dl/getContent/604224
- dataflow 5y ago
  Wow, I see, thanks. Makes you wonder why they couldn't fix it instead—sounds like it was a fundamentally difficult problem to solve?
  - DSingularity 5y ago
    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.
    - nyanpasu64 5y ago
      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)?

pjmlp 5y ago

I pity that MPX is gone as well, this makes x86/x64 lose to ARM in hardware memory tagging. While it was buggy, Intel doesn't seem keen in bringing in a replacement.

DSingularity 5y ago
The approach is fundamentally flawed.
- pjmlp 5y ago
  MPX sure, that doesn't prevent bringing a new one, otherwise in a couple of years Intel/AMD will be the only ones left standing without hardware memory tagging support.
  - monocasa 5y ago
    I mean, having played with MPX for use in a JIT, it was slower than just manually bounds checking.
    - DSingularity 5y ago
      With less security guarantees too.

pvg 5y ago

related 400 comment thread from 3 months ago: https://news.ycombinator.com/item?id=29932630 https://news.ycombinator.com/item?id=29932630

userbinator 5y ago

Is the ME next? One can dream... that Intel will stop playing with all of this user-hostile "security" nonsense and focus on performance and power efficiency while also releasing all the detailed programming/design information publicly.

stuu99 5y ago
They aren't going to. The industry has been pushing for copyright enforcement built into the hardware and OS. Windows 10/11 is the first client-server OS, aka the ultimate security risk since you all have been stealing software from yourselves with the rise of mmo's and steam, there's ZERO reason for any piece of software to require an internet connection. Intel, MS, Sony and AMD are not going to give up on trusted computing. They want to remove control of our PC's to jack up software prices and force the public to pay for software and games. https://www.cl.cam.ac.uk/~rja14/tcpa-faq.html https://www.cl.cam.ac.uk/~rja14/tcpa-faq.html

Syonyk 5y ago

Yup. SGX, TSX, all the interesting and complicated stuff seems to be getting deprecated after half a decade or more of "We got it! No, wait, we didn't... uh, this time we got it! Wait, crap, no... uh... but this time! Oh carp. Yeah, you know, screw it." After several of those "Release, revert" cycles, it ends up as a self fulfilling prophecy anyway - it's like the sentiment towards Google's new products you see often: "This, too, shall rapidly pass when they get bored." After you've seen TSX disabled on a few generation of chips, the motivation to put the work in to make something work with TSX just kind of evaporates, because you've no confidence that it'll actually work, or stay working, on hardware you want to run on. And because of the requirement to have a fallback path, TSX is a good bit more work, and, often, requires more complexity than a simple lock based approach that's good enough and simple to understand/validate. But my deeper concern is that it seems that nobody at Intel is capable of understanding all the interaction in the chip anymore - and SGX offers very strong evidence of this inability. SGX made the strong claim that, when deployed, a fully malicious ring 0 operating system could neither observe anything about the state of the compute happening in the enclave, nor modify the operation of that. They did various interesting things with how pages were swapped out to prevent replay attacks, and really did try to build it such that you couldn't mess with it. But they did these things at a high level, and didn't fully understand the nature of the chip. The L1TF (L1 Terminal Fault, also known as Foreshadow) attacks took advantage of the edge case L1 cache behavior to speculate out out anything that was in L1 cache, which included SGX enclave data. If I remember properly, because you could read out the stored register state as well as memory pages you faulted in, they demonstrated you could essentially single step a production SGX enclave with full register state and full memory state at every single instruction. Whoops. It's not hard to mitigate once you know the problem - just flush L1 entirely on exit. But Intel didn't know it was a problem, so they didn't do that. On the flip side, "influencing operation," there was Plundervolt. This involved the OS using an undocumented (grumble growl) MSR to reduce the voltage of the chip for improving efficiency of operation. However, the OS (that untrusted ring 0 thing...) has control over this register. And there aren't sane limits on it, such that the OS can drop the voltage enough that things like "multiply" and "AES operations" start faulting and glitching (silently), without being low enough that the chip stops functioning. Enter an enclave in this state, wait for multiply or AES to fault in the useful ways they will, and you've just influenced operation such that you can pull keys out. Whoops. Again, it's not hard to mitigate. Refuse to enter if the voltage isn't at stock settings (you can't just reset it on entry because it takes time for the VRMs to bring the voltage back up). But Intel didn't do this. The people who added this neat little efficiency hack and then kept it secret never rubbed the right way with the people in charge of the new flagship security features around the sort of adversarial thinkers who can ask "Now, wait a minute, what if I push this beyond sane bounds?" You can point at the other speculative stuff and claim it's not really a problem because architectural behavior is correct (I think that sort of reasoning is rubbish, when you can speculate your way past all security boundaries on the chip), but the SGX case, specifically, demonstrates that Intel didn't know about the problems or they would have taken the very simple mitigation steps. And that tells me that they can't reason about their chips as a whole. ... and that - hardware companies of the most critical components of the system not having a full understanding of how they operate - is scary. The foundation of everything is in an unknown state, and nobody knows how broken it is until some researchers go in and figure it out. More than once, after fixing the exact thing the researchers found, Intel has also had egg on their face of the "... so we found this very, very closely related, conceptually identical bug that they didn't fix with the last patches..." variety. It seems safe to say that there are university students and faculty who understand the security implications of Intel's design decision better than the people at Intel in charge of such things. We're running, very rapidly, out of "complexity runway." Everything, from the very chips on up, is so complex that nobody can reason about it, and the only solution to the very problems caused by complexity is, "Well, let's add more complexity to fix those problems." It's not the sort of thing that can go on forever. Anyway. </rant about the state of Intel>

Uptrenda 5y ago

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 computations, and so on. Looking a bit deeper though there were signs that placing all your trust in this technology was still a gamble. For example, the 'attestations' I spoke of earlier... were reports that had been signed by Intel's public key. You lose or hack that key and suddenly you can spoof reports. Then there were the hardware exploits which was the nail in the coffin. It's sad really because Intel SGX was some innovative shit. It would have enabled applications that just aren't possible with a conventional computing model. But it was too good to be true, unfortunately.

eightysixfour 5y ago
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.
- melchebo 5y ago
  https://techcommunity.microsoft.com/t5/it-transformation/microsoft-s-blockchain-proposition/m-p/193682 https://techcommunity.microsoft.com/t5/it-transformation/mic...
- tome 5y ago
  Are you thinking of https://en.m.wikipedia.org/wiki/Confidential_Consortium_Framework https://en.m.wikipedia.org/wiki/Confidential_Consortium_Fram...? It is alive and the source code is shared.
  - eightysixfour 5y ago
    I am! The “Coco” github from back in the day was killed so I thought it was gone.

muznar 5y ago

I wrote my graduate school thesis on Intel SGX. I was not a good student in grad school, my thesis was not some innovative thing but now it is completely useless. Edit: There is another comment linking an article from Intel saying SGX is full steam ahead in Xeon. Yay my thesis is not useless!

femto 5y ago

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

NavinF 5y ago
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 https://news.ycombinator.com/item?id=23809335
- janwas 5y ago
  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.
  - ivegotnoaccount 5y ago
    Also, moving things to the GPU may be good for throughput but bad for latency depending on the workload, since offloading to GPU has a cost and data exchanges too.
    - femto 5y ago
      Agree. Real-time signal processing with feedback loops is a case in point.
    - rbanffy 5y ago
      > offloading to GPU has a cost and data exchanges too. This is bad with dGPUs over the PCIe bus, but not so much with GPUs that share a very fast memory bus with the CPU. In this case, the layout of the data may prove challenging to keep the same for when you use a CPU and a GPU.
  - 5y ago

onedognight 5y ago

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/ https://signal.org/blog/private-contact-discovery/

inter_netuser 5y ago
AKA: "share your contacts with the NSA only"
- bawolff 5y ago
  Even if you dont believe in sgx, the nsa would still have to be in signal's servers somehow, in which case you are probably screwed anyways
  - ohthehugemanate 5y ago
    Edward Snowden is a public supporter and user of Signal. He's my canary in the coal mine. The moment the US three letter agencies get access to the data on Signal's servers, Snowden's dead. I feel comfortable in the resilience of their architecture as long as he's alive.
    - mhoad 5y ago
      This is an entire movie script you’ve made up in your mind. That isn’t how any of it works .
    - yosefk 5y ago
      Isn't Snowden alive because the US decided not to kill him? Doesn't sound like killing him is that hard
      - mhoad 5y ago
        Nobody is coming to kill him. The scenario as a whole makes no sense when you think about it with even the most gentle level of scrutiny. His only danger at this point is jail.

snvzz 5y ago

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 https://en.wikipedia.org/wiki/RISC-V#Design

mrweasel 5y ago
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?
IshKebab 5y ago
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.

londons_explore 5y ago

I'm more sad about the deprecation if Hardware Lock Elision on that page... What was wrong with it? It seemed to offer such massive performance benefits for complex multithreaded code.

doppioandante 5y ago

What is the significance of this when looking at the fact that SGX support has been recently merged into linux main tree? I was waiting till next Ubuntu LTS to have qemu packaged with SGX support in order to reverse engineer my fingerprint sensor (which is match-on-host, and uses SGX under Windows).