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

191–200 of 349 posts

Re: Downfall Attacks

#191

Post by jgalt212 »

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…

> Outside researches need to reverse all this by probing a black box

The kids are calling this activity "prompt engineering".

Re: Downfall Attacks

#192

Post by CanaryLayout »

efficax wrote: post #159
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…

an easier explanation is that modern chipsets are incredibly complex, side channel attacks like these are hard to reason about and traditionally, processors themselves have not been the target of these kinds of attacks, so i don’t think the engineers working on them are accustomed to thinking about them as attack surfaces in this way.

You didn't have to think about this when you ran your code on your own chips; so it's your fault for backdooring the front end into the datacenter.

But now we have the 21st-century mainframe we like to call the cloud, where everything is shared. So I upload a container image with the vampire vuln intending to read all the activity on the host. Other customers jobs, the OS itself, even steal internal keys used at Amazon.

The motivation to do this kind of attack now is incalculable.

Re: Downfall Attacks

#193

Post by toyg »

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.

Re: Downfall Attacks

#194

Post by CanaryLayout »

rvba wrote: post #184
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!

shoulda bought the threadripper the intern recommended than buying that vulnshit your ISV recommended to you

Re: Downfall Attacks

#195

Post by BeeOnRope »

justinator wrote: post #174
margalabargala wrote: post #161

Earlier quoted context omitted.

> I hope you're not in charge of hiring QA. This seems unnecessarily harsh. The whole post would be improved by removing that sentence IMO.

I'm in the camp that developers shouldn't be responsible for having a transcendental ability to predict future (example) security holes. If one appears, it's really the QA's job to document it and experiment with other similar vectors of attack. The developers are, you know: developing. Bring them back in when the security issues needs to be fixed, once it's found just how big the problem is.

Shouldn't the functions of "development" and "QA" both reside under the umbrella of the chip-maker though?

In fact, chip-makers famously invest an insane amount of money into "QA" (aka "validation") and many features or lack thereof are often put down to the cost of QA rather than the cost of development.

Re: Downfall Attacks

#196

Post by yyyk »

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 chipmakers don't have an incentive to look too hard for speculation security issues beyond a bit of PR. If they succeed, they lose money and marketshare, while their 'insecure' opponents gain and at most patches later. And in fairness, a lot of these bugs are rather theoretical. Until buyers take these bugs much more seriously, this isn't going to change.

Re: Downfall Attacks

#197

Post by BeeOnRope »

chrsw wrote: post #187
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.

Granted but the vendors accept these are serious problems given that they are immediately patched and the mitigation all enabled by default even at significant performance cost (most chip generations are down double digit perf % based versus "zero mitigations" at this int).

So they don't need to build the "perfect processor" but why aren't they discovering any of these issues themselves?

Re: Downfall Attacks

#198

Post by BeeOnRope »

anarazel wrote: post #182
BeeOnRope wrote: post #178

Earlier quoted context omitted.

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

> But that doesn't prevent issues due to switching between customers on the same physical core, no?

Yes they are explicit that customers may be time-shared on a physical core ("burstable" instances don't really make sense without that). Most of these attacks aren't known to be possible in that scenario and in any case the mitigations are much easier since flushing sensitive state at group scheduling boundaries is much less costly than permanent dynamic changes to how concurrent SMT threads interact.

Re: Downfall Attacks

#199

Post by anarazel »

BeeOnRope wrote: post #198
anarazel wrote: post #182

Earlier quoted context omitted.

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

> But that doesn't prevent issues due to switching between customers on the same physical core, no? Yes they are explicit that customers may be time-shared on a physical core ("burstable" instances don't really make sense without that). Most of these attacks aren't known to be possible in that scenario and in any case the mitigations are much easier since flushing sensitive state at group scheduling boundaries is muc…

Yes, it's certainly easier to mitigate at a boundary that's already as costly as switching between VMs.

The paper documents that disabling SMT does not entirely mitigate the problem (In 9.1). They briefly mention trying instructions to avoid the microarchitectural leaks, but don't go into more detail than mentioning verw isn't sufficient.

They state that a switch to/from SGX, with SMT disabled, doesn't prevent the attacks. See 8.1. That's not the same as a cross-vm switch, but it's certainly interesting that the attempts at flushing microarchitectural state when exiting SGX don't provide protection.

Re: Downfall Attacks

#200

Post by Panzer04 »

BeeOnRope wrote: post #188
mabbo wrote: post #155

Earlier quoted context omitted.

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

If a bug is not known, most of the incentives to the vendor are to not bother investigating, I suspect.

You could spend arbitrary amounts of time looking for these bugs and find nothing. Simpler and easier to offer a bounty or something and fix it then. If no one publicly finds the bug it doesn't matter to the mfg (and it wouldn't surprise me if there's truth to your supposition that they know about the bug but wait to fix until someone reports it - no public backlash so long as the bug is unknown)

Fixing bugs prior to release seems easy and free, though, especially since many more eyes would also be on the "new" in progress architecture, and proper hardware mitigations that don't cost a lot of performance can be made.

Post reply on HN