Intel and AMD have CPU meltdown as two major security flaws are blown open

Total Recall

No one likes going back to work after Christmas. The early mornings, the ever-disappointing trains and having to deal with hordes of perpetually grumpy commuters… it all sucks. But just imagine coming back to the office only to discover that the things you make and sell to people all across the globe and form the basis of every PC in the known world have a major security flaw that you can’t really fix. And some of the fixes you can implement may put a serious dent in your PC’s performance.

That’s what happened to the CPU industry this week, and I can only imagine a lot of Intel, AMD and ARM execs are pulling what I’m going to call the ‘Total Recall Arnie scream’ this very moment. Happy New Year!

So what’s this CPU problem all about and what does it mean for you? Well, put simply, it turns out that researchers and security experts have discovered two really quite major flaws in almost every CPU around today. One has been reassuringly dubbed ‘Meltdown’, while the other is being called ‘Spectre’, and both allow hackers to get their mitts on a computer’s entire memory contents, be it passwords, log-ins or other important personal data stuff. It’s not just PCs that are affected either, as the flaw also extends to mobile devices and servers that run various cloud services.

Right now, the Meltdown problem has only been found in Intel chips (plus ARM’s Cortex-A75 mobile processors), but according to The Register, who first broke the news, it might potentially affect all high-performance Intel processors since 1995. That’s a lot of CPUs. Even worse, every x86-64 Intel CPU since 2011 is definitely affected. The only ones that might be safe are Itanium processors and pre-2013 Atom chips.

The New York Times has a pretty comprehensive run-down of how Meltdown actually works, but the good news is that there’s already a Windows software patch that’s available right now. If you haven’t already downloaded it, you probably should. Linux users can also fix it with the following instructions, while Apple’s MacOS should have been patched with update 10.13.2.

The bad news? Said software patch will apparently slow down your CPU’s performance by as much as 30%, which rather takes the shine off those fancy new Coffee Lake chips. Intel, of course, claims this figure is being exaggerated, saying the performance impact will be “work-load dependent” and “should not be significant”, but until I get some benchmarks running it will be difficult to just how much of a hit we can expect to see.

It only gets worse, too, as anyone thinking about jumping ship to AMD to try and evade Meltdown still won’t escape the shadow of Spectre, which has been found in virtually all types of processor, AMD included. Spectre is much trickier to fix, and there’s currently no known solution. As far as we understand it, it might even require an entire redesign of the whole CPU architecture as we currently know it and/or, you guessed it, a total recall of all affected chips. As such, this could be an issue that sticks with us for many more years to come, according to another NY Times reporter.

In truth, CPU companies have known about these threats for a while. The problem was first outed by Google’s Project Zero research last June (the exact findings of which have been published this morning) , and was going to be officially announced next week – presumably so that fixes would be readily available at the same time so people wouldn’t freak out like Arnie up the top there. Only The Register decided to leak it yesterday, no doubt to probably cause a bit of a stink just before the Las Vegas tech fest that is CES begins on Sunday, hence all the panic and commotion happening right now.

Fortunately, there’s been no evidence so far to suggest anyone’s actually taken advantage of these flaws to steal any of our precious data, according to the BBC, who spoke with the UK’s National Cyber Security Centre, but how long that will remain the case is anyone’s guess now it’s all out in the open.

In the meantime, my advice would be to get that security update sorted for Meltdown and hang tight. There’s still a lot we don’t know about these flaws, mostly because the news of their existence has been rushed out ahead of time, and we’ll need some time for the dust to settle before anyone knows how to tackle the truly James Bond villain-sized problem of Spectre.


  1. FurryLippedSquid says:

    And the CEO of Intel, Brian Krzanich, sold $24 million of his Intel stock in October, three months before the flaws were made public but four months after he was aware of them.

    Make of that what you will.

    link to

    • Meat Circus says:

      I make fraud of that, wbu?

      • AngoraFish says:

        Fraud? Hard to see how. Insider trading on the other hand…

        • Premium User Badge

          subdog says:

          Insider trading is by definition a form of securities fraud.

    • Dewal says:

      I think everyone make fraud of that, but it may be hard to prove.

    • A Gentleman and a Taffer says:

      Insider Trading would be the crime, if it’s provable he sold the shares based on knowledge he held as CEO that wasn’t publically available then yeah, guilty. In the UK he’d probably get away with it but the US are pleasingly strict on that stuff.

      But if this Project Zero stuff was available to the public (even if not widely publicised) then he’s not really done any wrong.

  2. dwm says:

    The Linux update instructions above aren’t super-helpful for a mere-mortal user; for those running distributions like Debian, Ubuntu, or Arch, the advice I would offer is to wait for your distribution to package up a kernel that includes the KAISER, aka. KPTI security workaround, and install it as a standard update when it becomes available.

    At time of writing, Debian don’t have packages yet:
    link to

    Neither do Ubuntu. Arch, however, does:
    link to

    • DrMcCoy says:

      The Linux instructions are also bogus for immortals, because they’re outdated. Instead of pulling random patches into an old kernel, update to the kernel 4.14.11, which was released on Tuesday. That kernel includes the KPTI (aka KAISER) patch.

      However, there’s an issue with the nvidia binary blob drivers: they won’t compile for a 4.14.11 kernel with CONFIG_PAGE_TABLE_ISOLATION turned on, because one of the symbols has been marked GPL-only (and the nvidia kernel module is decidedly not GPL). A hacky workaround is to either modify the kernel so that the symbol is not marked GPL, or the nvidia kernel module to be GPL. Of course, no distribution can officially endorse that workaround, for legal reason.

  3. Czrly says:

    To be fair to The Register, Intel officially knew about this since last June — almost certainly they knew earlier, off the record — but they still had half a year to release a fix on their own time. During that half year, all of us were vulnerable and they sat on their hands.

    In my opinion, The Register did not act unfairly.

    One can speculate on reasons but I cannot imagine that dev. time, alone, was the cause of the delay. Patches started appearing late last year, even in bleeding-edge Windows editions!

    Personally, I think they sat on their hands because they knew AMD had yet to release Ryzen. If they had come clean at the same time as the AMD launch, the effects would have crippled them. Personally, I know I wouldn’t have chosen the i7 7700K that I ended up with.

    And, in hindsight, with all the thermal issues I am having, the recent Intel Management Engine hacks and, now, this, I’m damn sad I chose that i7. I’m properly pissed, to be honest.

    • Excors says:

      I think The Register didn’t leak it anyway, they just collected information and speculation that was already public. The Linux patches have been visible since months ago, where it was observed that they were being pushed with unusual urgency that suggested a serious security issue, and more details gradually came out over the past few days.

      It’s not a problem that Intel can realistically fix, so the embargo isn’t really for them. It’s up to the OS developers to develop workarounds in communication with Intel, AMD, ARM, etc, to make sure it’s the right fix, plus people like Amazon and Google to make sure their cloud servers are patched before the exploits become public, Linux distributors, etc. Long embargoes are perfectly normal to make sure all those parties have enough time to develop and thoroughly test the solution (especially a very tricky one like this that makes substantial changes to the virtual memory system and syscall mechanism, with a significant performance impact), and can deploy it simultaneously, to minimise the time in which previously-unaware attackers can learn about and exploit it.

      Plus it takes a while to come up with scary names and cute logos, which is apparently the best way to ensure public awareness of major security issues.

      • Cederic says:

        Yeah, “leading computer tech news site on the planet finds out biggest tech news of the decade and shares it with audience” isn’t exactly a leak.

        I will say though that Katharine’s put together a very solid summary here – good sources, good description for a non-technical audience and a nice validation that we can trust her on hardware.

        Not that I distrusted her, I just haven’t read enough of her work yet to know her preferences and how they influence her work.

    • Premium User Badge

      MajorLag says:

      Intel couldn’t release a fix because there is no fix that they can implement. The only workaround for Meltdown is to implement additional steps in the OS when switching contexts during syscalls.

      Unfortunately, this means every syscall will take a performance hit, but syscalls are already a performance sticking point and avoided as much as possible in highly performant code.

      The upshot? Gaming won’t see much, if any, performance degradation, VMs will see a little, and Databases will suffer the most though tests by Phoronix, at least, don’t back up the alarmist 30%.

      Spectre, on the other hand, is an architectural problem affecting pretty much every processor released in the past 20 years, and can’t even be worked around in the OS. There is literally no fix for it. Future processors will need to be re-architectured. The only mitigation possible is at the application level, for instance Chrome has “strict site isolation” that should help.

      To clarify the impact of these vulnerabilities, as I understand them:

      Meltdown only appears to affect Intel processors thus far, and allows for arbitrary reads of kernel memory. Basically, javascript in a web browser could read private keys and passwords from the OS. More relevantly, it allows for one VM on a host to read memory from any other VM on that host, which makes cloud computing suddenly extremely dangerous. If my website’s VM is running on the same hardware as a credit card processor, for instance, I could read credit card numbers out of the processor’s site’s memory.

      Spectre allows for arbitrary reads of process memory, meaning javascript in a web browser could read private keys and passwords out of your browser’s memory, but not the OS. This is a big problem for Desktop users because it means that any old site on the internet could potentially steal accounts, credit card numbers, etc, that happen to be being or have been used in the same browser session. Chrome has “strict site isolation” in chrome://flags/#enable-site-per-process to mitigate this, which IIRC will become the default in a near future chrome update.

      Basically, we just threw 20 years of mainstream IT security assumptions out the Window.

      • DanMan says:

        > Intel couldn’t release a fix because there is no fix that they can implement. The only workaround for Meltdown is to implement additional steps in the OS when switching contexts during syscalls.

        Linux is open source, so they certainly could implement fixes, if they wanted to.

        • Malcolm says:

          I think you are rather understating the difficulty implementing the fix. I can almost guarantee that intel has been involved in the design and development of the linux (and Windows, macOS) patches but it’s not exactly something they could drop in overnight.

          To provide some flavour, noted Windows Internal guru Alex Ionescu had this to say:

          “This patch literally invents new computer science to work around the side-channel CPU issues. Continuing to be in awe and massive kudos to all the OS vendors who had to probably re-do entire feature roadmaps to handle this work.”

        • demonspeedster says:

          The linux patch is indeed being worked on by Intel engineers, but this isn’t something that processor vendors usually do. Most of the time they will work on microcodes that motherboard vendors then will integrate to their bios. But Meltdown is so severe that no amount of microcode changes can patch it

      • Morte66 says:

        Thanks for posting that. I applied the fixes and set Chrome (which happens to be my usual browser) to strict site isolation.

        As it happens, I bought a new CPU/mobo/RAM/cooler last week and I have been doing lots of video testing, tweaking threads and memory pools and so on to optimise it all on the new CPU. So I have lots of careful benchmarks.

        After applying the patches today, on an Avisynth/x264 test I noticed a performance difference of: zero (measured to three significant figures). Yes, I checked very hard that I had applied the patches.

      • Monggerel says:

        “… it means that any old site on the internet could potentially steal accounts, credit card numbers, etc, that happen to be being or have been used in the same browser session.”

        Well laa-dee-fucking-dah. Now all my many years of paranoid care to memorize everything and never, *ever* allow a browser to save anything, or to only *ever* log in to a single site on one session and then only use that site and no other and log out and start a new session are… substantiated?

        I guess a paranoid really is just someone in posession of all the facts. Even if they don’t know they have the facts.

        • poliovaccine says:

          I believe the quote is, “a paranoid is one who knows a little of what’s going on, while a psychotic is one who’s got all the facts.” But we may be referencing different things here, haha.

      • Benitoxine says:

        As I understand it, for these two exploits to work you would need first to execute code in the computer.

        For cloud servers, this would mean having a VM executing code in the same cloud server. So you cannot trust VM data isolation anymore…

        For personal computers this would mean executing as part of a virus (using the usual means: fishing, executing an attachment or exploiting another vulnerability)

        Simply executing JavaScript in a browser would not be enough (unless you exploit a JavaScript vulnerability to execute real code)

        Still, very nasty stuff.

        • Movac says:

          Bad news: you don’t understand it. The Spectre paper makes it clear that it’s exploitable from JavaScript without any additional vulnerabilities. It includes a proof-of-concept that runs in Chrome and reads private memory from the browser process. Browser developers are working on mitigations, but the word in the security community is that Spectre can be used to break the same-origin policy, which is the foundation of all web security. This is A Dang Mess.

    • Merus says:

      To be fair to The Register, Intel officially knew about this since last June — almost certainly they knew earlier, off the record — but they still had half a year to release a fix on their own time. During that half year, all of us were vulnerable and they sat on their hands.

      In my opinion, The Register did not act unfairly.

      This is pretty ignorant, honestly. Project Zero doesn’t care about Intel’s product launches; they famously have a strict 90-day disclosure window that they extended here for the first time. While Intel is negligent, it’s the kind of negligence you and every other consumer demanded: they sacrificed security for performance, and if they didn’t, another vendor would have, they would have won the speed benchmarks, and you would have bought their chip instead. And finally, you weren’t vulnerable, because to be vulnerable, someone needs to know how to exploit the bug before patches are available. If your definition of ‘vulnerable’ involves ‘there’s a bug in my computer, whether or not anyone knows how to use it’, you might as well swap to pencil and paper because all software of sufficient complexity has a bug somewhere.

      It’s time to calm down, and wait. We’re in uncharted territory here.

      • Czrly says:

        Hold on a moment! I didn’t ask for this?

        If they hadn’t sacrificed security for performance they would have been equal to the competition, at worst. And we’d have some competition in the processor market and stuff like this simply wouldn’t fly.

        AMD’s processors do not suffer from this “meltdown” problem — by far the most worrying of the two because it can be easily exploited.

        Your post just reinforces my idea that Intel stayed quiet about this so that they would keep their edge on the competition: performance over security, what you don’t know… and all that.

        Even if you consider that to be fair plays (I don’t, but you’re entitled to your opinion.) they still had half a year to patch OSes and to mitigate the impact of the problem. There’s no way a problem like this should remain under wraps for more than that amount of time.

        Remember, there were people who knew about this since June, last year. Were they all benevolent? You cannot assume so.

  4. Excors says:

    It seems unlikely there will be a big performance impact on games, though it would be nice to get good benchmarks for that. The workaround for Meltdown slows down the transitions between application code and operating system kernel code, which is bad for applications that e.g. spend most of their time asking the OS to read files, but it has no effect on pure number-crunching code (which games do a lot of) and probably very little on graphics code (which usually sends a big batch of commands to the OS at once, it doesn’t keep jumping back and forth).

    It seems there’s less urgency around Spectre because it’s much harder to exploit usefully, but also basically impossible to fix properly without massive CPU architecture design changes, so the OSes will just try to add some more mitigations to make it a bit harder to exploit.

    (The problem with Meltdown is essentially that an application can read memory it’s not allowed to access, and (because of all the fancy optimisations that make modern CPUs fast) the CPU might not actually notice that it wasn’t allowed until a few dozen nanoseconds later, and then the CPU will try to undo everything that happened since the forbidden read. But it doesn’t actually undo *everything* – there are a few subtle ways to smuggle information out, which means an attacker can determine the contents of memory they shouldn’t have been able to read, and that memory might contain things like passwords.)

    • PseudoKnight says:

      As for game performance impact, some early reports see almost no impact with the newest CPUs, but I did see one showing around 4% average decrease in FPS (one outlier of 13%) for an i5-4690k OC @ 4.4GHz. This may indicate that “older” CPUs or some aspect to this older CPU will have a harder time with this patch. More data is necessary.

    • FelisCatus says:

      Spectre might be tougher to exploit right now but the educated thinking is Spectre will allow things like Sandbox breakouts (see Java sandboxes in specific) which means web browsers (even with KASLR) are going to be considered insecure from this point forward.

      The quote from the SANS web seminar that stuck with me is that Spectre will “usher in a new age of practical web browser exploits” that can be run remotely.

      Happy days to come.

  5. shaydeeadi says:

    The Linux benches I saw showed negligible impact on gaming, from what I read yesterday it will be a much bigger deal for Cloud/servers and tasks like compiling. So as far as gaming goes it might not be that big of a deal. Personally I’m more worried about how VST type performance holds up but I won’t find out until later really.

    link to – Benches in question

  6. frymaster says:

    “Only The Register decided to leak it yesterday”

    They reported on previously-published speculation that was – by the time they wrote their article – already in wide circulation

    Certainly at work I was sending people to El Reg because it was a good summary of what I’d already seen, not because it was a primary source

  7. Kefren says:

    Weirdly, I was thinking about Intel recently – I got a new laptop which had all sorts of Intel processes running. When I looked into whether they could be safely disabled, I found a whole morass where Intel refused to say what any of the processes did or why they had added them to your PC without permission or information. Worse, many people speculated that they were related to DRM and the ability to shut down content or remove things at a distance (hence their silence). It all seemed dodgy and underhand, and I started to hate Intel that little bit more, and wondered whether this kind of crap opened all sorts of security holes in our PCs. Turns out I was partly right as well, even if the revelations aren’t related to the DRM/spyware stuff they add.

    On the plus side – I disabled every Intel process and set it so they wouldn’t run on startup. No noticeable effect, no errors or problems or slowdown. Until companies are open and honest about the crap they try to install, I’ll continue with this approach.

    • Premium User Badge

      phuzz says:

      The Intel ME stuff, well, they did say what they were adding and why, they just didn’t release the source code.
      It’s a management processor, a separate chip, for doing things to PCs without having to have a working OS, which is super handy for big companies, you can just schedule a whole office full of PCs to reboot and install patches, but of no use to us home users.
      It’s entirely separate from today’s issue, which is effectively a flaw in the way their CPUs (and everyone else’s to a certain extent) deal with branches in code (If..THEN type stuff), and there’s no way to fix it without physically altering the design of the CPU.

      As for making sure none of the Intel programs are running in Windows, that won’t impact either the ME or these new bugs. If you manage to disable Intel drivers though, your computer will probably run worse.

  8. Stargazer86 says:

    Well, I’m glad this came out before I decided to buy a new PC. I had been looking at picking up Intel’s new Coffee Lake chips but now I don’t really know what to do. All of Intel’s stuff is affected by one issue yet AMD’s seem to be affected by another as well.

    • Ravenine says:

      Intel is affected by both, AMD is affected by only one, and is cheaper. Do with that what you will.

    • elvirais says:

      I switched after ten years of Intel. Very happy with my AMD Ryzen 1600X (got a great deal too).

  9. aepervius says:

    Knowing how the exploit works (basically you ask to read a specific memory point you should not be allowed to read, then use that as an indirect pointer to check a memory of a big array you set in memory, then check read speed of reading particular bytes of array, the byte value of the memory you just read is the one for which you get the lowest speed access for that 4096 byte memory block : it was in the cache, the other not they were not in cache – for those knowing assembler : it is as easy as a mov al,memory then shift left eax 12 bits, then read memory from indirect inference+index of eax. Then scan and measure access time of the array blocks. Just make sure all blocks are separated by 4096 bytes. That could be slapped in 5 minutes by anybody knowing a bit of asm. There is already a javascript exploit apparently) I can also see way of making it works to read any arbitrary points of memory not only the kernel, meaning any copy protection which relies on having the key with the client could be broken, password stolen etc…

    I forsee new classes of malware.

  10. obowersa says:

    A bit of a ramble on the exploits.

    Firstly we need to breakdown the vulnerabilities into three components, Spectre 1, Spectre 2 and Meltdown. I’ll go into a bit on what’s happening with each one, and what the scope is:

    Spectre-1 is a bounds-check bypass. This is the vulnerability with the least significant impact as it requires the ability to inject code into a process which has access to the memory you want to read. Generally speaking if you’re at that point, you can already just inject code to read the data without needing to use the exploit.

    Anyhow, Spectre-1 relies on using speculative execution to load data out bounds from a bounds-checked array. Once you’ve done this the data remains hidden from the program, but can be accessed through chaining together additional speculative execution tasks and then making use of cache-timing effects to extract the data. However, as said, the data still has to be legitimately readable by the original process.

    Pretty much everything made in the last however many years.
    This one’s a bit scarier as it allows a process user-space to access data from another processes privileged address space. In essence, this is a branch target injection attack and relies on a couple of neat tricks. Firstly you convince the CPU to mispredict an indirect branch and speculatively execute you’re payload code. The code which gets executed then has access to data which the process which executed the initial branch can access. Once done you can use the same techniques in Spectre-1 to get at the data.

    This one is particularly cool because when the CPU returns to the correct branch, execution keeps on going as if nothing had happened. The only restriction on this attack is that it must be executed from the same core as the process you want to compromise the data off as both processes need to share the same branch target buffer.

    Little more complex. Technically both Intel and AMD are vulnerable. However, Intel is more exploitable at this time. In essence Intel creates aliases for it’s branch target buffer in a predictable way, where as AMD doesn’t create any aliases at all. As suc you’d first need an exploit which could discover those addresses on AMD before you could then continue with the Spectre-2 attack.

    Wow. This is a beauty. A rogue data cache load attack which, while it can be patched, comes with a significant performance degradation. It’s also worth mentioning that there’s already a POC of this which can run from sandboxed javascript code.

    This exploit relies on the fact that certain instructions in Intel CPU’s are executed before being checked through speculative execution. This attack works by asking the CPU to speculatively load data which is in the L1 data cache, but has been unmapped and is marked as unreadable in the systems page tables. This will generally happen after a syscall has executed in order to help with performance. In essence this attack allows a process in userspace to read privildged data which another process has requested and left in the page-tables. Because of the way Intel’s speculative execution works, the check for the data being unprivildged in page tables never happens and the data is returned to the process.
    At present it seems tht this /only/ impacts Intel as Intel doesnt check the security flags when doing an L1 data cache load for speculatively executed requests. This is also what the security fixes coming are for. Essentially the security fixes will fully unmap privilidged addresses instead of just marking them as inaccessible. There is a big overhead for this though with anything which relies on that mechanism

    • Ragnar says:

      While I appreciate you taking the time to write this up, your write up is less “Explain it like I’m 5” and more “Explain it like I’m a cyber security specialist.” I used to work in IT as an IT manager / system & network administrator, and even I’m having difficulty understanding everything that you wrote. :)

      • pipja says:

        I’m just some noob code monkeh but I understood quite a lot of what he explained. Much better than a lot of others who tried.

      • Chaoslord AJ says:

        On the other hand why would he. There are a lot of articles by “tech journalists” out there who explain it like their audience was five…
        It’s better to challenge people to think hard than to ease them.

      • obowersa says:

        That’s fair!

        Wasn’t really going for an explain it like I’m five, was just having a bit of a ramble.

        In all seriousness though, as an attempt to give a more readable explanation for what a speculative execution attack is and how the timing works, which is the foundation for a lot of what is going on with these exploits. This might also be a bit of a gross oversimplification and get a few bits wrong.

        Let’s say you’re at work and want to access some restricted file. In order to access the file you need to go through a receptionist. The receptionist will get the file for you, but will also call upstairs to the boss in order to make sure you’re meant to have access to the file.

        Now, the receptionist knows that getting permission can take a bit of time so in attempt to be more efficient, they’ll fire a message up stairs and then before they’ve got a response back, go grab the file and put it in a draw next to their desk.

        At this point the call comes back from upstairs and they’ve said you can’t read the file . The first thing she does is tell you no and takes the piece of paper and throws it in the bin. At this point though the file is still in the desk in case someone else needs it or you get permission and are to be granted access to it.

        At this point, you ask the secretary if they could quickly check if they have a stapler. This is all cool but the stapler sits in the same drawer as the file. While the drawer is open, you take a quick photo of the file while they’re not looking and you’re on your way.

        Admittedly this example skips over a lot of details. You don’t actually know for certain which drawer the folders in ( there’s two drawers ) or if they’ve actually left it in the drawer. You can use your eyes ( variables ) to guess the former and use how long it takes her to check the permission and get the folder (if all they do is quickly check their desk and then don’t go to the file vault you know it’s in the drawer. ) Also, instead of an entire file we’re talking about a single value at an address and would need to repeat this process multiple times to get the full data we need.

        With that said I think it kind of explains the crux of the issue. The permission check happens out of order from the getting the data you want and it’s possible to use this in combination with the receptionists efficiency and laziness and a final side channel in order to get data you shouldn’t have permission for.

      • Person of Interest says:

        I’m a software developer who enjoys reading about exploits, and this summary was perfect for me, as I was struggling a bit with the Project Zero article’s details. Thanks obowersa for writing it up. This is better than anything I’ve seen on the tech forums or Reddit, in fact. Score another point for the RPS comments section.

    • obowersa says:

      A bit of a clarification I forgot to mention as I was writing this on a lunch break.

      The check does technically happen, but by this point the data has already been read by the speculative execution. When the check fails, the execution is rolled back, but the data left on the cache. You can then use some trickery to get at that.

  11. Chaoslord AJ says:

    Similar to the Daimler emission scandal where the fix was to lower the power of the car via software they should just be ruled to pay their customers 10% of the price back because they can’t deliver the processing power as advertised when I bought the chip.
    I’ll also take a discount for the next (fixed) processor model.

    Unfortunately noone cares about customer rights as they dance around the golden calf. Even the customers are a bunch of servile fanboys usually (esp. in gaming).

    • Excors says:

      The CPU can still run exactly as many instructions per second as it was advertised to, so I don’t think you can really make that claim.

      The problem is that the operating systems now have to spend more of those instructions on faffing around with security stuff instead of doing actually useful work. But the CPU is faffing as fast as it’s meant to.

      • Premium User Badge

        syllopsium says:

        As a home user you may have difficulty making a claim, and probably won’t notice the difference (if there is any).

        On the other hand, if you’ve bought a branded server advertised as being capable of processing n IOPS of database performance and it now can’t do that..

  12. Premium User Badge

    syllopsium says:

    There’s compiler patches on the way so that future applications/operating systems can be protected against one of the Spectre issues. So far it seems the largest real world performance degradation is with databases and web servers, averaging a 10-12% slow down.

    All the benchmarks so far show games to be unaffected.

    It’s going to be a huge pain in the neck, but isn’t quite the ‘sky is falling’ fear some people initially had. Good thing too, I can live with losing 10% performance on my new (old) dual Xeon system, but I’d rather not spring for an entirely new system, or use a PowerMac I’ve got lying around as a main machine..

  13. Hypocee says:

    It really is a coincidence that this has become a theme recently, but seriously. NoScript, I love you. Why you would let every Web page in the world execute arbitrary code, I’ll never know.

  14. Slazia says:

    Disable JavaScript by default for all websites and only allow it for websites you trust. This would be a start.

    • Premium User Badge

      MajorLag says:

      Great in theory, in practice the vast majority of the web will not function at all without a whole lot of javascript from other domains, making the whitelisting tedious and error prone.

      The Web is a horrible garbage fire of a platform, but it makes a lot of people a lot of money so don’t expect it to get better any time soon.

      • Cian says:

        I’m sure this is true for many, but I’m unconvinced that it’s really that difficult. I know a lot of people who can’t be fucked allowing and disabling each individual tracker/site but will “temporarily allow all”.

        This might seem like you’d face the same risk, but only when using the occasional website that requires it – which in my experience is far more often the likes of social media and newspaper websites. If those sites are pushing malware then there’s a whole lot more people in trouble.

  15. mercyRPG says:

    These are mandatory CIA and NSA exploits, nothing new.