Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Downfall Attacks

downfall.page

Post reply on HN
Print view View original

91–100 of 349 posts

Re: Downfall Attacks

#91

Post by t0astbread »

sidewndr46 wrote: post #65
throwaway892238 wrote: post #58

Earlier quoted context omitted.

Agreed. Browsers are now nothing but an application platform of APIs ( https://developer.mozilla.org/en-US/docs/Web/API ). For some reason they still retain the vestigial HTML, CSS and JS, but really all you need is bytecode that calls an ABI, and a widget toolkit that talks to a rendering API. Then we can finally ship apps to users without the shackles of how a browser wants to interpret and render some markup. The…

If someone created a way for WASM to talk to an SDL equivalent, it'd probably end use of HTML & CSS

If tri-state logic becomes viable it's game over for binary!

Re: Downfall Attacks

#92

Post by Dylan16807 »

calibas wrote: post #74
mike_hearn wrote: post #32

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…

> Claiming that it affects all users on the internet seems like a massive over-exaggeration, as he hasn't demonstrated any kind of browser based exploit and even if such a thing did exist He's saying it likely affects "everyone on the Internet" because most servers are vulnerable.

Most servers being vulnerable to a local attack is generally pretty boring news.

Re: Downfall Attacks

#93

Post by mike_hearn »

rocqua wrote: post #88
mike_hearn wrote: post #60

Earlier quoted context omitted.

Yes, I think that's what I said? Every attack no matter how deep it seemed to be has been patchable in microcode, sometimes at a cost in performance. But so far nobody had to toss the physical silicon, at least not with Intel. The malleability of these chips is quite fascinating.

The meltdown and spectre mitigations weren't patched in microcode, they were patched by changing the internal calling methods of the kernel.

I think it was both. There were initial software only patches, but those were quickly superseded by microcode+kernel patches, where microcode added features the kernel enabled. IBRS or something like that.

Re: Downfall Attacks

#94

Post by kiririn »

mike_hearn wrote: post #32

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…

>are there many clouds that still run workloads from different users on the same physical core?

There are a vast number of VPS providers out there that aren’t AWS/GCP/Azure/etc where the answer is yes. Even the ones that sell ‘dedicated’ cores, which really just means unmetered cpu

Re: Downfall Attacks

#95

Post by cbsmith »

mike_hearn wrote: post #93
rocqua wrote: post #88

Earlier quoted context omitted.

The meltdown and spectre mitigations weren't patched in microcode, they were patched by changing the internal calling methods of the kernel.

I think it was both. There were initial software only patches, but those were quickly superseded by microcode+kernel patches, where microcode added features the kernel enabled. IBRS or something like that.

It was both, and none of them completely addressed the problem. They did need new hardware for that.

Re: Downfall Attacks

#96

Post by pseudalopex »

malfist wrote: post #36
Negitivefrags wrote: post #33

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

> Vulnerabilities can be fixed

Not always the damage.

Re: Downfall Attacks

#97

Post by jgtrosh »

samwillis wrote: post #6
buildbot wrote: post #2

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

> some workloads may experience up to 50% overhead They word there are "some workloads", I suspect that performance hit is rare.

My guess is that HPC systems which run applications whose performance strongly depends on efficient data scatter gather will immediately disable the mitigation.

Re: Downfall Attacks

#98

Post by H8crilA »

kiririn wrote: post #94
mike_hearn wrote: post #32

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…

>are there many clouds that still run workloads from different users on the same physical core? There are a vast number of VPS providers out there that aren’t AWS/GCP/Azure/etc where the answer is yes. Even the ones that sell ‘dedicated’ cores, which really just means unmetered cpu

What about burstable instances on AWS, and whatever is the equivalent in other clouds? Hard to imagine those having a dedicated core, would probably defeat the purpose.

Re: Downfall Attacks

#99

Post by [deleted] »

Remnant44 wrote: post #45
stalfosknight wrote: post #39

Earlier quoted context omitted.

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 extensiv…

[deleted]

Re: Downfall Attacks

#100

Post by kazinator »

Negitivefrags wrote: post #33

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…

> 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.

Yes. This has had its heyday: the era of the time-shared systems, from the 1960's, right into the 1990's (Unix systems with multiple users having "shell accounts", at universities and ISP's and such). These CPU attacks show us that secure time-shared systems where users run arbitrary machine code is no longer feasible.

There will still be time sharing where users trust each other, like workers on the same projects accessing a build machine and whatnot.

Post reply on HN