Return to

Another BIG Intel-specific FUBAR: "SPOILER" speculative memory subsystem vulnerability


Spoiler is not a Spectre attack. The root cause for Spoiler is a weakness in the address speculation of Intel’s proprietary implementation of the memory subsystem which directly leaks timing behavior due to physical address conflicts. Existing spectre mitigations would therefore not interfere with Spoiler.

The leakage can be exploited by a limited set of instructions, which is visible in all Intel generations starting from the 1st generation of Intel Core processors, independent of the OS and also works from within virtual machines and sandboxed environments.

The root cause of the issue is that the memory operations execute speculatively and the processor resolves the dependency when the full physical address bits are available. Physical address bits are security sensitive information and if they are available to user space, it elevates the user to perform other micro architectural attacks.

This is a Intel specific vulnerability in their proprietary memory subsystem. So like Meltdown and L1TF, Intel gets hit with yet another speculative vulnerability specific to them.



They use fucking web assembly lmao. That’s awesome.

Your headline is a bit misleading, and click baitey, though. Much like other speculation attacks, this is a bit tricky to pull off.




For some reason I’m hung up on the typo in the references where they put Jeffrey M Abramson name down as Jeffery M Abramson. I mean they corrected it down further but it is still there…



Looks like the future is in RISC. x86 is becoming a bitch to deal with. It’s overcomplicated, has support for so much legacy shit that’s insane. It’s like a Jenga tower that’s getting worse and worse over time.
I would switch, I love new techs and RISC has been my reference achitecture when I studied CPU architectures (so it holds sentimental value lol), but there’s really not much available for average consumers as far as I know (beside SBCs).



I’d switch to get something to do useful stuff on, ain’t got time to tinker with things unfortunately.

Still a +1 for me regarding RISC, but it’s not time yet.

1 Like


From a layman’s use case, no.

Unfortunately that legacy works both ways. Pretty much all the software that matters outside of the phone world is reliant on x86.

It is looking less and less stable recently but largely confined to Intel… Rather than adopt RISC wholesale, let’s just drop Intel as they are a steaming mess and the source of pretty much all of these problems. That accomplishes the same thing and does not require finding a way to run a half century of software on an entirely new platform. Just thinking of the most reasonable approach.

It would be a hell of a time having to drop back so greatly in performance. Keeping in mind that people still won’t take up AMD because they can get 5 extra fps with Intel. Imagine telling people they will have to drop entire gigahertz.



Sure, that’s a mid way step that can be taken. A more practical way to deal with this sort of stuff. But there’s also undeniable that vulnerabilities like Spectre and Meltdown are more rooted into the x86 as an architecture more than just a poor implementation by a manufacturer.

Also I think that the future will require a shift of the CPU architectures to get greater and greater performance from silicon.

1 Like





rey vs ery

1 Like


What troubles me the most is intel still has gotten no flak over this to actually change whatever the hell they are doing.

This actually worries me because everything is on the cloud nowadays, cost effective is cloud unfortenatly… so if you get hacked, you your application, your bank or netflix, you are screwed and you wont be able to pin on an intel flaw even if it was you cant really prove it.

Althouth these attacks are not easy, since when hacking is actually easy? and I’m not talking about script kiddies… if it is possible it will be done eventually.

1 Like


Yes, and more is being written every day, which is why it’s important to make this sort of change ASAP: less software to rewrite later.



I mean theres a reason apple is going custom risc asap guys



Unfortunately this part is not on us consumers but it’s up to the chip makers. AMD has already dabbled into making ARM processors (which is the most popular and supported RISC variation) so I guess they’re the best candidate to put forward this change, together with software houses.

1 Like


Maybe I’m in denial of being dyslexic… totally didn’t see that.

1 Like


I first read about this issue on Phoronix here:

I particularly noticed the claim that any software fix will come with a performance hit. This may just be me stupidly stating the obvious or misunderstanding the problem, but it seems that both AMD and Intel are taking shortcuts they maybe shouldn’t in pursuit of higher performance. Only Intel is possibly being a bit more aggressive with it (hence some of their IPC advantage over AMD) and that is why their CPUs seem more effected. This also means that both companies will probably not change their behavior because consumers are more interested in higher performance and thus we will have to continue living with vulnerabilities like this (both the ones that have been revealed and the ones yet to be discovered) for the foreseeable future.



And yet

None of this crap seems to matter to investors

Check their stock value over the last 5 years…

Ups and downs but generally trending upwards

All the security holes, abandoned road map after abandoned road map, giving up on the race to mobile.

And none of that seems to matter.

I give up on the stockmarket actually making sense.

Sorry for the slight tangent, it is related to the subject matter though

I think my biggest problem with the way things are headed is that we are effectively rewarding bad behaviour

All intel are learning from this is that they can get away with selling you vulnerable cpus for over a decade, with no consequence… promise a new architecture without those vulnerabilities and then sell you those cpus based around that for the next decade.

Stockholders are rubbing their hands together and smilling

Next bit is tinfoil hat…

If it was me… then i would intentionally bake some DIFFERENT vulnerabilities into the next meltdown/spectre proof architecture…

Just so i could get another decade of sales from the cpu’s that end up replacing them.

It takes so long for these things to come to light so it is not an unrealistic scenario.

1 Like


Maybe this is why investors aren’t tanking the stock.

More sales = more money



Which is what I was getting at and why I am concerned

We are rewarding bad behaviour, and all that does is encourage more bad behaviour



And tablets. There are a few x86-based tablets, but the vast majority of them use ARM CPUs. Speaking of which, ARM also has a presence in server land. And there are all kinds of CPUs in the embedded world.

I will grant you that it’s “all x86, all day” in the general consumer/business world, but it seems like most of that software could be broadly categorized into one of two groups:

  1. Software that is new enough that the people/companies who wrote it are probably still around and can port/recompile it for other architectures (or release the source so that somebody else can).
  2. Software that is old enough that it targeted hardware which could be emulated at a reasonable fraction of native speed on today’s hardware.

I’m sure there’s some that doesn’t fall into either category, but nothing major comes to mind.

And it’s not like there’s no precent for this. I was a mac user during both of Apple’s architecture transitions. They just shipped emulators for the old arch with their new computers, and as best as I can remember everything more or less just worked. The only catch I can recall is I think you couldn’t have plugins compiled for the old arch be hosted by an app compiled for the new arch… I think? There was definitely something like that. In any case, IIRC, it also ended up not really being a big deal.



Yeah, but it’s still quite a niche market. It’s not really widespread.

Embedded devices usually run on a Linux kernel and with custom software, I don’t think they count a user base for RISC processors. They even run just on custom software sometimes, if we’re talking about controllers.

You’re talking about simpler times, when the computer world was still evolving rapdily and softwares weren’t as complicated as they are now. For example porting an early version of Word for Windows 3.1 won’t be such a big deal compared to porting the whole Office 2016 (it’s the latest, right?) suite.

The most recent attempt was emulating x83 32 bit code for the Snapdragon 835. And those tablets that came equipped in that configuration had terrible performance compared to the same performance in other devices that support the CPU properly. For exaple Chrome HTML5 tests had half the performance on W10 for ARM compared to Android, and we all know the Chrome engine is unified. I don’t think it’s a feasible option due to the complexity of new techs.