Hacker News Reader

Comment by bibabaloo | Hacker News Reader

Am I wrong to assume that cloud vendors are the most worried about these sort of exploits? Having exploits that would allow customers running on the same hardware to access each others' data seems like it would be disastrous for them. So much so that they're probably OK with paying the performance penalty (or, more accurately, passing the extra costs onto their customers!).

View on HN

If cloud vendors are working on this, they must see it as a real threat, I don't think they would put this much work into reducing their cpu resources willingly?

Why not, it's the customer that ends up paying because there's less performance per machine, and so they may need more of them. If all cloud providers use this fix then there's really nothing you can do. Some may provide true 'bare-metal' machines but I'd imagine they're pricey and a pain to maintain / monitor.

In that scenario, competition would come from different architectures. If you have one that can partition caches according to security contexts or encrypt memory at the CPU/L1 boundary at a lower cost, then you have a competitive advantage.

Graviton 2, by ditching SMT, has one such mitigation.

To me, it sounds like it should help ARM64 gain some ground (efficient physically separate machines instead of VMs); not for HPC, but for more traditional workloads.

Do you care to elaborate? You can already do this on Linux with any architecture (x86 or anything else) using cpusets.

I imagine that it is likely that sharing most hardware will lead to side channel vulnerabilities, and the per-core cache is not special. Smaller, cheaper SoCs could allow for sharing less of that hardware.

The problem of course being that CPUs that rival performance of a decently-specced x86 VM are going to be pricy, mooting the point.

For high core count (server) CPUs all levels of cache are local to core(s). For example, in Intel's current plattform each core has a 1.x MB L3 slice attached to it. In AMD's Zen 2 design, each CCX (group of four cores) has 16 MiB of L3 attached to it.

Based on these architectural features Intel has had CAT, which essentially turns LLC slices into private caches for certain cores. That's intended for performance, but is now also relevant for security.

Reply on news.ycombinator.com