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

61–70 of 349 posts

Re: Downfall Attacks

#61

Post by hsbauauvhabzb »

bee_rider wrote: post #57
hyperman1 wrote: post #46

Earlier quoted context omitted.

I've wondered if we can't give a dedicated core to the browser. Of course, then web pages can steal from other web pages. Maybe task switching needs to erect much higher barriers between security contexts, a complete flush or so?

I wish chips would come with a core devoted to running this kind of untrusted code; maybe they could take something like an old bonnell atom core, strip out the hyper threading, and run JavaScript on that. If a script can’t run happily on a core like that, it should really be a program anyway, and I don’t want to run it.

I’m not saying you’re wrong, but I have a hard time believing web developers would be capable of writing code efficient enough to share a single core. LinkedIn was slamming my CPU so much that I isolated it in a separate browser

Re: Downfall Attacks

#63

Post by Findecanor »

nwmcsween wrote: post #13

Haven't RTFA but would zeroing registers fix this (-mzero-caller-saved-regs=used)?

I don't think so. This vulnerability is leaking data from a load-buffer, not directly from registers. It affects data that is loaded in bulk or to vector registers.

However, general purpose registers are also loaded passing through this buffer during context switches.

Re: Downfall Attacks

#64

Post by bee_rider »

hsbauauvhabzb wrote: post #61
bee_rider wrote: post #57

Earlier quoted context omitted.

I wish chips would come with a core devoted to running this kind of untrusted code; maybe they could take something like an old bonnell atom core, strip out the hyper threading, and run JavaScript on that. If a script can’t run happily on a core like that, it should really be a program anyway, and I don’t want to run it.

I’m not saying you’re wrong, but I have a hard time believing web developers would be capable of writing code efficient enough to share a single core. LinkedIn was slamming my CPU so much that I isolated it in a separate browser

I think you are right, my wish involves living in a slightly different universe where the web has taken a slightly less silly direction of development.

Re: Downfall Attacks

#65

Post by sidewndr46 »

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…

If someone created a way for WASM to talk to an SDL equivalent, it'd probably end use of HTML & CSS

Re: Downfall Attacks

#66

Post by ibejoeb »

Liquix wrote: post #21
v8xi wrote: post #4

From FAQ: [Q] How long have users been exposed to this vulnerability? [A] At least nine years. The affected processors have been around since 2014. Amazing how these vulnerabilities sit around unnoticed for years and then it takes two weeks for someone to code up an exploit.

All a publication indicates is that a white/grey hat researcher has discovered the vulnerability. There is no way to know if or how many times the same flaw has been exploited by less scrupulous parties in the interim.

Since it is in a class of other well known vulnerabilities, I'm going to assume that there has been quite a bit of active research by state-operated and state-sponsored labs. I think it's more likely than not that this has been exploited.

Re: Downfall Attacks

#67

Post by [deleted] »

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…

[deleted]

Re: Downfall Attacks

#68

Post by paxys »

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…

So one should never install software from more than one company on a computer?

Re: Downfall Attacks

#69

Post by bee_rider »

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…

It is sort of like the second law of thermodynamics (before statistical mechanics came around and cleared things up): sure, maybe not well founded in some analytical or philosophical sense, but experimentally bulletproof to the point where anyone who tries to sell you otherwise would be regarded very suspiciously. The idea that any two programs running on a computer can be prevented from snooping on each other.

Re: Downfall Attacks

#70

Post by Veserv »

I am a little unclear on the attack. What data in the temporal buffer is being forwarded to the attacking vpgather?

Is the content of the temporal buffer just being blindly forwarded during speculative execution even if the indexed address of the attacking vpgather does not match?

Otherwise how is the speculative vpgather allowed to load the values of the temporal buffer?

If it is not blind is it a virtual address match? I guess it could also be a not-Present mapping physical match as well? I can not think of any other possibility off the top of my head.

If it is a blind forward that is pretty amazingly bad.

Post reply on HN