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

181–190 of 349 posts

Re: Downfall Attacks

#181

Post by sigotirandolas »

mike_hearn wrote: post #60
winternewt wrote: post #41

Earlier quoted context omitted.

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

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.

On some Skylake CPUs to get full mitigations you are taking a 30% performance penalty _and_ you need to disable SMT which is often another double digit penalty. It's not a literal "toss the physical silicon", but it's getting there.

In fact my thesis is that it's never a literal "toss the physical silicon" because the kernel is able to take control when switching between tasks so (with help from the microcode) it's able to wipe all potential speculation vectors (at an arbitrarily expensive cost) before switching to the next task. This also explains why SMT is unfixably broken on some processors, since by design the kernel does not intervene in the task switching on the virtual cores.

Re: Downfall Attacks

#182

Post by anarazel »

BeeOnRope wrote: post #178
BeeOnRope wrote: post #87

Earlier quoted context omitted.

They are definitely time-sliced among tenants and very possibly two tenants may run at the same time on two hardware threads on the same core: but you could have a viable burstable instance with time-slicing alone.

Nevermind, AWS explicitly documents that all instance types, including burstable, never co-locate different tenants on the same physical core at the same time: https://docs.aws.amazon.com/whitepapers/latest/security-desi...

It only seems to document that there's group scheduling for SMT cores. But that doesn't prevent issues due to switching between customers on the same physical core, no?

"It is possible, however, for two burstable performance EC2 instances to run sequentially (not simultaneously) on the same core. It is also possible for physical memory pages to be reused, remapped, and swapped in and out as virtual memory pages. However, even burstable instances never share the same core at the same time, and virtual memory pages are never shared across instances. "

I only started reading the paper - so I very well might be wrong here - but it doesn't look to me like you need victim/attacker to be scheduled simultaneously on two SMT threads, but that a single core sequentially executing victim / attacker code would be vulnerable. It's possible that the cross-customer "context switch" is larger than the the vulnerable window, but I'd not want to bet on it.

Re: Downfall Attacks

#183

Post by pseudalopex »

alerighi wrote: post #140
jjav wrote: post #112

Earlier quoted context omitted.

> This is an unreasonable position. Vulnerabilities can be fixed That's a highly optimistic position, to the point of being almost wishful thinking. The vulnerability being talked about today has been around since 2014 according to the report. Possibly being exploited for unknown number of years since. Sure, maybe we can workaround this one, now. Other similar ones to be published years into the future are also there…

The real problem here is the x86 architecture. We should stop using it. It's too complex, it's full of stuff made for backward compatibility purposes, it has too many instructions that may have unpredictable results, and for that exact reason it's extremely difficult to get things right. Somewhere in the thousands of instructions that it has you will surely find a bug. We should move forward. Apple did a great job wi…

Meltdown and Spectre affected ARM and POWER CPUs. Apple's included. PACMAN affected M1. The real problem is speculative execution seemingly.

Re: Downfall Attacks

#184

Post by rvba »

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 Intel cut corners wherever possible - so their processors are few percent faster due to each bug, but much less safe.

But hey they were faster than AMD!

Re: Downfall Attacks

#185

Post by BeeOnRope »

zamadatix wrote: post #179
BeeOnRope wrote: post #144

Earlier quoted context omitted.

I think the comparison between CPU and software exploits holds at a very high level, but in the case of software the gap between internal and external researches seems lower. Much software is open-source, in which case the play field is almost level and even closed source software is available in assembly which exposes the entire attack surface in a reasonably consumable form. Software reverse-engineering is a hugely…

I'm not sure I agree significant gaps in the playing fields are really there. By significant I mean something that explains it should be e.g. 10x harder or something to the point it's supposed to be suspicious how the ratio is indicative of something off. Sure, you don't get to see how they laid out the transistors of the CPU but that's not how these attacks work it's by some oversight in memory handling not that dif…

I dabble in this space (hardware reverse-engineering) and write software for a living and in my opinion the gaps are huge.

I should disclose have been paid by a chip-maker for a blog post that I wrote which "disclosed" an optimization which could be uses for a side channel attack (though I did not even suggest that aspect) and which was subsequently patched away via a microcode update. The whole process was very surprising to me in that there must have been several people inside the chip-maker who knew about the optimization I described in much deeper detail ... after all they conceived and implemented it.

So by what path does a blog post mentioning it get treated as the disclosure that results it it being removed when they knew about it all along?

> that's not how these attacks work it's by some oversight in memory handling not that different from software.

I think it is very different. Assembly is merely a somewhat less convenient form of the original semantics that embeds all the relevant semantics related to the attack surface since the original source has been "erased". Many analysis tools such as fuzzers operate directly on assembly with little loss in functionality.

These attacks are against completely unspecified aspects of the instruction execution and lean heavily on the actual hardware implementation (almost at the level of "how the transistors are laid out") such as what hidden buffers are used, when they are filled, how they are shared with sibling threads, etc.

In my experience there are very few people interested in these details outside of the vendors themselves and these folks and the ones creating the exploits would fit in a modestly sized lecture hall. The scope has increased a bit lately (see Tavis's fuzzer work) but it was originally a small group with little or no funding.

Re: Downfall Attacks

#186

Post by raggi »

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…

The intersection of probabilistic optimization and timing based side channels is a gift that will never ever fully go away.

Everything _really fast_ which is approximately any very mature systems gear has probabilistic optimization in it now, and that's where a great deal of modern performance comes from.

Even thermals and power draws produce side channels. Eradicating every side channel is untenable, research is required to understand what side channels are tenable, then we have to patch them up as best we can.

I'm waiting for the one where we find that binning is involved in an integrated way, and that some arbitrary sub-population of popular chips turn out to much more exploitable than others due to particular paths being disabled and leaking extra timing info. That'll be a really fun and awful day.

Re: Downfall Attacks

#187

Post by chrsw »

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…

There's more money to be made in performance and efficiency than security. If chipmakers could design and build the perfect processor, they would. But like anything else complex, there are compromises everywhere.

Re: Downfall Attacks

#188

Post by BeeOnRope »

mabbo wrote: post #155
BeeOnRope wrote: post #141

Earlier quoted context omitted.

I considered this, but we have pretty good evidence that the chipmakers have not been busily secretly patching Spectre attacks: 1) Microcode updates are visible and Spectre fixes are hard to hide: most have performance impacts and most require coordination from the kernel to enable or make effective (which are visible for Linux). There have been a large number of microcode changes tied to published attacks and corres…

You don't need to patch the errors found during the initial R&D. The patch was made before the hardware was ever sold. What's left are the attack vectors that Intel's greatest minds didn't discover.

That's true, but it leads the odd assumption that the vendor managed to fix N side-channel attacks before release but 0 thereafter, while random individuals fixed M thereafter over a period of years with N >> M.

This seems to be much less likely than the conclusion that vendors are not in fact fixing many prior to the release and then stopping "cold turkey" after that. Especially since these attacks seem to cross chip versions, in many cases 6+ generations of chips: if vendors had substantial and increasing efforts on new chip versions they'd also be catching issues that applied to old released chips as well. We don't see that happening.

Re: Downfall Attacks

#189

Post by CanaryLayout »

CTDOCodebases wrote: post #173
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…

And maybe just maybe when the Snowden revelations started to come out some people woke up and realised that the companies who design the processors used in the vast majority of computers are from the US. https://www.theverge.com/2013/12/20/5231006/nsa-paid-10-mill...

Since Applied Cryptograhy and everyday since publication it's been well-known and well-understood that NSA's never-ending efforts to weaken systems to make it easier for them to do their work wrecks havoc and costs billions to everyone else. Luckily their attempt to get everyone to adopt a PRNG that was broken on-purpose was thwarted.

But who's to say that any chipmaker gets bribed to backdoor their design to allow the reading of any page of RAM from any protection level doesn't happen? It would make their job super easy.

Re: Downfall Attacks

#190

Post by stordoff »

basedrum wrote: post #170

Can someone explain why the ssh video at 2:25, where the 256bit comparison is pasted in, it doesn't match? The first two colon separated number sets do match, but not the following two?

At the end of this video? https://downfall.page/media/gds_aes.mp4 They appear to match to me, albeit with the last few characters hidden by the timer. They are visible when the key is copied though.
Post reply on HN