May 27, 2019

AMD's chips apparently don't have the security vulnerabilities that make SMT unsafe to enable on Intel chips - they released a white paper explaining why MDS etc aren't possible and what exactly the boundaries are on their chips: https://www.amd.com/system/files/documents/security-whitepap... It just didn't get a huge amount of press coverage.

May 26, 2019

While it's true that speculation as a whole needs to be revisited, Intel is impacted to a much greater extent because they designed their hardware to speculate beyond permission barriers as a matter of routine. AMD did not [0] and consequently is affected only by the most general attacks on speculation, e.g., Spectre. As far as I understand, AMD chips are not impacted by Meltdown or any of the MDS attacks.

It'd be great to see Michael run the same benchmarks against an AMD chip that has all relevant mitigations enabled and compare the performance loss. I'd ballpark that AMD chips may have lost ~10% overall, whereas we see here that Intel chips have lost ~25%.

[0] https://www.amd.com/system/files/documents/security-whitepap...

May 19, 2019

Yeah, it really does seem like a fundamental difference in how AMD and Intel designed their processors. Researchers have found Intel processors allowing speculation to bypass hardware protection all over the place, and they just haven't found an AMD equivalent. Not only that, AMD have looked into this themselves and released an entire whitepaper explaining why this isn't possible: https://www.amd.com/system/files/documents/security-whitepap... (With, interestingly, one exception. Apparently AMD CPUs allow speculative execution to ignore x86 segmentation. It's just that no-one cares because that's not used anymore. I'm not sure there have even been any mainstream OSes that used that for process isolation.)

This is particularly bad for Intel because most of the SMT-based exploits can pretty much only be mitigated by disabling SMT entirely and taking such a substantial performance hit that they've been trying desperately to convince people not to.

May 15, 2019

As you say, only the first Foreshadow attack went after SGX - it turned out to be a broader flaw that also affected OS page table protections more generally and could be used to attack process-OS and VM-hypervisor isolation. Those variants relied only on Intel's implementation of standard x86 paging, and they don't exist on AMD because they didn't implement it in the flawed way Intel did. That is, Foreshadow/L1TF is Intel-only not because it relies on an Intel-only feature, but because it's an Intel-specific implementation flaw. (Linux had to substantially rework its paging code to work around this.)

AMD don't seem to have commented on ZombieLoad yet, presumably because it's much newer and they didn't have pre-announcement info about it, but they've commented on the other two vulnerabilities announced today and explained that the reason they're not vulnerable is because the corresponding units in their CPUs don't allow speculative data access unless the access checks pass and their whitepaper seems to suggest the same is true of ZombieLoad: https://www.amd.com/system/files/documents/security-whitepap...

SGX does make for an easier and flashier demo for Foreshadow, though, so it makes sense that the researchers went after that target. They managed to recover the top-level SGX keys that all SGX security and encryption on the system relies on, something that I don't think anyone had ever managed before.

Also, as I've said elsewhere, Intel seems to speculatively leak data that shouldn't be accessible pretty much everywhere in their designs where memory is accessed.