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.<p>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.<p>Outside researches need to reverse all this by probing a black box (plus a few much-worse-than-insider sources like patents).<p>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"?<p>Maybe they <i>did</i> 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?
The Intel paper link is dead, this seems to be the right one:<p><a href="https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/gather-data-sampling.html?wapkw=gather%20data%20sampling" rel="nofollow noreferrer">https://www.intel.com/content/www/us/en/developer/articles/t...</a><p>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?)<p>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).
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.<p>There are really only two common cases for this anyway. VMs and JavaScript.<p>For VMs we just need to give up on it. Dedicate specific cores to specific VMs or at least customers.<p>For JavaScript it’s a bit harder.<p>Either way, we need to not be giving up performance for the the normal case.
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?<p>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.
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.<p>Amazing how these vulnerabilities sit around unnoticed for years and then it takes two weeks for someone to code up an exploit.
See this LWN story: <a href="https://lwn.net/Articles/940783/" rel="nofollow noreferrer">https://lwn.net/Articles/940783/</a><p>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..
Worth to note that GCP has this patched (<a href="https://cloud.google.com/support/bulletins#gcp-2023-024" rel="nofollow noreferrer">https://cloud.google.com/support/bulletins#gcp-2023-024</a>)
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).<p>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?<p>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.<p>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.<p>Am I crazy?
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
> [Q] Should other processor vendors and designers be concerned?<p>> [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.<p>Not sure what to make of this wording. Thinly veiled threat? Hint that other embargoes are in place?
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.
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.<p>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?
The Linux mitigation can be disabled with gather_data_sampling=off in the kernel boot parameters.<p>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.
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.<p>Theoretically, this can be mitigated permanently by disabling hyper-threading?
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.
I am a little unclear on the attack. What data in the temporal buffer is being forwarded to the attacking vpgather?<p>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?<p>Otherwise how is the speculative vpgather allowed to load the values of the temporal buffer?<p>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.<p>If it is a blind forward that is pretty amazingly bad.
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?
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?
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?
Am I correct in understanding this affects basically every CPU generation up to and including Alder Lake?<p>EDIT: Maybe not? That linked table is very esoteric.
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.