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

101–110 of 349 posts

Re: Downfall Attacks

#101

Post by H8crilA »

robotnikman wrote: post #5
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.

I have a feeling the time spent searching for the vulnerability in the first place was more than 2 weeks though.

Those things come in waves. Once the first large CPU vulnerability was found then more followed soon. I think it's obvious why this is so.

Re: Downfall Attacks

#102

Post by zamadatix »

Negitivefrags wrote: post #54
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?

It probably would be possible to add a new instruction that causes the processor to flush all state in exchange for sacrificing task switching speed. Of course it might still have bugs, but you could imagine that it would be easier to get right. Of course, it’s not doing much for the billions of devices that exist. I would hope that we could find a software solution that web browsers can implement so that devices can…

Software can choose to invalidate all cache, fence access, and the like today. It may not be a single instruction but it's not far off. Usually something like "just don't JIT 3rd party JS to native code" is "secure enough" most don't want to go down that route though. For cloud (reputable) providers just don't allow more than 1 VM to be assigned to a core at the same time and flush everything between if they are time shared. The mitigations are the way to keep the most overall performance outside those who are most concerned with maximum security, so they are the most popular.

Re: Downfall Attacks

#103

Post by EGreg »

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

Re: Downfall Attacks

#104

Post by GartzenDeHaes »

dwrodri wrote: post #73
GartzenDeHaes wrote: post #62

How could an attacker gain the level of knowledge necessary to accomplish this without compromising the target process?

I've only done a quick read through the link, but I think the model they imply is that a malicious user could rent a Cloud VM in AWS/Azure/GCP/etc and then sniff the contents of SIMD registers, similar to the Zenbleed attack which was also disclosed recently[1]. This is a big deal because optimized implementations of strcpy, strlen, and memcpy in glibc all use SIMD registers, and glibc is everywhere. 1: https://lock.…

How do they know what data is in the registers? In the linked article, the person running the attack code knows what is running on the target. The target is also conveniently waiting for the attack code to run without doing anything other than referencing the target data.

Re: Downfall Attacks

#105

Post by rvnx »

dcow wrote: post #71
2OEH8eoCRo0 wrote: post #42

Earlier quoted context omitted.

The mitigation here can incur a whopping 50% performance penalty. At what point can customers return these CPUs for either being defective or sue for false advertising? If they can't safely meet the target performance they shouldn't be doing these tricks at all.

Did processor companies ever advertise that processors guaranteed certain security properties of the software they execute? Aren't system designers at fault for coming up with the idea of a context switch and assuming that we can trust a processor not to leak details across artificial software constructed boundaries?

But wait, how is it even considered a processor bug ?

You write data inside the registers, yes, other processes can read these registers.

It always been like this, and is absolutely normal.

It's the responsibility of the operating system to clear the registers if it is switching context.

Re: Downfall Attacks

#106

Post by watermelon0 »

H8crilA wrote: post #98
kiririn wrote: post #94

Earlier quoted context omitted.

>are there many clouds that still run workloads from different users on the same physical core? There are a vast number of VPS providers out there that aren’t AWS/GCP/Azure/etc where the answer is yes. Even the ones that sell ‘dedicated’ cores, which really just means unmetered cpu

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.

Re: Downfall Attacks

#108

Post by bhk »

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 you "dedicate cores to specific VMs" you will find that chip designers can also screw that up, just like they can screw up protection within a core. So you might as well proclaim that "impossible to get right" preemptively.

Re: Downfall Attacks

#109

Post by wg0 »

sidewndr46 wrote: post #65
throwaway892238 wrote: post #58

Earlier quoted context omitted.

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

IF GTK/Qt etc can render to canvas using WebGPU while compiled to assembly, I think game is almost over than too IF there's a way to lazy load application modules.

Think Autodesk products. Certain parts (wasm modules) only load when you hover over a menu while overall app loads within milliseconds because it just has the main window and such.

Post reply on HN