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

261–270 of 349 posts

Re: Downfall Attacks

#261

Post by lenkite »

parasubvert wrote: post #235
throwaway892238 wrote: post #226

Earlier quoted context omitted.

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.

HTTP != HTML/CSS. You are applying a [Strawman Argument]

Re: Downfall Attacks

#262

Post by ftaghn »

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 process of updating grub.

Grub uses a configuration file generator that reads from the human readable/editable /etc/default/grub and creates a /boot/grub/grub.cfg, and the result of that generator doesn't have a stable "interface". At any time, an update to grub might read grub.cfg incorrectly, if you do not generate it again.

99% of the linux distributions out there had no breakage with grub because they run the grub-mkconfig command every time grub is updated through grub-install. It is automated within the scripts included in the packaging of the distribution and the user will never see any of this in Debian, Ubuntu, Fedora etc. If a newer grub package comes out on those distro, the scripts will run both grub-install and grub-mkconfig. There will never be a mismatch between the grub binary versions and the config file state.

Arch Linux users who knew how grub works also had no issue. If you update grub, you must regenerate the config file (it's a "if you update" because arch linux, by default, will NOT automatically update grub at all, updating the package is not the same as updating grub). If you edit the config file and regenerate it when you have a newer grub package installed, you must also update the grub binaries. So any time you do something with grub, you MUST run grub-install, then grub-mkconfig. Doing only one of the two is akin to doing a partial upgrade, which is a no-no.

If, as I suspect, you're an arch user, I would recommend switching to systemd-boot, which doesn't even need a configuration file at all if you set up your system to follow its conventions and use unified kernel images. EFI binaries are automatically scanned and shown in the menu and it uses EFI variables to remember the few settings you can interactively edit, like the preferred kernel to boot. It's robust and only has what is needed in a small, KISS boot manager. It can't even be truly called a boot loader because that part is managed by efistub which is part of the unified kernel image. Very unlike grub, which has the whole kitchen sink, including its own implementation of a ton of filesystems..

Re: Downfall Attacks

#263

Post by skolsuper »

Panzer04 wrote: post #200
BeeOnRope wrote: post #188

Earlier quoted context omitted.

That's true, but it leads the odd assumption that the vendor managed to fix N side-channel attacks before release but 0 thereafter, while random individuals fixed M thereafter over a period of years with N >> M. This seems to be much less likely than the conclusion that vendors are not in fact fixing many prior to the release and then stopping "cold turkey" after that. Especially since these attacks seem to cross chi…

If a bug is not known, most of the incentives to the vendor are to not bother investigating, I suspect. You could spend arbitrary amounts of time looking for these bugs and find nothing. Simpler and easier to offer a bounty or something and fix it then. If no one publicly finds the bug it doesn't matter to the mfg (and it wouldn't surprise me if there's truth to your supposition that they know about the bug but wait…

What about the incentive to release "the most secure chips on the market", are you discounting that a bit too much?

Granted that human nature tends to mean these factors don't have a high enough weight, e.g. it's not the safest airplanes that sell the most, it's the cheapest ones that meet the regulations, and the regulations drive safety improvements, for the most part

Re: Downfall Attacks

#264

Post by zgluck »

bironran wrote: post #115

Worth to note that GCP has this patched ( https://cloud.google.com/support/bulletins#gcp-2023-024 )

Corresponding AWS notice:

https://aws.amazon.com/security/security-bulletins/AWS-2023-...

AWS customers’ data and instances are not affected by this issue, and no customer action is required. AWS has designed and implemented its infrastructure with protections against this class of issues. Amazon EC2 instances, including Lambda, Fargate, and other AWS-managed compute and container services protect customer data against GDS through microcode and software based mitigations.

Re: Downfall Attacks

#265

Post by johncolanduoni »

DarkNova6 wrote: post #258
dwrodri wrote: post #206

Earlier quoted context omitted.

I'm gonna get put on a list for typing this out but I'll clarify: 1. Bad guy creates cloud account and spawns 10 of the cheapest VMs across different data centers, let's say this costs a total of, what... $50 a month? 2. Bad guy reads this paper, and makes a program that frequently samples SIMD registers. Contents get dumped to stdout and then streamed over an encrypted line to a RAID array hosted in $COUNTRY_WITHOUT…

hmmm. Does this not assume that a cpu is shared among exactly 2 tenants over a long period of time? And can‘t the cloud provider simply block access to the cpu api? Like they don’t allow you to create your own threads? Just trying to understand this.

A VM cloud provider can't block you from running at least one thread, which is all the malicious threads required for this attack.

However none of the big cloud providers share CPU cores between users to combat exactly this kind of thing. I really wish the people that did these disclosures were more up-front about this, instead of saying vague things like "frequently happens on modern-day computers". Though I guess you can assume that if an attack would work on AWS the researcher would definitely mention it, so the lack of such an explicit claim almost ensures the attack is not viable on major clouds.

Re: Downfall Attacks

#266

Post by whoisthemachine »

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…

It's the same as any product, the product team wants a faster, cheaper product, yesterday. Security and trust is secondary, because if you're lucky enough, that will fall on the next product team.

Beyond that, processors contain billions (or trillions?) of possible outcomes from a set of inputs. Testing for all of these just to verify reliability and stamp out logic bugs is really hard due to the combinatorial explosion. Putting security testing on top just complicates matter further. The best they can probably do is map out potential ways in which their general purpose processors could be used for specific nefarious uses.

Re: Downfall Attacks

#267

Post by asaddhamani »

eternityforest wrote: post #260
r3trohack3r wrote: post #232

Earlier quoted context omitted.

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

We really need to standardize "just wrapping a browser view". Why are we shipping a whole browser when we could be shipping a zip file of HTML with some metadata, and maybe a few tiny native helper utilities?

This is how PWAs work on smartphones. I recall coming across some electron alternatives that use the system webview and those are able to generate binaries hundreds of kilobytes in size. But you lose out on access to many of the modern APIs due to Safari there.

Re: Downfall Attacks

#268

Post by CanaryLayout »

tedunangst wrote: post #83
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…

Does Digital Ocean count as a major cloud player?

Yes. And Linode. And Quadra. And OVH.

A lot of people on YC are enterprisey-brained and only think there are 3 possible clouds, and then there is the rest of the planet who can't afford to park their cash at AWS and set it on fire.

Re: Downfall Attacks

#269

Post by Panzer04 »

skolsuper wrote: post #263
Panzer04 wrote: post #200

Earlier quoted context omitted.

If a bug is not known, most of the incentives to the vendor are to not bother investigating, I suspect. You could spend arbitrary amounts of time looking for these bugs and find nothing. Simpler and easier to offer a bounty or something and fix it then. If no one publicly finds the bug it doesn't matter to the mfg (and it wouldn't surprise me if there's truth to your supposition that they know about the bug but wait…

What about the incentive to release "the most secure chips on the market", are you discounting that a bit too much? Granted that human nature tends to mean these factors don't have a high enough weight, e.g. it's not the safest airplanes that sell the most, it's the cheapest ones that meet the regulations, and the regulations drive safety improvements, for the most part

I guess there's probably some margin in it - if both parties seem about equally vulnerable, there's not much lost. You could expend a lot of effort into security, but the nature of these bugs is still that they are fairly rare, often require pretty significant hurdles, etc. The mfg. could probably spend a lot more money and find a few extra bugs, but who knows if they would have turned into "real" exploits?

Remember that this particular bug isn't actually present on the newest chips either - and 12th/13th gen were shipping before Intel was informed of this bug - so it was fixed eventually, probably incidentally as a result of design changes.

The unknown factor is how much additional money you'd have to invest to gain additional security, given how esoteric many of these bugs are.

Re: Downfall Attacks

#270

Post by thayne »

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…

> Maybe they did and are well aware of all these attacks but to save face and performance hits they simply hold on to them hoping nobody makes them public?

Or they chose not to look for these types of bugs in the first place, for those reasons.

Post reply on HN