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

231–240 of 349 posts

Re: Downfall Attacks

#231

Post by dzaima »

Panzer04 wrote: post #201
IlliOnato wrote: post #134

Earlier quoted context omitted.

The only 100% reliable way is to turn off branch prediction completely, and yes, this would make the processors at least 2 times slower, perhaps more. Too bad that apparently nothing came out of the Mill architecture. My limited understanding is that this architecture would not have such vulnerabilities. Of course it's possible it would have others :-) but being much simpler, at least conceptually, perhaps it would h…

Given the classic stack overflow branch predictor question, you are underselling things quite a lot - a factor of 6 on those older processors in question, and who knows on modern processors. https://stackoverflow.com/questions/11227809/why-is-processi...

I'd give at least a single order of magnitude for most code; maybe closer to two even.

Re: Downfall Attacks

#232

Post by r3trohack3r »

throwaway892238 wrote: post #226
eternityforest wrote: post #221

Earlier quoted context omitted.

HTML/CSS is one of the easiest way to develop GUIs, one of the most visually flexible, and one of very few things this side of ncurses that runs everywhere. Actually, without hacks, there are probably more end user devices with a browser than a command line. It's also highly standardized. Regular programming languages have dozens of GUI toolkits, or at least one per platform. I'd rather we go the other way, and build…

If by "highly standardized" you mean "you don't get a choice in what you can do or how it works", I agree. Native mobile apps thrive despite this magical web browser working everywhere, because the web browser simply doesn't do what native apps do. You may enjoy that, but a million businesses and billions of users out there don't agree, because they use native apps. There were 255 billion native mobile app downloads…

> Native mobile apps thrive despite this magical web browser working everywhere

There’s also user behavior. Many users are conditioned to get software through the App Store. I’ve seen this be a driving factor for quite a few web native applications spinning up native dev teams and shipping native clients.

Many folks are surprised to see just how far you can push a browser app and how small the gap between web and browser has become for well built applications, including native-like things like Bluetooth, NFC, USB, etc. (see: https://youmightnotneedelectron.com/)

Have hacked with quite a few devs/companies that had a fully functioning offline capable web native application. The most requested feature they’d get? “I want to download it from the App Store.” (Usually in the form of “I can’t find your app in the App Store”)

I suspect this is why the PWA experience on mobile devices hasn’t been well paved and why some App Store policies call out “don’t just wrap a browser view in a native app” - they want to keep users coming in the front door of a marketplace where they collect a cut off the top of all transactions.

Re: Downfall Attacks

#233

Post by broodbucket »

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

Re: Downfall Attacks

#234

Post by semiquaver »

bob1029 wrote: post #208
ancris wrote: post #107

At this rate, with all these vulnerabilities and mitigations, we'll rollback CPU performance back at least 10 years.

It seems to me like most don't have a fundamental gut feel for what speculative execution actually is and the implications of "not getting it". At some level we need to fight for performance. My operating systems are only getting slower and shittier. I cannot fathom my CPUs going backwards too. Security must take a back seat at some point. You can't put bubble wrap and warning labels over everything or it becomes use…

  > Why should everyone else on earth have to suffer crappier performance by default because of the business/software practices of a select few?
The author states in the article that they believe this may be exploitable from javascript in a browser. Just to hammer the point home, any web page could steal anything in memory on your computer. Spectre was also browser-exploitable, and was mitigated there partly by making access to high precision timers privileged. This is very much not a problem that only impacts cloud providers.

Re: Downfall Attacks

#235

Post by parasubvert »

throwaway892238 wrote: post #226
eternityforest wrote: post #221

Earlier quoted context omitted.

HTML/CSS is one of the easiest way to develop GUIs, one of the most visually flexible, and one of very few things this side of ncurses that runs everywhere. Actually, without hacks, there are probably more end user devices with a browser than a command line. It's also highly standardized. Regular programming languages have dozens of GUI toolkits, or at least one per platform. I'd rather we go the other way, and build…

If by "highly standardized" you mean "you don't get a choice in what you can do or how it works", I agree. Native mobile apps thrive despite this magical web browser working everywhere, because the web browser simply doesn't do what native apps do. You may enjoy that, but a million businesses and billions of users out there don't agree, because they use native apps. There were 255 billion native mobile app downloads…

You are delusional and terribly out of your depth if you think even a sizable minority has any interest in getting rid of hypertext and the web. Networked native apps are useless without the web architecture as the glue to integrate between them. It is highly likely that URIs, HTTP and hyperlinks will still be a foundational elements of our technology world in a hundred years.

Re: Downfall Attacks

#236

Post by peddling-brink »

yyyk wrote: post #196
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.

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

Re: Downfall Attacks

#237

Post by snvzz »

acdha wrote: post #211
snvzz wrote: post #162

ISA complexity breeds microarchitecture bugs. In the internet era, x86 is an anachronism. RISC is the way forward. RISC-V is inevitable.

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, but that's a low bar to meet.

>even if you weren’t wrong, it would be off-topic

We will have to agree to disagree on this.

Re: Downfall Attacks

#238

Post by parasubvert »

bob1029 wrote: post #208
ancris wrote: post #107

At this rate, with all these vulnerabilities and mitigations, we'll rollback CPU performance back at least 10 years.

It seems to me like most don't have a fundamental gut feel for what speculative execution actually is and the implications of "not getting it". At some level we need to fight for performance. My operating systems are only getting slower and shittier. I cannot fathom my CPUs going backwards too. Security must take a back seat at some point. You can't put bubble wrap and warning labels over everything or it becomes use…

These vulnerabilities have a lot less to do with cloud providers, and a lot to do with networked computers in general. It's not unreasonable to expect this exploit to be done via web browser, as was demonstrated with prior speculative execution exploits.

Fundamentally, the only reason we need speculative execution is that we haven't updated our software to be more concurrent (reflecting how chips have kept pace with Moore's law for 15+ years), we still program as if we're in the 1970s.

This may turn into a great opportunity to force a rebuild a lot of ancient code.

For more information: C is not a Low Level Language https://queue.acm.org/detail.cfm?id=3212479

Re: Downfall Attacks

#239

Post by CanaryLayout »

IlliOnato wrote: post #129
dcow wrote: post #71

Earlier quoted context omitted.

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?

Yeah, I am sure the customers can sue, but would they win? I find it unlikely.

AMD has the same problem (Inception). Predictive instruction pipelining makes timing and context separation harder. Even if you are on s390x or M1 it's not like you are safe either. This is a whole field of study.

In my mind the better mitigation is to put control over trusted code back to the user and to do that you have to add less-performant cores onto the die and force the operator to elevate (or not) to SMT.

Right now it's an all-or-nothing proposition for the whole board. I would like to think that you can take your untrusted code and stick it on the less-performy cores with the safer instruction pipelining scheme so an actual physical barrier exists.

If that was in the chip architecture, then it's up to OS vendors to surface it in a way that developers understand, and then down to the operator to decide upon configuration.

You are never going to get a perfect-solve from the chipmakers on this where the consumer has to do nothing.

Re: Downfall Attacks

#240

Post by slondr »

wg0 wrote: post #109
sidewndr46 wrote: post #65

Earlier quoted context omitted.

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.

This has been possible for years. I actually got in the habit of porting my qt projects to the web target because they ran better than native compiled on some of my older machines.
Post reply on HN