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

171–180 of 349 posts

Re: Downfall Attacks

#171

Post by tracker1 »

watermelon0 wrote: post #106
H8crilA wrote: post #98

Earlier quoted context omitted.

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.

Not just burstable instances. AWS Fargate, container as a service, allows specifying 0.25 or 0.5 CPU, and I would be surprised if those weren't shared. Same probably? also applies to AWS Lambda.

My guess is there's likely less value in trying to target those kinds of environments... Just poking random data out of lambda or low end vps neighbors is a needle in a haystack the size of the moon in terms of finding anything useful.

It's more likely useful as part of a group of exploits to hit an individual, targeted system.

Re: Downfall Attacks

#173

Post by CTDOCodebases »

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

Re: Downfall Attacks

#174

Post by justinator »

margalabargala wrote: post #161
justinator wrote: post #132

Earlier quoted context omitted.

>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 machine-readable specifications for the low-level operations of these chips. I hope you're not in charge of hiring QA. Bugs are often found by people who AREN'T thinking like th…

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

Re: Downfall Attacks

#176

Post by c2h5oh »

watermelon0 wrote: post #106
H8crilA wrote: post #98

Earlier quoted context omitted.

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.

Not just burstable instances. AWS Fargate, container as a service, allows specifying 0.25 or 0.5 CPU, and I would be surprised if those weren't shared. Same probably? also applies to AWS Lambda.

Worse: by default it's not CPU but VCPU - a single core with multithreading = 2 VCPU

Re: Downfall Attacks

#177

Post by accrual »

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.

I believe this is why OpenBSD disabled SMT by default in June of 2018. [0]

It can still be enabled with a simple 'sysctl', though.

[0] https://www.mail-archive.com/source-changes@openbsd.org/msg9...

Re: Downfall Attacks

#178

Post by BeeOnRope »

BeeOnRope wrote: post #87
vladvasiliu wrote: post #79

Earlier quoted context omitted.

> 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. Isn't this the whole point of AWS' t instances? It's my understanding that they are "shared" at the core level, or else there wouldn't be a reason for the CPU credit balance thing.

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

Re: Downfall Attacks

#179

Post by zamadatix »

BeeOnRope wrote: post #144
zamadatix wrote: post #131

Earlier quoted context omitted.

The logic in this comment rubs me the wrong way. You could use the same train of thought to postulate programmers that have made 2 memory safety errors are nefarious instead of simply human. When billions use something I expect them to find more problems, flaws, and exploits in it than the creator/manufacturer did. The presence of this does nothing to indicate (or refute) any further conclusion about why.

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 different from software. They analyze how individual assembly instructions behave in certain scenarios vs how they are designed to behave. Compare this to the process of attacking closed source software like Windows, sift through a bunch of assembly in a debugger and see what gets left behind or compared incorrectly, and it's not glaringly different just because hardware is involved. Difficult, sure, but far from anything to suggest it should be uncommon. More importantly, by definition you don't really get to see all of the things they do catch. Maybe they are getting 90% of other related vulnerabilities with the patches but you only hear about the 10% that weren't covered by it because that's the only thing someone is going to publish/get a cve for/make the front page of HN.

The point isn't that billions of users all actively try to exploit software it's that if you have billions of users then even if 0.01% try to then that's still a hell of a lot more external bug finders than internal bug finders.

Yeah nothing against you or genuine curiosity it's just when a comment sets up a series of logic and concludes with a leading question then the conversation is damned to largely revolve around the leading question instead of genuine answers.

Re: Downfall Attacks

#180

Post by kzrdude »

Dalewyn wrote: post #114

Am I correct in understanding this affects basically every CPU generation up to and including Alder Lake? EDIT: Maybe not? That linked table is very esoteric.

> Computing devices based on Intel Core processors from the 6th Skylake to (including) the 11th Tiger Lake generation are affected.
Post reply on HN