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

241–250 of 349 posts

Re: Downfall Attacks

#241

Post by CanaryLayout »

snvzz wrote: post #237
acdha wrote: post #211

Earlier quoted context omitted.

This isn’t true - note how similar vulnerabilities have occurred on ARM, POWER, etc. – and even if you weren’t wrong, it would be off-topic for this thread since you’re not giving anyone useful information.

>This isn’t true - note how similar vulnerabilities have occurred on ARM, POWER, etc. I understand you're trying to argue against my main point, which is: >ISA complexity breeds microarchitecture bugs. And definitely stands. From there I have no idea how you derived that bugs are impossible under a simple ISA, which is implied in your statement. As an added note: ARM in particular isn't simple. It's simpler than x86,…

On a certain level this is like arguing that you will never see this problem in an Arduino.

I mean, sure. On many levels and planes you are correct, but not where any of the intersections matter.

Re: Downfall Attacks

#242

Post by stevefan1999 »

broodbucket wrote: post #233
zerocrates wrote: post #117

Only up to 11th gen... it didn't seem like this could have been disclosed to Intel soon enough for them to have fixed it for 12th gen, so had they just happened to fix it while fixing something else, or what? Decided to look in the paper and "Intel states that newer CPUs such as Alder Lake, Raptor Lake, and Sapphire Rapids are unaffected, although not a security consideration and seems just a side effect of a signifi…

Microarchitectural behaviour changes from generation to generation, and thus so do side effects. Fixing things by accident (and also introducing new problems by accident) are relatively frequent occurrences

Fix one big bug, get two small bugs...

Re: Downfall Attacks

#243

Post by snvzz »

CanaryLayout wrote: post #241
snvzz wrote: post #237

Earlier quoted context omitted.

>This isn’t true - note how similar vulnerabilities have occurred on ARM, POWER, etc. I understand you're trying to argue against my main point, which is: >ISA complexity breeds microarchitecture bugs. And definitely stands. From there I have no idea how you derived that bugs are impossible under a simple ISA, which is implied in your statement. As an added note: ARM in particular isn't simple. It's simpler than x86,…

On a certain level this is like arguing that you will never see this problem in an Arduino. I mean, sure. On many levels and planes you are correct, but not where any of the intersections matter.

If it's not clear enough, I am not talking whatever Arduino strawman you came up with.

I am talking about RISC architectures such as RISC-V (which I mentioned by name), the sort that can scale all the way up to supercomputers and down to microcontrollers.

There is no justification for putting up with x86's complexity. This complexity has negative consequences such as vastly increased likeliness of micro-architectural bugs.

It is utter madness for many of its current popular uses, such as in servers handling personal data.

Re: Downfall Attacks

#244

Post by CanaryLayout »

EGreg wrote: post #103

How can the registers still hold this info when users switch? I would think that it is very transitory, and wiped by other stuff quickly

The OS job scheduler informs the CPU when it's ideal to swap jobs. But the OS is not doing the work of moving the register and stack pointers, the microcode is. These timing attacks take advantage of shared information in the cache (where it's likely the context of the thread you are not supposed to be able to read is).

SMT (hyperthreading) introduces some ambiguity when the context change is going to happen, and it appears there's instructions that are callable where registers/mem can be read that were outside the calling context.

Re: Downfall Attacks

#245

Post by mekoka »

justinator wrote: post #132
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…

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

Why the personal attack? The logic is sound. Isn't QA typically part of the same organization?

Re: Downfall Attacks

#246

Post by hansendc »

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

The AVX disable is only when you use "gather_data_sampling=force". The default is to leave AVX alone and proclaim the system to be vulnerable.

From https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... :

> Specifying "gather_data_sampling=force" will use the microcode mitigation when > available or disable AVX on affected systems where the microcode hasn't been > updated to include the mitigation.

Disclaimer: I work on Linux at Intel. I probably wrote or tweaked the documentation and changelogs that are confusing folks.

Re: Downfall Attacks

#247

Post by CanaryLayout »

peddling-brink wrote: post #236
yyyk wrote: post #196

Earlier quoted context omitted.

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.

Clouds take these vulns seriously, and have a lot to lose, and have deep wallets. I'd be surprised if this topic didn't come up when large purchases are discussed. Not that there are many alternatives..

They have workarounds. If you prevent multi-tenant from sharing their threads on the same core, that eliminates the most desirable goal of an attacker.

However it does not eliminate the vulnerability within a single tenants own threads.

You also have to think about all the web shops that are out there that are just running proxmox or a cloud reseller who reintroduces the vulnerability in their multicore VPS setup

Re: Downfall Attacks

#248

Post by _lvbh »

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…

NSA Backdoor \s

Re: Downfall Attacks

#249

Post by CanaryLayout »

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…

Think of all the cloud resellers that are out there who really aren't segregating their tenants out or it's just a web shop with proxmox who recombined their own customers onto a core even though the cloud provider specifically segregated it

Re: Downfall Attacks

#250

Post by CanaryLayout »

pwarner wrote: post #80
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…

I think most if not all cloud VMs dedicate a core to you. Well, there are some that share like the T series on AWS and I think other clouds have similar, but my bet is they can put in an extra "flush" between users to prevent cross tenant leakage. Of course cross process leakage for a single tenant is an issue, in cloud or on prem, and folks will have to decide how much they trust the processes on their machine to no…

This concern I also share and it's probably worth converting into layman's terms so that all computer users understand what it is. Basically the job scheduler Behavior in the OS needs to surface to the user with understandable language they can read so they can make the trade-off decision.
Post reply on HN