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

201–210 of 349 posts

Re: Downfall Attacks

#201

Post by Panzer04 »

IlliOnato wrote: post #134
ancris wrote: post #107

At this rate, with all these vulnerabilities and mitigations, we'll rollback CPU performance back at least 10 years.

The only 100% reliable way is to turn off branch prediction completely, and yes, this would make the processors at least 2 times slower, perhaps more. Too bad that apparently nothing came out of the Mill architecture. My limited understanding is that this architecture would not have such vulnerabilities. Of course it's possible it would have others :-) but being much simpler, at least conceptually, perhaps it would h…

Given the classic stack overflow branch predictor question, you are underselling things quite a lot - a factor of 6 on those older processors in question, and who knows on modern processors.

https://stackoverflow.com/questions/11227809/why-is-processi...

Re: Downfall Attacks

#202

Post by kzrdude »

kzrdude wrote: post #148

See this LWN story: https://lwn.net/Articles/940783/ on Linux, any cpus that don't have updated microcode will have AVX completely disabled as a mitigation for this issue. That's rather harsh if you ask me and would be very noticeable. Now I'm interested in finding out if I can get updated microcode..

Maybe that's not the default? Not entirely clear from the text.

Re: Downfall Attacks

#203

Post by istjohn »

throwaway892238 wrote: post #58
marssaxman wrote: post #35

Earlier quoted context omitted.

> For JavaScript it’s a bit harder. "We should probably just stop doing it" works for me.

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…

The web started as a graph of hyperlinked documents, and that use case hasn't gone away. SPA's aren't the internet.

Re: Downfall Attacks

#204

Post by acdha »

ajross wrote: post #116
kiririn wrote: post #94

Earlier quoted context omitted.

>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

Per the paper, this looks like an attack against speculated instructions that modify the store forward buffer. The details aren't super clear, but that seems extremely unlikely to survive a context switch. In practice this is probably only an attack against hyperthread code running simultaneously on the same CPU, which I'd expect cloud hosts to have eliminated long ago.

Yeah, the way AWS has stock language like “AWS has designed and implemented its infrastructure with protections against this class of issues” supports the idea that you’re probably not getting anywhere with exploits of this class on a major cloud host any more.

Re: Downfall Attacks

#205

Post by djbusby »

toyg wrote: post #193
BeeOnRope wrote: post #120

What I find odd is that after the initial Spectre attacks, there have been a long string of these attacks discovered by outside researchers and then patched by the chipmakers. In principle it seems like the chipmakers should hold all the cards when it comes to discovery: they are experts in speculative execution, know exactly how their chips work and have massive existing validation suites, simulators and internal ma…

Maybe they're simply victims of Kernighan's Law of Debugging: "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" There is no doubt that Intel make chips "as clever as they can". Hence, by definition, they can't fully debug them.

If debugging is what we call it when fixing things, does that mean we're "bugging" when we make it?

Re: Downfall Attacks

#206

Post by dwrodri »

GartzenDeHaes wrote: post #104
dwrodri wrote: post #73

Earlier quoted context omitted.

I've only done a quick read through the link, but I think the model they imply is that a malicious user could rent a Cloud VM in AWS/Azure/GCP/etc and then sniff the contents of SIMD registers, similar to the Zenbleed attack which was also disclosed recently[1]. This is a big deal because optimized implementations of strcpy, strlen, and memcpy in glibc all use SIMD registers, and glibc is everywhere. 1: https://lock.…

How do they know what data is in the registers? In the linked article, the person running the attack code knows what is running on the target. The target is also conveniently waiting for the attack code to run without doing anything other than referencing the target data.

I'm gonna get put on a list for typing this out but I'll clarify:

1. Bad guy creates cloud account and spawns 10 of the cheapest VMs across different data centers, let's say this costs a total of, what... $50 a month?

2. Bad guy reads this paper, and makes a program that frequently samples SIMD registers. Contents get dumped to stdout and then streamed over an encrypted line to a RAID array hosted in $COUNTRY_WITHOUT_US_EXTRADITION.

3. Bad guy writes program to sift through data dumps on RAID array for passwords, encryption keys, etc.

If you create a cloud instance right now that has an SSH login on port 22, you stream the SSH login logs and see a steady stream of attempted logins to your device. While the marginal cost of brute forcing SSH logins is free (no cloud VM needed) and my proposed scenario isn't, I think this is a very real scenario that needs monitoring.

Re: Downfall Attacks

#207

Post by foolswisdom »

dralley wrote: post #14
galacticaactual wrote: post #11

Stop. Releasing. Attack research. Without. Detection strategies.

It was reported to Intel a full year ago, apparently.

And yet they seem to still not have released the fix...

Edit: they released the fix today, I was mislead by the current tense "is releasing" in the OP.

Re: Downfall Attacks

#208

Post by bob1029 »

ancris wrote: post #107

At this rate, with all these vulnerabilities and mitigations, we'll rollback CPU performance back at least 10 years.

It seems to me like most don't have a fundamental gut feel for what speculative execution actually is and the implications of "not getting it". At some level we need to fight for performance. My operating systems are only getting slower and shittier. I cannot fathom my CPUs going backwards too. Security must take a back seat at some point. You can't put bubble wrap and warning labels over everything or it becomes useless. The most dangerous tools are typically the most effective.

The CPUs are vulnerable because of the exact way in which they are being applied to a problem. Speculative execution is not inherently unsafe. Whatever future predicted memory prefetching shenanigans are going on in my CPU over here have absolutely ZERO impact on your CPU over there. Certainly someone could figure out a protocol/system/architecture that capitalizes on this notion that "2 different CPUs are indeed different CPUs".

One can see how any perspective here still causes trouble for Amazon, Microsoft, et. al., but that was a business risk they signed up for the moment they intended to squeeze every last drop of subscriber revenue out of the hardware. Why should everyone else on earth have to suffer crappier performance by default because of the business/software practices of a select few?

Re: Downfall Attacks

#209

Post by Bu9818 »

kzrdude wrote: post #148

See this LWN story: https://lwn.net/Articles/940783/ on Linux, any cpus that don't have updated microcode will have AVX completely disabled as a mitigation for this issue. That's rather harsh if you ask me and would be very noticeable. Now I'm interested in finding out if I can get updated microcode..

`[ 0.000000] microcode: updated early: 0x27 -> 0x28, date = 2019-11-12`

I'm on haswell. Is there a list of what CPUs get updated microcode? Sad.

Re: Downfall Attacks

#210

Post by dmatech »

winternewt wrote: post #41
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…

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

What's interesting is that the FDIV bug from 1994 could also be worked around, but Intel recalled and wrote off those processors[1]. For their latest several problems, their response was more of a "sucks to be you". While they provided microcode updates and worked with OS vendors, there were performance impacts that materially affected the value of the chips.

1. https://www.intel.com/content/www/us/en/history/history-1994...

Post reply on HN