I'm pretty sure AWS/Azure/GCP don’t assign separate boxes to every customer, and somehow they’re fine.

You can pay AWS a premium to make sure you're the only tenant on the physical machine. You can also split your own stuff into multiple tenants, and keep those separate too.

At which point you don't really need the flexibility of AWS and you might as well get a Dedicated Server elsewhere?

It'll still let you do the elastic scaling stuff, billing for actual usage instead of racked hardware.

Eric Brandwine (VP/DE @ AWS) said publicly in 2019 that EC2 had never scheduled different tenants on the same physical core at the same time, even before we learned about these kinds of side-channel attacks.

https://www.youtube.com/watch?v=kQ4H6XO-iao&t=2485s

Yes (lowest vCPU seems to be 2 everywhere), and that protects against this attack. However, this thread was talking about airgapping hosts, which is needed for the general threat of VM escapes.

At least Fargate and Lightsail can select < 2 vCPU. (and maybe micro EC2 instance types?)

Well, that does sound like those were vulnerable then, if they happened to run on Zen 2. (Obviously microcode patched by now.)

As usual, cost is the biggest hindrance to security.

Even before then, the sufficiently paranoid (but still bound to AWS for whatever reason) would track usage/steal/IO reporting along with best guesses for Amazon hardware expidenture and use that information to size instances to attempt to coincide with 1:1 node membership.

Good point, I should have clarified that I was talking about on-prem VMs e.g. VMWare.

Not sure if they're actually fine, some researchers have exploited this vulnerability on AWS instances that use affected EPYC CPUs: https://twitter.com/0xdabbad00/status/1683581484337348608

That sounds like it's leaking across user/process boundaries on a single EC2 instance, which presumably also requires the processes to be running on the same core.

Leaks between different EC2 instances would be far more serious, but I suppose that wouldn't happen unless two tenants / EC2 instances shared SMT cores, or the contents of the microarchitectural register file was persisted across VM context switches in an exploitable manner.

Just running on a separate core would avoid this bug.

Yes but the Firecracker VMs are pinned to specific cores. So no two tenants never share a CPU core. Other than Rowhammer, has there been a hardware vulnerability of this nature that has worked x-core? I don't recall.

Still, I think that if your company is handling user data it's worth seriously considering dedicated instances for any service that encounters plaintext user information.

Interesting. Physical cores or SMT virtual cores? Is there a link to their docs about this?

I honestly think I only ever saw an AWS Security Eng tweet about it lol sorry

https://docs.aws.amazon.com/whitepapers/latest/security-desi... seems like the relevant docs?

They keep breaches quiet so we don't know how porous their security is in practice.