Live data from Hacker News

Downfall Attacks

downfall.page

41–50 of 349 posts

Re: Downfall Attacks

#41

The Intel paper link is dead, this seems to be the right one: https://www.intel.com/content/www/us/en/developer/articles/t... General caveats: are there many clouds that still run workloads from different users on the same physical core? I thought most had changed their schedulers years ago so you can't get cross-domain leaks between hyperthreads anymore. Claiming that it affects all users on the internet seems like…

The Spectre attack had to be patched in the kernel in a way that significantly slowed down execution on Intel CPU:s: https://www.notebookcheck.net/Spectre-v2-mitigation-wreaks-h...

Re: Downfall Attacks

#42
post #36

Once again it seems clear that running code from two security domains on the same physical processor cores is just not possible to get right, and we should probably just stop doing it. There are really only two common cases for this anyway. VMs and JavaScript. For VMs we just need to give up on it. Dedicate specific cores to specific VMs or at least customers. For JavaScript it’s a bit harder. Either way, we need to…

This is an unreasonable position. Vulnerabilities can be fixed

The mitigation here can incur a whopping 50% performance penalty. At what point can customers return these CPUs for either being defective or sue for false advertising? If they can't safely meet the target performance they shouldn't be doing these tricks at all.

Re: Downfall Attacks

#43
post #2

This is a huge performance hit - up to 50% it is claimed! 70% of modern intel processors are affected apparently as well.

Is that 50% overhead for "Gather" instructions? If that is the case, then if 10% of instructions are "gathers" in your workload then that would be 5% overall.

Re: Downfall Attacks

#44
post #2

This is a huge performance hit - up to 50% it is claimed! 70% of modern intel processors are affected apparently as well.

Is that 50% overhead for "Gather" instructions? If that is the case, then if 10% of instructions are "gathers" in your workload then that would be 5% overall.

Something like that, yeah.

Re: Downfall Attacks

#45

Earlier quoted context omitted.

I'm not sure what evidence there is to think that Apple's chips are any better. And that's not really a dig at Apple; these are just very complicated devices and especially with the optimizations that CPUs need to make to run today's software with acceptable performance, it can become very hard to foresee all possible attacks and vulnerabilities.

I'm not trying to suggest that Apple's ARM chips are magically better because they're designed by Apple. Rather that the x86 architecture is obviously very long in the tooth and now would be a great time to switch to a far more modern architecture especially in light of this steady stream of vulnerabilities and defects that keep being found in x86. I'm sure ARM64 isn't perfect but I've yet to learn of something as se…

Almost all of these exploits are due to the out-of-order/speculative execution.. which is incredibly complicated. There is no reason to believe that an out of order architecture that has not been hardened is any better at defense here than x86 - Just that as a minority architecture, it's still less profitable to target for exploitation. I have very little faith that the Apple ARM chips do better here without extensive exploit attempts made...

Re: Downfall Attacks

#46

Once again it seems clear that running code from two security domains on the same physical processor cores is just not possible to get right, and we should probably just stop doing it. There are really only two common cases for this anyway. VMs and JavaScript. For VMs we just need to give up on it. Dedicate specific cores to specific VMs or at least customers. For JavaScript it’s a bit harder. Either way, we need to…

I've wondered if we can't give a dedicated core to the browser. Of course, then web pages can steal from other web pages. Maybe task switching needs to erect much higher barriers between security contexts, a complete flush or so?

Re: Downfall Attacks

#47

Earlier quoted context omitted.

I'm not sure what evidence there is to think that Apple's chips are any better. And that's not really a dig at Apple; these are just very complicated devices and especially with the optimizations that CPUs need to make to run today's software with acceptable performance, it can become very hard to foresee all possible attacks and vulnerabilities.

I'm not trying to suggest that Apple's ARM chips are magically better because they're designed by Apple. Rather that the x86 architecture is obviously very long in the tooth and now would be a great time to switch to a far more modern architecture especially in light of this steady stream of vulnerabilities and defects that keep being found in x86. I'm sure ARM64 isn't perfect but I've yet to learn of something as se…

Just as a couple of examples…

ARM has suffered from Spectre too: https://developer.arm.com/Arm%20Security%20Center/Spectre-BH...

There was also PACMAN: https://appleinsider.com/articles/22/06/10/new-pacman-flaw-i...

Speculative vulnerabilities have virtually nothing to do with the instruction set. Changing the language of the processor has little to do with how the processor works under the hood, especially for fundamental technologies like speculative execution.

Also, as a corollary, speaking the same language doesn’t mean every vulnerability is shared. AMD does not seem affected by Downfall, for instance.

Re: Downfall Attacks

#48

I'm getting annoyed with all of these yawning security holes in Intel's CPUs. I'm tempted to replace my Intel MacBook Pro with an Apple Silicon model sooner than I normally would.

Yes, it's definitely only Intel who has these problems. [1] [2]

[1] - https://lock.cmpxchg8b.com/zenbleed.html

[2] - https://comsec.ethz.ch/research/microarch/inception/

Re: Downfall Attacks

#49
This is one of many similar previous attacks, and more of these attacks will continue to come out and be increasingly weaponized. From now on the assumption must be that same-core computing is not secure.
Post reply on HN