from Hacker News

Downfall Attacks

by WalterSobchak on 8/8/23, 5:27 PM with 336 comments

  • by BeeOnRope on 8/8/23, 9:13 PM

    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 machine-readable specifications for the low-level operations of these chips.

    Outside researches need to reverse all this by probing a black box (plus a few much-worse-than-insider sources like patents).

    Yet years after the initial disclosures it's still random individuals or groups who are discovering these? Perhaps pre-Spectre this attack vector wasn't even considered, but once the general mechanism was obvious did the chip-makers not simply set their biggest brains down and say "go through this with a fine-toothed comb looking for other Spectre attacks"?

    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?

  • by mike_hearn on 8/8/23, 6:22 PM

    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 a massive over-exaggeration, as he hasn't demonstrated any kind of browser based exploit and even if such a thing did exist, it'd affect only a tiny minority of targeted users, as AFAIK many years after the introduction of Spectre nobody has ever found a specex attack in the wild (or have they?)

    I think the more interesting thing here is that it continues the long run of speculation bugs that always seem to be patchable in microcode. When this stuff first appeared there was the looming fear that we'd have to be regularly junking and replacing the physical chips en masse, but has that ever been necessary? AFAIK all of the bugs could be addressed via a mix of software and microcode changes, sometimes at the cost of some performance in some cases. But there's never been a bug that needed new physical silicon (except for the early versions of AMD SEV, which were genuinely jailbroken in unpatchable ways).

  • by Negitivefrags on 8/8/23, 6:23 PM

    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 not be giving up performance for the the normal case.

  • by ndesaulniers on 8/8/23, 7:34 PM

  • by zerocrates on 8/8/23, 9:06 PM

    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 significantly modified architecture." So basically they just randomly fixed it, or at least made this particular exploit nonworkable.

  • by v8xi on 8/8/23, 5:50 PM

    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.

  • by kzrdude on 8/8/23, 10:15 PM

    See this LWN story: https://lwn.net/Articles/940783/

    on Linux, any cpus that don't have updated microcode will have AVX completely disabled as a mitigation for this issue. That's rather harsh if you ask me and would be very noticeable. Now I'm interested in finding out if I can get updated microcode..

  • by bironran on 8/8/23, 9:02 PM

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

  • by buildbot on 8/8/23, 5:33 PM

    This is a huge performance hit - up to 50% it is claimed! 70% of modern intel processors are affected apparently as well.

  • by CanaryLayout on 8/9/23, 1:02 AM

    The NES incorporated a chipset that buried an entire 6502 inside. You can get a Rockchip ARM chip for the price of a pizza that incorporates mixed cores on the die. Maybe the chipmakers don't NEED to solve every edge case until the end of time, but delegate side channel attack mitigations like this back to the chipgobblers (us).

    Hear me out: Instead of making SMT an all-or-nothing pre oposition, we have "lousy cores" where untrusted code goes and make the customer "prove" it should get elevation to the cores with SMT?

    I dont't want to clobber my chip that's running the mega-important payroll jobs where no one can load anything else on to the board under pain of death. However I would like to be forced into tagging what is safe to run SMT else I get stuck on the safer cores.

    I might be an intern who has no idea what any of this stuff means and goes to Google it, then learn what this attack vector truly is. Then makes a plan on how to defend against it.

    Am I crazy?

  • by brundolf on 8/9/23, 5:20 AM

    Speculative execution seems like a never-ending rabbit hole of vulnerabilities. Though I feel like most of them end up being in Intel chips for some reason

  • by baq on 8/8/23, 6:12 PM

    > [Q] Should other processor vendors and designers be concerned?

    > [A] Other processors have shared SRAM memory inside the core, such as hardware register files and fill buffers. Manufacturers must design shared memory units with extra care to prevent data from leaking across different security domains and invest more in security validation and testing.

    Not sure what to make of this wording. Thinly veiled threat? Hint that other embargoes are in place?

  • by ngneer on 8/8/23, 7:45 PM

    I do not doubt the severity of the flaw, but most practical attacks end up being far more mundane. Consider SolarWinds, for example. No dazzling tricks needed, whatever gets the job done.

  • by sholladay on 8/9/23, 5:07 AM

    It feels like chipmakers never learned to "Make it work, make it right, make it fast", in that order. But then, hindsight is 20/20.

    How much slower would processors be if they got rid of all complex / risky optimizations? How much performance could we gain back with more expensive components, more integration (e.g. SoCs), and other approaches that are unlikely to lead to security problems?

  • by ancris on 8/8/23, 8:53 PM

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

  • by errantmind on 8/8/23, 9:14 PM

    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.

  • by aestetix on 8/8/23, 6:40 PM

    I just did a cursory readthrough. Am I correct to think this feels a bit like heartbleed, but for CPU registers rather than memory?

  • by entriesfull on 8/9/23, 7:00 AM

    So this is literally the same thing as AMD's Zenbleed vulnerability? Ridiculous how these companies make so much money and are completely incompetent at handling security.

    Theoretically, this can be mitigated permanently by disabling hyper-threading?

  • by samwillis on 8/8/23, 6:01 PM

    Ouch, I wander if they received a bug bounty from Intel for this...

  • by tomrod on 8/8/23, 5:47 PM

    Geez! This seems like a _really_ big attack vector. Anyone on the security side have some caveats?

  • by GartzenDeHaes on 8/8/23, 6:53 PM

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

  • by throwaway892238 on 8/8/23, 6:36 PM

    This is one of many similar previous attacks, and more of these attacks will continue to come out and be increasingly weaponized. From now on the assumption must be that same-core computing is not secure.

  • by Veserv on 8/8/23, 7:17 PM

    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.

  • by Aaronmacaron on 8/8/23, 10:28 PM

    Are there any known attacks which exploited Spectre or Meltdown vulnerabilities? And is it likely that this vulnerability will be successfully used to perform attacks?

  • by nwmcsween on 8/8/23, 6:07 PM

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

  • by tamimio on 8/8/23, 10:40 PM

    So my CPU from 2015 (CPUID 306C3)

    - Is not affected

    - Doesn’t support Win11

    And both are good to know.

  • by isoprophlex on 8/9/23, 6:11 AM

    I guess Moore's law isn't exactly dead, but it doesn't seem to be alive either... Moore's law is undead?

  • by thewataccount on 8/8/23, 6:20 PM

    Does anyone know what type of workloads this effects the performance of the most? Is this specialty-type of workloads or are general webserver/database/coding/compiling/gaming/desktop usages effected?

  • by basedrum on 8/8/23, 10:38 PM

    Can someone explain why the ssh video at 2:25, where the 256bit comparison is pasted in, it doesn't match? The first two colon separated number sets do match, but not the following two?

  • by xyst on 8/8/23, 10:32 PM

    So it seems like speculative execution cannot be disabled. What’s the mitigation here? Nothing and wait for patch or significant redesign?

  • by bruce343434 on 8/8/23, 6:29 PM

    Is there an overview page of all these processor data leak bugs the last 10 years? It feels like there has been an enormous surge in them.

  • by coding123 on 8/8/23, 10:45 PM

    I guess 1995 is calling when computers were expensive.

  • by Dalewyn on 8/8/23, 9:01 PM

    Am I correct in understanding this affects basically every CPU generation up to and including Alder Lake?

    EDIT: Maybe not? That linked table is very esoteric.

  • by EGreg on 8/8/23, 8:42 PM

    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

  • by lefuturiste on 8/8/23, 10:17 PM

    As I see, there is no debian security release yet?

  • by SomeoneFromCA on 8/9/23, 1:22 PM

    Similar to Zenbleed judging by description.

  • by yakkityyak on 8/8/23, 6:08 PM

    Not again!

  • by snvzz on 8/8/23, 10:33 PM

    ISA complexity breeds microarchitecture bugs.

    In the internet era, x86 is an anachronism.

    RISC is the way forward.

    RISC-V is inevitable.

  • by stalfosknight on 8/8/23, 6:05 PM

    I'm getting annoyed with all of these yawning security holes in Intel's CPUs. I'm tempted to replace my Intel MacBook Pro with an Apple Silicon model sooner than I normally would.

  • by galacticaactual on 8/8/23, 6:05 PM

    Stop. Releasing. Attack research. Without. Detection strategies.