Hacker News Reader

Comment by kurikuri | Hacker News Reader

>desktop executes untrusted and rather arbitrary code pretty often

Aren’t the most affected group of users cloud users (and providers), not desktop users? I thought the biggest risk of specter attacks is the ability to glean information on other server residents who should be segmented off. There are many more concerns in user space which make attacking a desktop with specter pretty cumbersome for low reward wrt opportunity cost.

The performance savings of speculative execution do seem to be worth the risk on a desktop IMO.

View on HN

I was under the impression that spectre is is much more limited in scope than Meltdown. I think you have to be in a position to influence the execution of the program you are trying to extract information from. Like JavaScript engines running in browsers. One example is your JS can be used to get the browser to speculatively execute something that leaks data. I think that it’d be pretty hard for one VM to set up a spectre attack on another arbitrary VM. Meltdown however does expose everything.

Yeah, this is mostly an issue in the cloud where you share SMT threads with other people.

To be more precise, running different cloud customers on different SMT threads of the same core allows them to attack each other.

This is also the case with Spectre-related vulnerabilities such as L1TF.

At least on AWS EC2, malicious neighbors won't be an issue. "This issue has been addressed for AWS hypervisors, and no instance can read the memory of another instance, nor can any instance read AWS hypervisor memory. We have not observed meaningful performance impact for the overwhelming majority of EC2 workloads."[1]

[1] https://aws.amazon.com/speculative-execution-os-updates/

> for the overwhelming majority of EC2 workloads.

I wonder if that’s weasel words for

“the majority of AWS workloads run single digit cpu utilisation, so a 50% performance hit is not a ‘meaningful performance impact’ for them”?

Reply on news.ycombinator.com