One Glitch to Rule Them All: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization · HackerPapers discussions

One Glitch to Rule Them All: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization — mentioned by dongcarl

Mon, 18 Aug 2025 15:54:22 GMT

I actually spent a few months prototyping SGX/SEV VPNs before settling on a Multi-Party Relay scheme for obscura.net Things may have changed since mid-2023 but here were my takeaways: ----- Re: Vendor lock-in Vendor lock-in is (was?) a huge problem (at least for process-based TEEs) Process-based TEEs (mainly SGX) operated by providing essentially a whole new system abstraction. At the base level, there was no `libc`-like or `POSIX`-like interfaces, only Intel specific ones. This is why there are projects like [Gramine](https://github.com/gramineproject/gramine) and…

Paper and discussion history. A mention is not an endorsement.

One Glitch to Rule Them All: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization — mentioned by natesales

Thu, 15 May 2025 22:43:47 GMT

An attacker would need to compromise our build pipeline to publish a backdoored VM image [1] and extract key material to forge an attestation from the hardware [2]. The build process publishes a hash of the code to Sigstore’s transparency log [3], which would make the attack auditable. That said, a sufficiently resourced attacker wouldn’t need to inject a backdoor at all. If the attacker already possesses the keys (e.g. the attacker IS the hardware manufacturer, or they’ve coerced the manufacturer to hand the keys over), then they would just need to gain access to the host server (which we…

Paper and discussion history. A mention is not an endorsement.

One Glitch to Rule Them All: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization — mentioned by magicalhippo

Fri, 01 Sep 2023 18:53:28 GMT

There's also voltage glitching which has been used with great success as well[1][2]. [1]: https://web.archive.org/web/20190801014726/https://www.cl.ca... [2]: https://arxiv.org/abs/2108.04575

Paper and discussion history. A mention is not an endorsement.

One Glitch to Rule Them All: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization — mentioned by nazgulsenpai

Thu, 17 Aug 2023 12:40:59 GMT

AMD was impacted by a Meltdown-style attack[0], and the AMD Secure Encrypted Virtualization voltage attack[1] that, recently, was used to jailbreak Teslas. This culture of corporate fandom "console wars" mentality that has permeated almost every facet of technical discussion makes me nauseated. (not directed at parent -- just ranting.) [0] https://www.amd.com/en/resources/product-security/bulletin/a... [1] https://arxiv.org/pdf/2108.04575.pdf

Paper and discussion history. A mention is not an endorsement.

One Glitch to Rule Them All: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization — mentioned by exfalso

Sat, 16 Apr 2022 08:09:28 GMT

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

Paper and discussion history. A mention is not an endorsement.

One Glitch to Rule Them All: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization — HN submission

Thu, 12 Aug 2021 08:15:46 GMT

Fault Injection Attacks Against AMD's Secure Encrypted Virtualization

167 points; 60 discussion replies on HN. Paper and source history. A submission is not an endorsement.