back to article Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign

A fundamental design flaw in Intel's processor chips has forced a significant redesign of the Linux and Windows kernels to defang the chip-level security bug. Programmers are scrambling to overhaul the open-source Linux kernel's virtual memory system. Meanwhile, Microsoft is expected to publicly introduce the necessary changes …


  1. Anonymous Coward
    Anonymous Coward

    Intel are serious rubbish.

    Not only have I had to put up with the fact that Bluetooth does not function properly on all the Intel devices I have but now we are possibly going to lose 5 - 30% processing power? I want 20% refund. I think that's fair! I have always found Intel tech to be worse than AMD. And now, AMD lost the battle and we have to have Itel junk. People are so fickle to want to buy the fastest... Why don't you all learn we want the most reliable then the fastest!

  2. Anonymous Coward
    Anonymous Coward


    It's actually closer to 65%.

    1. Dan 55 Silver badge

      Re: 30%?

      du is basically syscalls in a loop which thrashes the disk and causes I/O interrupts (yet more paging). It's annoying when you want to run du but hardly representative.

      And grsecurity using du as a benchmark says more about grsecurity than the bug.

  3. Uffish

    American Technology

    When you look at the power and coverage of American technology you can easily understand how Americans were the first, and only, people to walk on the moon. When you look at American technology in detail you wonder how the hell they managed to get them all home again.

    1. Anonymous Coward
      Anonymous Coward

      Re: American Technology

      Don't take it so hard. You lot almost succeeded in getting a Reliant Robin Orbiter to separate from its main fuel tank.

  4. Alan Sharkey

    Why just now and will MS/Linux be intelligent?

    If the fix is just

    <If CPU=Intel, do this


    do that>

    Then any fixed CPUs (e.g. the i7-8xxx apparently) will not benefit from it at all. So, will MS/Linux etc. do the right thing and test properly?

    ALSO - if Intel knew about it when they were designing coffe-lake (I7-8xxx), then how come it's taken so long to get a patch in place? Surely the design was years ago.

    1. GreenReaper

      Re: Why just now and will MS/Linux be intelligent?

      They have been doing that, yes - the Meltdown stuff isn't applied to AMD at all. There's more that they could be doing w.r.t. PCID when INVPCID is not available (most 3xxx/4xxx/G32xx/G1xxx Intel chips), and maybe they will in due course, but it that's an optimization that can be done a little later.

  5. Anonymous Coward
    Anonymous Coward

    PR gone wild

    Intel's press release is a masterpiece.

    Translation: This critical security exploit that will be disclosed soon (though not by us, even though we've known about it forever) affects only systems that are working as designed (to leak sensitive data, presumably), running specific workloads (not general ones?), via a software analysis method that is definitely not a "bug" or "flaw" (it doesn't, like, delete your secrets or anything, it just gives them away). We are working tirelessly with companies like AMD to develop a fix (even though AMD's products are immune and they should be pissed we're mentioning them), and to roll out software and firmware updates that mitigate this definitely-not-a-bug-or-flaw. In conclusion, Intel believes that Intel's products are for sure totally the most secure.

    1. Dan 55 Silver badge

      Re: PR gone wild

      I do like the way they're throwing all the shit at the fan and seeing what sticks. In one paragraph they claim it's not confined to Intel and in the next they say they're working with other manufacturers which they go on to name. The insinuation is that every manufacturer has this problem.

      They probably thought about mentioning VIA who have just announced they're returning to x86 too but that'd be too obvious.

    2. misterinformed

      Re: PR gone wild

      > Intel's press release is a masterpiece.

      I think the word for it is "brazen".

      1. This post has been deleted by its author

  6. sisk Silver badge

    To be fair, it really doesn't take much for the word "fuckwit" to show up on the kernel mailing list, though granted it's usually Linus using it rather than one of the other devs. That's really not an indication of how severe this is or how annoying that particular group of devs found it.

  7. Anonymous Noel Coward

    According to a blog post by Google, there's another two different kinds of attack which AMD are vulnerable too...

  8. jchevali

    Bad journalism

    I'm disappointed of Reuters, Bloomberg, and others, for reproducing this piece of news uncritically, specially the 30% slowdown claim.

    While The Register has a very specific audience, and I'm sure among us everyone understands that a 30% slowdown for one application may mean nothing for others (and even a speed up), Reuters and Bloomberg, among others, should know better than to quote a 30% slowdown without saying it comes from a single PostgreSQL developer, running a very rudimentary speed test. And which % of apps that run on Intel chips fits reasonably well that description and that environment, so how could possibly that figure be authoritative? I'd say more: how could it possibly mean anything at all and be newsworthy?

    The Register's article's well within their own "flair" and kind of journalism and that's ok. But for others to quote it carelessly without double-checking with enough qualified experts (who may have to take time, perhaps months, to investigate the seriousness of this and the actual consequences, speed and otherwise) is irresponsible.

    I can only surmise the people responsible for airing this news at those other outlets are techies, and aren't better than the average The Register readership and not mindful of the consequences. In other words their job's too big for them. They should probably write for The Register and not for the global mainstream news. Ditto for the editor in charge of those outlets: allowing this to make front page news is IMO careless and irresponsible.

    The Register unscathed.

    1. Adrian 4 Silver badge

      Re: Bad journalism


      What you're forgetting here is that news agencies are more interested in a striking headline than a detailed or even correct explanation.

      1. jchevali

        Re: Bad journalism

        There: It took just two days to send the 'up to 30% slowdown' claim to where it belongs: the garbage can:

        1. Anonymous Coward
          Anonymous Coward

          Re: Bad journalism

          "Intel continues to believe that the performance impact of these updates is highly workload-dependent and, for the average computer user, should not be significant and will be mitigated over time."

          Don't they know?

  9. Ron Guilmette

    So what happens to my well-isolated single-user systems that only I have access to? Am I going to get UNIX, Linux, and Windoze auto-updates that will slow these systems down, dramatically, even though there may be no compelling need for that in the context of well-isolated single user systems?

    1. AdamWill

      It doesn't really matter that they're single user, since obvious attacks for something like this include root privilege escalation, and escape from isolation mechanisms like VMs and containers. And simply apps reading stuff from other apps which they're not supposed to be able to (like some Javascript in your browser being able to poke around anything else that happens to be running on your system).

  10. qwerty123123

    There are other OSs to consider as well

    Early indications shows that FreeBSD it is not affected by this bug. Stay tuned..

  11. Anonymous Coward
    Anonymous Coward


    Just an uneducated question: could this be an intentional NSA mandated back-door that was somehow outed?

  12. heroofonenation

    What about compensatio?

    WTF? What happens when an airbag manufacturer produces exploding mines that hit you in the face when you have a low speed prang? Do you just accept the performance penalty and drive at 10mph?

    Why hasn't anyone mentioned compensation? This isn't the only fuck up by intel? What about the great lock elison debacle on the first gen Bradwells and Haswells? We accepted that we had our processors crippled and now we have to take a performance hit as well?

    I say the chipzilla should pay. I believe 25% of list price for the processor is a decent compensation amount.

    1. Anonymous Coward
      Anonymous Coward

      Re: What about compensatio?

      Good point maybe they will end up in a class action, make a few lawyers ridiculously rich and the rest of us ... if we're lucky enough to have all the stuff most people throw out, proving we have said computer chip, still laying around. We can then submit those things and get a coupon for 50% off a Starbucks Coffee.

      In answering your question no the manufacturer goes bankrupt moves to another country changes their name and starts fresh. Of course all done legally with the money from decades of previous sales of the bad chip held in off shore accounts.

      Of course I might just be a pessimist :)

  13. Anonymous Coward
    Anonymous Coward

    I'm guessing I'm safe from infection if I don't browse websites right?

  14. Maelstorm Bronze badge

    A better question...

    A better question to ask is what other flaws has Intel been hiding from us? They apparently knew about this for awhile. Evidence from Linux sources show as much since July or so when the developers started working on the fix.

    Anyone remember the Pentium F00F bug? That's the one where any user in any operating mode can halt the processor in a denial of service attack. The only way to recover the system was to hit the big red button labeled 'RESET'.

    Or how about the FPU bug where six entries from a lookup table took a permanent vacation and screwed up floating point calculations? That one cost Intel USD $400,000,000 to fix.

    Intel's recent statement about other CPU vendors being vulnerable was pointed directly at ARM and AMD. ARM, to it's credit as stated that some of their chips have the problem as well. AMD has come out and flat said they are not vulnerable. It seems to me that Intel is trying to make others look bad (especially AMD) so they don't stink as much.

    1. AdamWill

      Re: A better question...

      "A better question to ask is what other flaws has Intel been hiding from us? They apparently knew about this for awhile. Evidence from Linux sources show as much since July or so when the developers started working on the fix."

      You, uh, realize this is how security *works*, right?

      When responsible researchers discover an issue they don't just immediately go and plaster it all over the press. They disclose it to other relevant parties, behind what's called an embargo, which basically means everyone agrees not to go and tell the press about it.

      Then all the relevant parties work together to come up with a comprehensive fix. *Then* they ship the fix and declare the vulnerability once everything is nicely lined up.

      If they *don't* do this you have a zero-day vuln - where the vuln is publicly disclosed, but no *fix* is yet available - which is a very bad thing. Embargoes and delayed disclosure exist precisely to prevent this happening.

      The reason this issue was still embargoed is that fixing/mitigating it is complex and requires co-ordination among many parties, because it can't just be conveniently fixed in one place. People were busy lining up comprehensive fixes to various OS kernels and to things like web browsers to try and prevent exploitation via malicious scripts.

      Whichever numpty went and prematurely blew the gaff to the press has caused a whole ugly mess, particularly since they didn't really do a very good job of explaining it, leading to lots of coverage which is confusing one specific exploit variant (that is Intel-only) with the entire class of potential exploits (which is certainly *not* Intel-only; weaponizable exploits are already known to exist for Intel, ARM, s390 and PPC CPUs, and for AMD CPUs with a non-default Linux kernel configuration, and it seems extremely naive to believe there won't be *more* along very soon).

  15. Luiz Abdala

    Stop the Presses...?

    Taking this to the automotive side and mixing the kernel-level table jokes:

    - Is Intel still selling CPUs with Takata airbags on them?

    - Now they will send you a new catalyst for your muffler that will cut up to 30% of the horsepower of your vehicle?

    - Nobody is suing VW for CPUs that had 30% extra horsepower, but polluted the environment?

  16. Anonymous Coward
    Anonymous Coward

    So about this 35% overhead for CPU usage...

    Will we see further patches over time which reduces this?


    1. AdamWill

      Most of the numbers you're seeing on this are wildly inflated and based on synthetic benchmarks that aren't at all representative of real-life workloads.

  17. Cobalt

    I came to piss you off. Have fun!

    Ryzen > Intel

  18. selangley

    More Info


    Helpful website explaining the issues by Graz University of Technology

    AMD's response to these issues:

    1. Dan 55 Silver badge

      Re: More Info

      Hurray, we've now got a logo.

  19. Kiers

    intel can dictate TERMS to open source s/w source code????

    " but comments in the source code have been redacted to obfuscate the issue" WHOA! What's this? Linux is FOSS! Someone maintains kernel code and intel tells them to redact comments written for clarity? is this possible?

  20. Anonymous Coward
    Anonymous Coward

    The page fault qualification by AMD is interesting. It either means that the Intel flaw occurs primarily when speculative execution pulls from virtual memory (disk)...

    or that AMD did have the same flaw but takes advantage of page fault interrupts to add in a simpler microcode privilege check as a patch.

    *** Best guess... Intel speculative execution is hardwired such that it begins immediately without waiting for OS address protection schemes being re-applied to newly loaded page fault loads. ****

    So very likely protections on kernel data/instructions work well on those portions of kernel that are actually in memory (? via the memory controller mapping bits?). But portions of kernel currently residing in virtual memory do not have those protective bits as an integral part of initial page loads (different protections apply while on disk). That is address protection bits on newly loaded pages are probably set by ad hoc software OS routines (multiple instructions running in kernel mode)...a delay of hundreds of clocks.

    The future silicon fix is therefore simple - new page loads start as kernel buffers that default to NX and kernel mode protections THEN load page data and LATER at leisure (OS routine) decide if the protection bits for that page need to be set to some user space or executable instead. Seems fairly easy to do as a software patch as well...unless current page load instruction mess with protection bits in some other way by default (like setting user mode).

    Or Intel could add a Page Not Ready bit that would prevent all CPU access except page loading instructions until a new load page protection instruction successfully completed and reset the PNR bit.

  21. Sir Lardassicans

    Muhahaha only x86-64 is affected, boooyah!

    My Pentium M remains to be secure as an AMD chip, thanks to the absence of 64bit transistors! Finally after 20 years my refusal to upgrade has paid off - Ka Ching!

  22. JBowler

    ARM slowed down to help Intel marketing department?

    Is Linus dumping Shyte on ARM because he doesn't know what an ARM processor is?

  23. This post has been deleted by its author

  24. paddypawprints


    There has been lots of discussion about the impact to individual operating systems but what about VMWare, Hyper-V, and Xen? Are they immune to the issue? Can someone running a VM get access to hypervisor memory, and from there access to all the other VMs on the machine?

    Seems to me this is the big issue.

  25. Depressed Optimist

    Shouldn't we be upset with The Register for broadcasting this?

    Shouldn't we be upset with The Register for exposing this before anyone's had a chance to patch for it? My understanding is, the big players affected by this vulnerability have known for months and are working on mitigating it, but have been asked to keep it quiet so hackers didn't come up with a way to take advantage of it. Now that The Register has publicly spilled this--(apparently against the wishes and advice of everyone involved)--aren't hackers off to the races to exploit this now? Looking at the ongoing conversations taking place out there, it looks like it won't take hackers too terribly long to put something together...just hopefully longer than it will to put preventative measures in place.

    I hope The Register reporter(s) are happy with their "we-got-it-first" award and can sleep well at night knowing they may have given hackers a head start.

    <Just a thought.>

    1. diodesign (Written by Reg staff) Silver badge

      Re: Shouldn't we be upset with The Register for broadcasting this?

      >apparently against the wishes and advice of everyone involved

      No one we contacted for comment told us to stop.


  26. Sirius Lee

    Limited impact on EC2?

    All of the Windows servers I am using on AWS EC2 use AMD64 processors. AWS and Azure can swap out Intel hardware for AMD hardware with just a virtual machine restart so this may be a preferred option for them.

    AWS went through an exercise over the summer to force reboot some servers. We were told it was for essential maintenance of the host hardware. It affected two of my servers. Perhaps the real reason for this exercise was move us onto AMD processors (I wish now I knew the CPUs used before the reboot).

  27. Augie

    Kudos to AMD,

    Intel should take note of how AMD have responded with this, in a fairly clear manner.

    This is how you respond to a cluster f&*k like this

  28. Brent Beach

    Just sayin'

    I wonder if we are going to hear from the design engineer at Intel who said, many years ago,

    "You know if we do this pre-fetch thingee we are losing data security ...

    and was promptly shut down by his boss who was far more concerned about AMD having faster processors than data security?

  29. Gigabob

    Hopefully a Major Zero Day Exploit Resolved

    Given this flaw has been Intel CPU design for over a decade, it is reasonable to assume security agencies with in the US and at least Russia are intimately familiar with this capability and have tools to read the core kernel details as a result and compromise any system previously thought of as secure. I will be applying the patch ASAP - but will now start looking more closely at a new CPU. Perhaps it is time to switch to AMD.

  30. nkz15

    If you guys are wodering, here is the windows update id.


  31. BobCooper

    History Repeats

    This design error is history repeating itself. Back in the seventies the 1970's the CDC 7600 had a similar design flaw. A process would reference an out-of-bound memory address which would stop execution. However, the contents of the out-of bounds address would be in a register of the image of the stopped process. Using a parent process to repeatedly access low memory by the child process, all of low memory was read. This is where pass words were stored, unencrypted at the time. Seymour Cray made a hardware fix which was the right things to do.

  32. PeterM42

    Er WHAT?.....

    "The team proposed splitting kernel and user spaces to prevent this information leak".

    I would have thought that was pretty basic security, but there is not much about WINTEL that smacks of ANY sort of REAL security.

  33. JoshS

    Those very old Mac G3/4/5s will be hauled out of storage,

    to get around this very serious problem.

  34. GrapeBunch
    Thumb Up


    Normally I would apologize for not reading the preceding comments, but with over 400 and counting, I will stay shtum on that account. Still, in my heart, I apologize. Thanks to El Reg for a highly educational article; were I a "real" systems analyst, I might have understood it all !

    I'm wondering if the bug applies to 32-bit Intel processors. The article says x86-64, but a comment mentions that all Intel x86 processors get patched in Linux. So I'm wondering if my now fairly ancient Thinkpad T60, Intel 32-bit Core Duo T2400 laptop running XP is, with care, as secure as or more secure than a contemporary machine running Bo Derek. If it is, well, chortle.

    We all know that Microsoft the OS-maker introduced undocumented features and that Microsoft the application-maker exploited said undocumented features to stay ahead of the application competition. Yes, from experience, I am expecting to get downvoted for that. Go ahead, fill your buffers. I am wondering if any parallel could be drawn with the current case. I'm not after the obvious, that Intel was trying to keep ahead of AMD and, ah, jumped the shark.

  35. shakeup

    apple patched macOS 10.11, 10.12, and 10.13

    Please don't insist that everyone update to mac os high sierra 10.13 if they don't want to do so as 10.11 and 10.12 both appear to have been patched back on Dec 6. If you look at the kernel updates, there is a new one added/updated today that indicates the 2017-002 update for 10.12 and the 2017-005 updates for 10.11 (along with 10.13.2 for high sierra) all fix the Meltdown vulnerability aka CVE-2017-5754.

    NONE of the entries list any fixes for the other two Spectre vulnerabilities -- CVE-2017-5753 or CVE-2017-5715. There have been no other new security updates listed on the Apple support site.

    Reference (all Apple security updates) --

    Reference (with fixes listed for CVE-2017-5754) --


    Available for: macOS High Sierra 10.13.1, macOS Sierra 10.12.6, OS X El Capitan 10.11.6


    Entry added January 4, 2018"


POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019