3 ms·
> But that doesn't prevent issues due to switching between customers on the same physical core, no? Yes they are explicit that customers may be time-shared on
by BeeOnRope 3y ago
> But that doesn't prevent issues due to switching between customers on the same physical core, no?
Yes they are explicit that customers may be time-shared on a physical core ("burstable" instances don't really make sense without that). Most of these attacks aren't known to be possible in that scenario and in any case the mitigations are much easier since flushing sensitive state at group scheduling boundaries is much less costly than permanent dynamic changes to how concurrent SMT threads interact.
- anarazel 3y agoYes, it's certainly easier to mitigate at a boundary that's already as costly as switching between VMs. The paper documents that disabling SMT does not entirely mitigate the problem (In 9.1). They briefly mention trying instructions to avoid the microarchitectural leaks, but don't go into more detail than mentioning verw isn't sufficient. They state that a switch to/from SGX, with SMT disabled, doesn't prevent the attacks. See 8.1. That's not the same as a cross-vm switch, but it's certainly interesting that the attempts at flushing microarchitectural state when exiting SGX don't provide protection.
- CanaryLayout 3y agoThink of all the cloud resellers that are out there who really aren't segregating their tenants out or it's just a web shop with proxmox who recombined their own customers onto a core even though the cloud provider specifically segregated it