It's time to talk about TEEs
joshcsimmons
19 points
6 comments
October 18, 2026
Related Discussions
Found 5 related stories in 104.8ms across 9,867 title embeddings via pgvector HNSW
- Show HN: K10s – A Clickable Kubernetes TUI (Go, Bubble Tea) pierreneter · 63 pts · October 08, 2026 · 47% similar
- Show HN: Texttile, a multiplayer blog engine for people who write together klausbreyer · 13 pts · August 28, 2026 · 46% similar
- Show HN: Hntui – A TUI for Hacker News ahmd-sh · 107 pts · September 28, 2026 · 46% similar
- The Test latexr · 161 pts · September 25, 2026 · 43% similar
- Show HN: OTP Inspired actor supervisor based full stack templates annrap1d · 11 pts · July 20, 2026 · 43% similar
Discussion Highlights (2 comments)
mike_hearn
It's just another spin on a very old debate in computer security: nothing is perfect, so where do you draw the line? SGX was designed from the start on the assumption that there would be bugs or people would find clever unanticipated attacks, so it has a games console-like resealing procedure that lets the platform be fixed in place via firmware and microcode updates. SGX pre-dated Spectre, so those assumption were proven true, and the platform was resealed a bunch of times. Is this a success or failure? The article takes it as obvious that it's a failure. But if you judge a general purpose computing system by the standard of "did it ever need to be patched" then there has never been a success. Clearly that can't be where the line is drawn. An alternative place to draw the line might be whether the system provides the needed guarantees when fully patched and there are no known bugs. According to this standard, SGX is a mixed bag. The original SGX implementation fully took hardware attacks into account including on DRAM chips. Later versions were deliberately weakened to try and find product-market fit, as developers were unable to handle a programming model more complex than "boot an entire VM with our app inside it" (and frankly even then weren't able to get it right, I've seen so many botched RA implementations). But you hit hard physical limits: making untrusted DRAM secure trades off against making it large. Developers reject anything that requires them to conserve RAM, and so the original SGX design died there. This was arguably not Intel's fault. A few hundred megabytes of RAM was sufficient to achieve many important security goals with the original SGX model, but developers just don't care enough to do learn a new programming model or paradigm. It's easier to just trust the cloud providers to not peek, like everyone else does. AMD SEV ended up getting more support from the cloud vendors because it required less work from developers, but AMD's implementation was much worse than Intel's was and spent much of the time I worked on this stuff in an entirely broken and un-resealable state. SGX is one of those technologies that was maybe ahead of its time. Privacy tech in general is a hard sell because there are very few scandals where tech firms leak data, so blocking that possibility via more programmer effort was a hard sell in a world where skilled programming time was scarce. Maybe AI changes the game here, hard to say.
azalemeth
SGX is one of those things where 95% of the time the actual motivating use case is evil DRM and frankly you have a very well motivated world of hackers desiring to break it for all sorts of different reasons. My gut feeling is that it fulfills a purpose of making a mid level manager somewhere get a bonus, potentially marginally increase the efficacy of a DRM scheme (e.g. blue ray video -- all official players require windows and run on the TEE) and any actual "good" use cases are somewhere along the lines of good incidental marketing, including the cloud computing ones...