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

311–320 of 349 posts

Re: Downfall Attacks

#311

Post by zamadatix »

BeeOnRope wrote: post #185
zamadatix wrote: post #179

Earlier quoted context omitted.

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 dif…

I dabble in this space (hardware reverse-engineering) and write software for a living and in my opinion the gaps are huge. I should disclose have been paid by a chip-maker for a blog post that I wrote which "disclosed" an optimization which could be uses for a side channel attack (though I did not even suggest that aspect) and which was subsequently patched away via a microcode update. The whole process was very surp…

Do you have a link for the blog post? I'd love to read more about that.

Since we disagree in how big the gap is, and neither of us is going to get a satisfactory answer out of a chip maker any time soon, perhaps a different argument: there are plenty or microcode updates all the time, doing more than fix just security bugs. There are also security bugs like M1racles which have nothing to do with performance incentives. If these can all be explained by a lecture halls worth of people finding things most wouldn't post release of the chip then why does the same situation on security issues require unique explanation?

Re: Downfall Attacks

#313

Post by flerchin »

dijit wrote: post #292
mike_hearn wrote: post #289

Earlier quoted context omitted.

One possibility nobody mentioned yet: the chip vendors don't invest a ton of time looking for them because they don't actually matter that much. Bear in mind, security researchers are incentivized to find things to build their reputation. It's very often the case that they claim something is a world-shaking security vulnerability when in reality it doesn't matter much for real world attackers. Has anyone ever found a…

> Has anyone ever found a speculation attack in the wild? I think the answer might be no. this is known as the Y2K paradox. The Y2K bug had the potential to be very dangerous, but due to a wide-reaching campaign and tonnes of investment in prevention, when the millennium came, it did so with very few issues (though there were still some ); leading many to speculate that the issues were overblown

It's also the anti-tiger rock.

Tigers exist, and can kill you, so you'd better hold this rock at all times.

Re: Downfall Attacks

#314

Post by pnut »

bsder wrote: post #138
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 problem is that nobody wants to admit that the old, stodgy mainframe guys were right 30 years ago and that sharing anything always results in an exfiltration surface. Nobody wants to be the first to take proper steps because they have to either: 1) Partition hardware properly so that users are genuinely isolated. This costs silicon area that nobody wants to pay for. 2) Stop all the speculative bullshit. This thro…

Bad news, 1993 was 30 years ago. Maybe 50+ years ago at this point.

Re: Downfall Attacks

#315

Post by macinjosh »

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…

> really all you need is bytecode that calls an ABI, and a widget toolkit that talks to a rendering API

Browsers have a 2D renderer (canvas) and you can write your GUI code in C++, Rust, or whatever and compile it to WASM. Some widget toolkits for this even exist already. If this were a superior model it would have taken over by now? I guess you are after deeper integration with the desktop environment?

Re: Downfall Attacks

#316

Post by errantmind »

ftaghn wrote: post #262
errantmind wrote: post #121

The Linux mitigation can be disabled with gather_data_sampling=off in the kernel boot parameters. Be warned, apparently Grub had some kind of problem back in August 2022 and this pre-existing bug broke my boot completely when I updated grub for the above mitigation. I had to boot into a live ISO and reinstall grub to fix it.

> Be warned, apparently Grub had some kind of problem back in August 2022 Are you referring to this? https://archlinux.org/news/grub-bootloader-upgrade-and-confi... This isn't the first time, and won't be the last time, something like that happens with grub, and it's entirely an issue with the user not doing what they should when they run archlinux or some other minimalist distribution that doesn't automate the proce…

Good to know and, yes, that was the issue (grub-mkconfig without grub-install). Somehow I've never had this issue in Arch before now and wasn't aware of this idiosyncrasy.. but now I know.

Re: Downfall Attacks

#317

Post by ogoffart »

macinjosh wrote: post #315
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…

> really all you need is bytecode that calls an ABI, and a widget toolkit that talks to a rendering API Browsers have a 2D renderer (canvas) and you can write your GUI code in C++, Rust, or whatever and compile it to WASM. Some widget toolkits for this even exist already. If this were a superior model it would have taken over by now? I guess you are after deeper integration with the desktop environment?

The challenge with toolkits confined to rendering is their inability to effectively utilize the browser's integration with the OS. Key components like font rendering, input methods (including standard key shortcuts and behavior within input fields), selection handling, image decoding, network stack, native-like scrolling, and accessibility features need to be recreated from scratch. A web toolkit must use the DOM for optimal performance. (and therefore lower to HTML)

Re: Downfall Attacks

#318

Post by acdha »

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,…

I see you’re basically trying to “No True Scotsman” a definition where anything which isn’t RISC-V is too complicated. That’s a shame as the time you’re spending on counterproductive RISC-V advocacy could have been spent learning about this class of attack and how it has nothing to do with the ISA.

When a CPU implements speculative execution, this class of attack becomes a concern. If it doesn’t, it’ll be too slow for most applications. Fortunately, the people who are - unlike you - actually helping RISC-V are working on efficient countermeasures:

https://arxiv.org/abs/2206.04507

Re: Downfall Attacks

#319

Post by polynomial »

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…

Presume you did not mean bytecode that calls ABI, but rather API? (ABI is a Web3 thing.)

Re: Downfall Attacks

#320

Post by kragen »

AgentOrange1234 wrote: post #310
rzwitserloot wrote: post #227

Earlier quoted context omitted.

This. Downfall affects CPUs released almost a decade ago. The argument of 'Intel caught a ton of these and downfall is the one that got away' doesn't add up. Surely Intel would find at least one issue during development of a new chip that has the property that it _also_ affects older chips. They can hardware-fix it before ever releasing their new chip, but unless they just decided to ignore the vulnerability in their…

FWIW. Spectre/meltdown really caught the hardware development world off guard. Speculative execution was well-trodden ground and we thought it was fine. After these attacks, we had legacy designs that we needed to patch in a hurry, and the performance costs of not speculating were unfathomable. A lot of work went into mitigations like new kinds of barriers. But hardware designs are enormous and there is state lurking…

dan bernstein had pointed out the risk that speculative execution would lead to side-channel attacks years before, but there's a common pattern where security people point out a risk and then vendors dismiss it as impractical until it's demonstrated in practice
Post reply on HN