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. bombastic bob Silver badge
    Unhappy

    Hmmm...

    I hope the kernel patches are intelligent enough to ONLY apply the 'slowness feature' when absolutely necessary, and not simply slow EVERYONE down to be "fair" (or, on the part of devs, LAZY).

    1. bazza Silver badge

      Re: Hmmm...

      Who knows. With Linux of course we can tell. With Windows, possibly benchmarks are our friend if MS are keeping stum about the matter.

      From a security point of view it would be better to leave things as they are if the hardware is not effected; better to be running mature code than to be running what seems like a major update out together in a bug hurry.

      1. Dave K

        Re: Hmmm...

        The other issue here is what MS does regarding Windows 7. It would not surprise me in the least if they tried a clever/efficient patch for Windows 10 and a simpler (and slower) bodge-job for Windows 7/8. Still, I guess we'll find out soon enough. They'd also better make sure that the changes only apply to Intel machines. I don't want MS to arbitrarily slow down my AMD PC as a result of this - you'll note that AMD submitted a Linux patch to ensure their CPUs weren't caught up in this, will MS do the same?

        1. demented

          Re: Hmmm...

          If they do a bodge job for win7 o/s then many won't install the patch, if you have a good security suite installed then how can this be an issue?

        2. Anonymous Coward
          Anonymous Coward

          Re: Hmmm...

          “you'll note that AMD submitted a Linux patch to ensure their CPUs weren't caught up in this, will MS do the same?”

          We’ll find out, I guess - the two paths MS can take being “do we release patches that only impact performance on Intel” or “are we working together so closely with Intel that the competition authorities should be involved”?

      2. bernardo.ortiz

        Re: Hmmm...

        By the sound of things it looks like the bug allows users (non-admin) to see the guts of the OS. This means, that once published, hackers will be given details as to how to take over the computer if you haven't upgraded (security risk).

        What is naturally to fear is that the first generation code (patch) will be to block these details. New, ad-hoc code means there may be stability issues (return of the blue screen ??). If the OS developers run all their security test vectors, no old holes should open up. The question I think you have is will there be some new hole, I'm not sure anyone can know for sure - we can only demand that old bugs don't return.

        What we can expect is for code to run slower. If I interpret the description well, the more threads you have the slower the code should run, ie it should impact JAVA code (scripts/interpreted code) more than C++(compiled code). It'll expose individual coding styles and change coders tactics for performance optimization.

      3. Anonymous Coward
        Anonymous Coward

        Re: Hmmm...

        " With Linux of course we can tell. With Windows, possibly benchmarks are our friend "

        But Windows has far more in depth performance diagnostic features off the shelf than Linux does?

        1. Daniel von Asmuth
          Windows

          Re: Hmmm...

          Anomalous Cowboy wrote: "But Windows has far more in depth performance diagnostic features off the shelf than Linux does?"

          No, but the Windows performance monitor is more user-friendly.

        2. oldcoder

          Re: Hmmm...

          No - the hybrid kernel of Windows will have a much LARGER overhead.

    2. Tom 7

      Re: Hmmm...

      Its going to have to slow everything down - if the OS doesnt do the checks on everything then its leaky as a sieve.

      Someone just took £50 from my cpu!

      1. Destroy All Monsters Silver badge
        Devil

        Re: Hmmm...

        Someone just took £50 from my cpu!

        Suddenly your CPU is like Bitcoin.

        Or the EURO

      2. Anonymous Coward
        Anonymous Coward

        Re: Hmmm...

        Only a tiny few are affected, but since you're a good friend, here's a $29 battery replacement deal to shut you up.

      3. Alex Fielder 1

        Re: Hmmm...

        I suspect the class-action lawyers are already sharpening their knives depending on the performance hit.

    3. diodesign (Written by Reg staff) Silver badge

      Re: Hmmm...

      The KPTI Linux patches are applied to all Intel x86 CPUs. AMD submitted a patch to stop it being automatically enabled on its chips. It is possible to turn off KPTI during boot up.

      C.

    4. Red Bren

      Re: Hmmm...

      Would this mean distributing Intel & AMD specific binaries, or would users have to compile their own kernel to enable/disable the patch as necessary?

      1. hellwig

        Re: Hmmm...

        If written intelligently, the kernel would detect the CPUID and supported instruction sets, and apply itself appropriately.

        Ideally the kernel would flag all Intel chips, and once Intel fixes their problem, Intel releases a new feature flag that indicates a fix to the problem that the kernel could also flag off of.

        1. This post has been deleted by its author

      2. Tom Paine

        Re: Hmmm...

        What do you think?

    5. Cl9

      Re: Hmmm...

      Kernel memory is mapped to user mode processes to allow syscalls (a request to access hardware/kernel services) to execute without having to switching to another virtual address space. Each process runs in its own virtual address space, and it's quite expensive to switch between them, as it involves flushing the CPU's Translation Lookaside Buffer (TLB, used for quickly finding the physical location of virtual memory addresses) and a few other things.

      This means that, with every single syscall, the CPU will need to switch virtual memory contexts, flushing that TLB and taking a relatively long about of time. Access to memory pages which aren't cached in the TLB takes roughly 200 CPU cycles or so, access to a cached entry usually takes less than a single cycle.

      So different tasks will suffer to different extents. If the process does much of the work itself, without requiring much from the kernel, then it wont suffer a performance hit. But if it uses lots of syscalls, and do lots of uncached memory operations, then it's going to take a much larger hit.

      That's what I make of it from understanding of it, which might not be 100% correct.

      1. Notas Badoff

        Re: Hmmm...

        "So different tasks will suffer to different extents." But the hardware...?

        "The downside to this separation is that it is relatively expensive, time wise, to keep switching between two separate address spaces for every system call and for every interrupt from the hardware."

        So now we'll have a little tax charged for every interrupt - *every* *interrupt*. How much software do you run that doesn't use disk or network or any I/O?

        This was not the financial micro-transaction future I was thinking of.

        1. Anonymous Coward
          Anonymous Coward

          Re: Hmmm...

          Ideally, any I/O heavy software will use large buffers and avoid calls like fgetc, instead asking the kernel to read in a large chunk at a time to its buffer with something like fread, thus reducing the number of system calls being made.

          1. anonymous boring coward Silver badge

            Re: Hmmm...

            Yes, but the amount of stuff going on for almost no good reason whatsoever on a Windows PC is astonishing. Now massive overhead on top of those misbehaving apps... Worrying!

      2. ThomH

        Re: Hmmm...

        So this puts us more or less to where a true microkernel would be in terms of performance? Virtually a full context switch cost for any trip into the kernel?

        A breathtaking error if I've understood it. In a fair market this should kick the door down for AMD.

        1. string
          Trollface

          Re: Hmmm...

          > In a fair market this should kick the door down for AMD.

          What's the betting intel are pushing M$ to enable the KPTI patch for all chips regardless of mfr to try and shore up relative losses in performance?

          1. Christopher Rogers

            Re: Hmmm...

            Maybe MS getting on board with arm processors was foresight based on insider knowledge....

            1. oldcoder

              Re: Hmmm...

              No, that was just Linux eating MS lunch again - and demonstrating perfectly usable desktops on the Pi and Arduino.

      3. Peter Gathercole Silver badge

        Re: Hmmm...

        I think we need to return to PDP11, where you had an alternative set of memory management registers for program and supervisor (kernel) mode. When you issued the instruction to trigger the syscall, the processor switched the mode, triggering an automatic switch to the priv. mode registers, mapping the kernel to execute the syscall code..

        This meant that it was not necessary to have part of the kernel mapped into every process.

        IIRC, s370/XA and Motorola 68000 with MMU also had a similar feature. I do not know about the other UNIX reference platforms like VAX (the BSD 3.X & 4.X development platform) or WE320XX (AT&T's processor family used in the 3B family of systems - the primary UNIX development platform for AT&T UNIX for many years), but I would suspect that they had it as well.

        I first came across the need to have at least one kernel page mapped into user processes on IBM Power processors back in AIX 3.1, where page 0 was reserved for this purpose. In early releases, it was possible to read the contents of page 0, but sometime around AIX 3.2.5, the page became unreadable (and actually triggered a segmentation violation if you tried to access it).

        1. Anonymous Coward
          Anonymous Coward

          Re: Hmmm...

          Those processors (nice though they were) didn't do speculative execution.

          1. Peter Gathercole Silver badge

            Re: Hmmm... @AC

            That's true. Having a address space change would have to disable speculative execution, because it would also have to try to predict which address space it would be in.

            Actually, thinking about it, it still has to, because if the mapped page is protected from view, there still needs to be some mechanism to lift the protection to allow the speculative execution of the branch of code, before the decision is taken. But in theory, the results of the branch-not-taken should be discarded as soon as the decision is made, so that the information gathered could not be used. Maybe there is something in the combination of speculative execution and instruction re-ordering (not mentioned yet) which allows data to be extracted from later in the pipeline.

            Maybe this is the problem, and if it is, it's probably a design flaw rather than a bug, Interesting.

            1. hugo tyson

              Re: Hmmm... @AC Might not even leak data

              The leak may not even be data, it could be as small as a timing change from the spec-ex path taking longer to fault, or not, allowing the attacker to probe the kernel space for not/valid pages - so defeating to an extent the kernel memory-map randomisation? Worse might be a spec-ex branch on spec-read secret data which affects timing similarly, without directly exposing the data itself.

              1. DCFusor

                Re: Hmmm... @AC Might not even leak data

                Now that would be embarrassing to the Rust evangelists, who think their one trick pony solves every possible security issue! They'll suppress that idea with their usual fervor I bet. To me it's the height of vanity to think you can pre-define and therefore pre-solve every possible side channel and backdoor attack. The endless game of thief vs locksmith is...endless...

              2. anonymous boring coward Silver badge

                Re: Hmmm... @AC Might not even leak data

                Rolling our massive changes for something as esoteric as that seems unlikely?

            2. Paul Shirley

              Re: Hmmm... @AC

              "the results of the branch-not-taken should be discarded"

              From the and hint the problem isn't speculative execution as such, it's fetch hardware that reads memory before checking permission, presumably changing cache state irreversibly. It speculative execution disables the privilege violation because the code path is discarded there's no way to detect the event or take any remedial action like invalidating the tlb. However invalidating the tlb would leak address layout information anyway!

              The correct thing is blocking the fetch ops completely while still potentially raising an exception if that part is taken. Better, raise an exception anyway. Which appears to be the amd approach. Intel look like they saved some transistors and maybe gained a tiny speed advantage without thinking it through.

              1. oldcoder

                Re: Hmmm... @AC

                That causes the instructions to stall - filling the pipeline with unusable instructions and no data.

        2. Warm Braw

          Re: Hmmm...

          I think we need to return to PDP11

          While the elegance of the PDP-11 design is beyond dispute, it wouldn't scale to the performance of current systems. Notably, its memory management was very simple: 8 base and length registers for each execution mode. As soon as you go much beyond a 64k address space it becomes infeasible to have a full set of mapping registers on the CPU and you're forced down the TLB road.

          What might well make sense is if it were possible to run the (key parts of the) kernel in a "protected real" mode (i.e. with no virtual address translation at all, but with some form of memory protection using keys or limit registers. If you don't have enough physical memory to contain a kernel, you're not going to make much progress anyway. And it's only one of many areas in which improving performance with caching of one kind or another leads to potential anomalies with specific execution patterns.

          Not that any speculation (sorry!) of that kind helps with the current debacle - but it does illustrate how the growing complexity and unauditably of processor designs has largely been overlooked until recently while we've been principally worried about software security.

          1. Anonymous Coward
            Anonymous Coward

            Re: Hmmm...

            "What might well make sense is if it were possible to run the (key parts of the) kernel in a "protected real" mode"

            If the kernal is in the same address space as user code and using the same pipe then nothing changes. Either a seperate CPU/cache for kernal code and without speculative execution or scrap the whole model.

            Basically no kernal code should be run before security has been validated and that means stalls in kernal code execution.

            1. Paul Shirley

              Re: Hmmm...

              "If the kernal is in the same address space as user code and using the same pipe then nothing changes. Either a seperate CPU/cache for kernal code and without speculative execution or scrap the whole model.\"

              Even in user space page permissions exist. There's nothing intrinsic to a flat, shared address space that stops a CPU enforcing all permissions at the thread/page/exe page level, all the way down to prefetch and cache access. Separate cache/memory systems per ring is a high price to pay to replace access control logic in the memory system. Dumping cache state is an even higher price to pay for not having that logic.

            2. oldcoder

              Re: Hmmm...

              Not really. "key parts of the" kernel are interrupt service functions... and they need to be able to address the entire memory.

              Real mode sucks.

              What is really needed is better architecture.

              One set of registers for each interrupt, kernel, supervisor, user

              at a MINIMUM. Then add separate cache for each level - though not necessarily all being the same size.

        3. J.G.Harston Silver badge

          Re: Hmmm...

          The problem with the PDP11 method is the kernel code has to do fiddly read-userland-from-kernal operations to get the call's parameters and data. If the kernal is paged in and running in kernel memory at &o004010 and the caller has its parameters in userland at &o004010 the kernal can't read them by just reading from &o004010 as that would read kernel memory, it has to use MoveFromPreviousInstructionspace (MFPI) instructions to copy the parameters to local (kernel) space, and MoveToPreviousInstructionspace (MTPI) instructions to copy stuff back to userland, such as loaded data.

          1. Peter Gathercole Silver badge

            Re: Hmmm... @J.G.Harston

            That is true, but for volume data moves was mitigated by DMA from disk directly into memory-mapped buffers in the process address space, using the UNIBUS address mapping registers, which allowed raw DMA transfers to addresses outside of the kernel address space.

            Of course, not all PDP11 models had the UNIBUS (or, I presume a similar QBUS) feature, but pretty much everything after an 11/34 would have. I had an unusual 11/34e that also had 22-bit addressing, which made it much more useful.

          2. oldcoder

            Re: Hmmm...

            Only for the parameters.

            Once past that, the kernel could use a single page table entry to map to whatever user memory was needed.

            For the intel processors.... this bug just about kills any microkernel which was already slow, now becomes 20% slower.

            Microsofts hybrid microkernel is going to have fits with this.

        4. Primus Secundus Tertius

          Re: Hmmm...

          @Gathercole

          Back in the 1970s I was asked to make a PDP11 system go faster. It was running DEC's real time OS, viz RSX11. The critical part of the program needed to make a lot of OS calls. I arranged for that region of the program to be mapped into kernel space (using a 'connect to interrupt' facility) and got my speedup. The cost was a section of high-risk code.

          There is a reason why interrupts used to return control to the kernel. It may be that a disk transfer has finished, thus allowing some more important program to resume. In more general terms, the context has changed and the system should adjust, particularly if several programs are running. The PDP11 could respond to interrupts within microseconds, perhaps to capture volatile data from fleeting registers on special hardware; but it could be a long time returning to the point of interrupt.

          1. Peter Gathercole Silver badge

            Re: Hmmm... @Primus Secundus Tertius

            The reason why PDP-11 could respond so quickly to interrupts was this facility to switch address spaces without having to save the register context. On other architectures, in order to take an interrupt, the first thing that you need to do is save at least some of the address registers, and then restore them after you've handled the interrupt.

            IIRC, the PDP-11 not only had duplicate address mapping registers, but also had a duplicate set of some of the GP registers, so you had to do pretty much nothing to preserve the process context that's just been interrupted. This is what made the interrupt handling very fast.

            The time to return from the interrupt was entirely down to the path length of the code handling the interrupt. The actual return mechanism was as quick as the calling mechanism. There were unofficial guidelines about how long your interrupt code should take, which I believe were conditioned by the tick length for the OS. If you took too long, you would miss a clock-tick, which would result in the system clock running slow.

            In addition, I also believe that there were a small number of zero page vectors that were left unused by either UNIX or RSX11/m (the version of RSX I was most familiar with) that allowed you to add your own interrupt handlers for certain events.

            1. oldcoder

              Re: Hmmm... @Primus Secundus Tertius

              Depending on the CPU, it did have to save registers.

              In other cases, the kernels did save registers as it could not determine BEFORE handling the interrupt, which task was going to be next.

              The registers that took the longest was the FPU registers.

        5. Roo
          Windows

          Re: Hmmm...

          "I think we need to return to PDP11, where you had an alternative set of memory management registers for program and supervisor (kernel) mode."

          There are already plenty of non x86 derivatives out there that don't have this bug, all that's required is folks to make the move. :)

          Would be nice if vendors updated their benchmark results in the light of a 30% performance hit, so we can get an apples-apples comparison against processors that don't suffer from this particular fault.

          1. Doctor Syntax Silver badge

            Re: Hmmm...

            There are already plenty of non x86 derivatives out there that don't have this bug, all that's required is for vendors to make them as readily available so as to enable folks to make the move. :)

          2. Peter Gathercole Silver badge

            Re: Hmmm... @Roo

            I think that you should say were plenty of non-x86 processors out there. There really aren't any more, with just AMD (which is an x86 derivative, but may not be affected), Power, zSeries, ARM, and the tail end of SPARC, and I suppose Itanium (just) being around.

            You could also say, I suppose, that there is a MIPS processor around still, but you'd have to buy it from the Chinese.

            A lot of other architectures never made the switch to 64 bit (although Alpha was always 64 bit). Architectures we've lost include Alpha, PA-RISC, VAX, all Mainframe apart from zSeries, DG Eclipse, Motorola 68000 and 88000, Nat. Semi. 32XXX, Western Electric 32XXX, various Honeywell, Burroughs and Prime systems, and various Japanese processors from NEC, Hitachi and Fujitsu.

            This is largely the cost of wanting cheap, commoditized hardware. You end up with one dominant supplier, and suffer if they get something (or even a lot of things) wrong.

            1. Roo
              Windows

              Re: Hmmm... @Roo

              "I think that you should say were plenty of non-x86 processors out there."

              There are still plenty out there, not all of them will be a viable alternative for your application...

              "There really aren't any more, with just AMD (which is an x86 derivative, but may not be affected),"

              In my view AMD share the same problem as Intel: The x86 ISA (64bits, extensions, warts and all) are simply too complex to test properly. It's a scalability limit in the design space - and this isn't a new problem - it goes back decades. We are seeing bugs span multiple steppings AND generations of product line as a matter of routine. The x86 vendors are physically unable to sell us a fully functional chip even if we pay top dollar for it.

              As I see it, as customers, we have no alternative but to go to other ISAs over the long run - simply to get a working chip without the "feature-itis" imposed by 30+ years worth of workarounds.

        6. Down not across
          Happy

          Re: Hmmm... @Peter Gathercole

          I think we need to return to PDP11, where you had ...

          The only reason I would need is,well,PDP11.. nuff said.

        7. Version 1.0 Silver badge

          Re: Hmmm...

          It seems to be an architectural bug from what I'm seeing - probably related to the need for speed being the highest priority for marketing while security takes a back seat. We never worried about "security" in the old days of processor design, we were far more worried about incorrect access causing a crash and that took priority - with the result that modern security issues were mostly nonexistent.

          1. Roo
            Windows

            Re: Hmmm...

            "We never worried about "security" in the old days of processor design"

            How old is old ? MMUs have been around a long time now.

            "We never worried about "security" in the old days of processor design, we were far more worried about incorrect access causing a crash and that took priority - with the result that modern security issues were mostly nonexistent."

            Seems to depend on where you worked - some vendors never embraced KISS. The protection features of the DEC Alpha were far easier to understand, use, test and verify than the equiv plumbing on the much older i386 for example.

    6. TheVogon

      Re: Hmmm...

      So we all get new CPUs on Intel like we did with the Pentium floating point bug?

      1. bpfh

        Re: Hmmm...

        And a soldering iron for all the cpu’s that are welded to the mobo...

      2. Hans 1

        What if ?

        Class action lawsuit -> recall -> Intel chapter 11

      3. Giles Jones Gold badge

        Re: Hmmm...

        Pretty sure the FPU bug was easily patched, they just added one or two NOOPs between certain instructions. It was a compiler fix.

      4. Daniel von Asmuth
        Unhappy

        Re: Hmmm...

        No, you don't get a new CPU, you get a software workaround.

        There is no time like the present for China to become a world player in CPU design.

        Around the turn of the millennium I was able to read and write SCO Unix kernel variables (specifically uptime) as root using a simple shell script. Utilities such as 'ps' likewise ran in user space and needed to read process tables from kernel memory.

    7. Oh Homer
      Mushroom

      Intel Inside...

      Can run but can't hide.

      What a clusterfsck.

      Yet another reason to stick to AMD.

      1. big_D

        Re: Intel Inside...

        Hmm, good timing... I bought a new PC just before Christmas and decided to go AMD after about a decade of Intel...

        1. sambaynham

          Re: Intel Inside...

          Me too! Ryzen Ryzen, La la la!

        2. Maelstorm Bronze badge

          Re: Intel Inside...

          "Hmm, good timing... I bought a new PC just before Christmas and decided to go AMD after about a decade of Intel..."

          Good call. I just bought a new laptop myself and went with AMD as well. It's going to be some time before updated chips from Intel come out as this is a hardware problem with speculative instruction execution on the pipeline. Hardware means that Intel will have to redo all the masks that are used for the fabrication process.

        3. Doctor Syntax Silver badge
          Unhappy

          Re: Intel Inside...

          " I bought a new PC just before Christmas and decided to go AMD after about a decade of Intel"

          Just starting to think about a laptop replacement. Looked at PC Specialist. Not an AMD in sight.

          1. honkhonk34

            Re: Intel Inside...

            PC Specialist stopped being my go to around 3 years ago unfortunately, as the choices were becoming too restrictive. If I knew of a company as good as they once were, I'd throw business at them any day of the week!

        4. rnturn

          Re: Intel Inside...

          Good timing indeed. I've got plans to replace several aging PC/servers and AMD just leapfrogged to the top of the list (or should I say that Intel just step on their shoelaces and stumbled to the bottom).

    8. Robert Brockway

      Re: Hmmm...

      There is precedent here. The kernel still tests for the F00F bug on boot and applies the kernel-level work around only on systems that need it. Thus the slow down is only applied where it is needed. I expect this will happen in this case, although we are talking about a significant architectural change here.

    9. wayne 8

      Re: Hmmm...

      Will this slowdown affect iPhones? /sarc

      1. Version 1.0 Silver badge

        Re: Hmmm...

        Looks like the bug doesn't affect the J11 on my PDP 11/23 so I guess I'm OK.

    10. peter-.-

      Re: Hmmm...

      did you mean, eh, crippling AMD ??

      you bet, it will happen

      how come that AMD would be faster ? impossible !!!!11!!1!!!

      1. Maelstorm Bronze badge

        Re: Hmmm...

        "did you mean, eh, crippling AMD ?? you bet, it will happen how come that AMD would be faster ? impossible !!!!11!!1!!!"

        If that happens, I can safely guarantee that AMD will not be quiet about it. Lawsuit anyone?

    11. cream wobbly

      Re: Hmmm...

      If it helps, Minix, Mach, Hurd, Exec, and Fuchsia (okay, Zircon) won't suffer the 'slowness feature'. Less-than A aitch-ref equals https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate greater-than I'll wait for you to catch up less-than oblique a greater than.

      1. oldcoder

        Re: Hmmm...

        I believe the added overhead in context switching will nail all the microkernels...

    12. J. R. Hartley

      Re: Hmmm...

      Fuc

  2. bazza Silver badge

    Oh....

    ....crap.

    1. Sampler

      KAISER?

      I predict a riot...

      1. elDog

        Re: KAISER?

        I predict a roll. Would you like poppy-seeds on that, sir?

        Not sure if translates well outside of US delicatessens.

      2. John Smith 19 Gold badge
        Unhappy

        Re: KAISER?.. I predict a riot...

        And are we sure this will be a complete solution?

    2. Pascal Monett Silver badge
      Flame

      Crap indeed

      Here I was, all happy with my i7 6700 that has served me well for the past two years, and now I learn that I'm basically going to have to replace the hardware if I want to stay secure and have good performance. What a nuisance.

      Another round of Windows reinstall, with another fracking call to Redmond to justify that I am indeed the owner of this shit. I hate the idea already.

      Ah, the day games are made for Linux first . . .

      1. lsatenstein

        Re: Crap indeed

        My uneducated guess is that the brute force protection code is being implemented. This code should give Intel some time to arrive at a more sophisticated microcode solution where the overhead is perhaps one or two dozen microcode instructions. With a microcode fix, the patch can be removed, or made specific to certain models of CPU.

        I like to be optimistic, not pessimistic. A low overhead fix will be developed AQAP. (As quickly as possible)

        1. xeridea

          Re: Crap indeed

          They say it is not possible to fix with microcode. Either be insecure, have huge slowdown, or buy an AMD CPU.

          1. werdsmith Silver badge

            Re: Crap indeed

            I'm quite happy to live with the security flaw on my home computers, so I hope this update is elective.

            Did Mac OSX get mentioned in the article? I don't read that carefully.

            1. Known Hero

              Re: Crap indeed

              "I'm quite happy to live with the security flaw on my home computers, so I hope this update is elective."

              I was under the impression that MS is forcing updates whether you like it or not !!

            2. Don Pederson

              Re: Crap indeed

              Isn't the Mach kernel in MacOS a microkernel? If so, wouldn't that mean that this wouldn't be an issue?

              1. oldcoder

                Re: Crap indeed

                Nope.

                The problem appears to be context switching problems due to pipeline optimization.

                The presented solutions will impact microkernels more than monolithic kernels as they have to do more context switching.

              2. kain preacher

                Re: Crap indeed

                nope its hybrid kernel same as windows.

                https://en.wikipedia.org/wiki/MacOS

        2. Paul Shirley

          Re: Crap indeed

          If the problem is memory fetching that does not check permissions before fetching ops or data that's under the level microcode works at and can't be fixed.

          1. -tim
            Facepalm

            Re: Crap indeed

            A problem seems to be that the data is feed into the data pipeline (and L1 cache?) via speculative execution. To simplify the problem... if you have some code like:

            if(false) {

            x=some data that shouldn't work

            } else {

            do something slow

            }

            y=some data that shouldn't work

            The x= gets the data loaded into the cache while the slow code is slow enough to make sure it gets there. Then the y= pulls data that is in the cache (and whatever makes up the other 64 bytes in its cache line) and that might not be checked against the permission bits in the virtual memory tables. I can't think of any situations where the x86 does speculative writes that would hit memory so this should be limited to reading data. The trick might work to slow down memory sharing on multi-core systems. x86 I/O sometimes is read based so that reading a memory location could resets a counter or buffer and that would be a problem limited to some i/o device. If someone can come up with a way to have the speculative data being read and then written back through the cache, the security game is over.

        3. scarletherring

          Re: Crap indeed

          > I like to be optimistic, not pessimistic

          You must be new here.

        4. oldcoder

          Re: Crap indeed

          Unfortunately, this is below the microcode level.

      2. LewisCowles1986

        Re: Crap indeed

        I was thinking the same, but then I remembered that Linux also has to deal with this shit because it's on the CPU die itself.

      3. Anonymous Coward
        Anonymous Coward

        Re: Crap indeed

        I'd be on Linux for gaming already if Star Citizen had a linux client.. Yes the game is miles from done but damn its' fun.

        1. Dane Pack

          Re: Crap indeed

          How many miles could you go in the next 4 years

  3. GBE

    I finally switch from AMD to Intel, and this is what happens.

    It's my fault. For decades I bought AMD processors instead of Intel. The last time around, I finally broke down and bought Intel...

    1. Tom 7

      Re: I finally switch from AMD to Intel, and this is what happens.

      I find buying AMD like not buying Windows - some else always makes the savings.

    2. Anonymous Coward
      Anonymous Coward

      Re: I finally switch from AMD to Intel, and this is what happens.

      I considered AMD, having recently bought a Xeon for a personal server. I wonder where we stand legally now? IANAL but surely the chips we have, once patched, will no longer be performing as advertised?

      1. Anonymous Coward
        Anonymous Coward

        Re: I finally switch from AMD to Intel, and this is what happens.

        Just change the battery.

      2. Red Bren

        Re: I finally switch from AMD to Intel, and this is what happens.

        "IANAL but surely the chips we have, once patched, will no longer be performing as advertised?"

        I was thinking something similar. The Lenovo laptop I bought less than 18 months ago is still in warranty so is it reasonable to ask for a refund/replacement?

      3. Alan J. Wylie

        Re: I finally switch from AMD to Intel, and this is what happens.

        Intel's CEO Just Sold a Lot of Stock

        https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx

        (Via Jackie Stokes)

        1. Kabukiwookie
          FAIL

          Re: I finally switch from AMD to Intel, and this is what happens.

          Wonder if the SEC is going to investigate this.

          Of course they're not going to be doing that, most regulations in the US that held back predatory forms of capitalism have been neutered and the ones that are still in place are not being enforced.

          1. Anonymous Coward
            Anonymous Coward

            Re: I finally switch from AMD to Intel, and this is what happens.

            The Securities and Exchange Commission in the US? I don't think this falls in their area, does it?

            No, this is a job for ...for...Bat Man?

        2. Colonel Mad

          Re: I finally switch from AMD to Intel, and this is what happens.

          Oh Wow, SEC on alert?

      4. Aqua Marina

        "I wonder where we stand legally now?"

        If you are a UK based consumer (not business) you have up to 6 years to make a claim against the business that sold you the CPU (not Intel) because of the wonderful Consumer Rights Act. If the manufacturer admits the fault, then all the relevant criteria have been met. A 30% performance loss would be considered unreasonable without compensation.

        The "First 6 months" and "since months or more" paragraphs on the Which website explain it best here https://www.which.co.uk/consumer-rights/regulation/consumer-rights-act

        1. Anonymous Coward
          Anonymous Coward

          Re: "I wonder where we stand legally now?"

          Under Australian law this probably fails the ACL guarantee and would be classed as a major problem, in which case consumers are entitled to a remedy of repair, refund, replace. The choice of remedy is down to the consumer.

          Quoting the ACCC:

          A product or good has a major problem when:

          * it has a problem that would have stopped someone from buying it if they’d known about it

          * it is unsafe

          * it is significantly different from the sample or description

          * it doesn’t do what the business said it would, or what you asked for and can’t easily be fixed.

          I think you can certainly argue that it has failed the first of these, and probably the 3rd and 4th as well.

          More details here:

          https://www.accc.gov.au/consumers/consumer-rights-guarantees/consumer-guarantees

          https://www.accc.gov.au/consumers/consumer-rights-guarantees/repair-replace-refund

        2. rnturn

          Re: "I wonder where we stand legally now?"

          I'm wondering how this will affect the contractual relationships between compute cloud vendors and their customers when the N processors the customers are paying for no longer get the job done. Oh to be a fly on the wall during those discussions...

      5. Destroy All Monsters Silver badge
        Trollface

        GURU MEDITATIONS! PRESS LEFT MOUSE BUTTON TO SLOW DOWN 30%

        IANAL but surely the chips we have, once patched, will no longer be performing as advertised?

        I don't think it said on the box "Guaranteed Security At Top Performance For Any Possible Kernel"

        1. Ian 55

          Re: GURU MEDITATIONS! PRESS LEFT MOUSE BUTTON TO SLOW DOWN 30%

          /I don't think it said on the box "Guaranteed Security At Top Performance For Any Possible Kernel"/

          No, but it did say in the CPU documentation that it definitely wouldn't allow this...

      6. Anonymous Coward
        Anonymous Coward

        At the AC, re: legal stance.

        If you're in the United States then the phrase you want to suggest to your lawyer is "Defective By Design". I am not a lawyer, but if it takes a major software fix to ensure security, that's pretty much spot-on the definition of a DBD claim.

        If an auto maker had to fix a serious issue that robbed the engine of nearly 30% of its power delivery capacity, there would probably be a general recall & more lawsuits than you could shake a stick at. So a CPU that has to be fixed & the fix robs it of ~30% computational capacity? Yup. DBD.

      7. James 47

        Re: I finally switch from AMD to Intel, and this is what happens.

        The chips will still work as advertised, it's the kernel that is being made slower.

        1. EnviableOne

          Re: I finally switch from AMD to Intel, and this is what happens.

          Intel's GOJF card

          They are not slowing the processor, the OS is, so no comeback on Intel

          OS is slower because "security" and they are informing you before it happens, so no recourse to MS

          SO basically we all get srewed and Intel MS et al. get to keep their mnega bucks

          1. misterinformed

            Re: I finally switch from AMD to Intel, and this is what happens.

            > They are not slowing the processor, the OS is, so no comeback on Intel

            I don't think that argument will work for Intel. Their chips are not working to specification: the user-mode/kernel-mode separation is supposed to be policed by the CPU, and it's leaky. There is no chance of them hiding this fact.

            They could try to spread the blame by claiming that some of the slowdown is due to badly coded workarounds by Microsoft etc but they can't escape the blame for workarounds being needed.

          2. Anonymous Coward
            Anonymous Coward

            Re: I finally switch from AMD to Intel, and this is what happens.

            @EnviableOne

            "They are not slowing the processor, the OS is, so no comeback on Intel"

            I don't think this will wash under Australian consumer law as one of the key guarantees a product must meet is that it has a major problem entitling the consumer to a repair/refund/replace remedy if (quoting the ACCC):

            * it has a problem that would have stopped someone from buying it if they’d known about it

            If you had been told at the point of purchase that x months down the line, a software patch is going to be required due to a flaw in the CPU that would slow it down by a significant margin would you still have bought it?

            Going a bit off topic...

            If you are really stuck for something to read, the legislation setting out these guarantees is part of Schedule 2 of the Competition and Consumer Act 2010

            https://www.legislation.gov.au/Details/C2015C00327

            For something more readable, I would heartily recommned that everyone has a look at this:

            https://www.accc.gov.au/publications/electrical-whitegoods-an-industry-guide-to-the-australian-consumer-law

            I always print this out to take with me whenever I need to take something back to a retailer. It is amazing how quickly they change what they are saying when you show them that you know the law.

            Shout out for KMart, Bunnings and BigW as in my experience they usually provide excellent customer service and will refund or replace even when they don't have to under the law.

            Big boo to JB HiFi who basically lie to you about your consumer rights and have to be shown the document above to get them to do anything. Their weasel word "Minimum Voluntary Warranty Policy Guide" states that your rights can't be restricted then goes on to attempt to restrict your rights by stating that you are not allowed a refund after 3 or 6 months, depending on the price of the goods in question. The in store staff will always tell you that these are hard limits and you can't get a refund after these times, assuming that they haven't instead tried to fob you off to the manufacturer, which is also illegal.

            https://www.jbhifi.com.au/Documents/Consumer%20Warranties%20and%20Refunds%20docs/YourRights_July2014_HR_02_v3.pdf

            This is from personal experience at two seperate JB stores. Maybe others are better, but considering this guide comes from their head office I won't be holding my breath.

            Please note that I don't blame the shop floor staff. I have worked in retail and know what it can be like. The problem comes from corporate policy and training. The staff seem genuinely surprised when you show them the ACL guide and point out where they are breaking the law.

            Sorry. Rant over.

    3. thames
      Trollface

      Re: I finally switch from AMD to Intel, and this is what happens.

      I'm typing this from a PC with an AMD CPU and running Ubuntu. Aren't I feeling smug right now.

      Given how many people are affected, I can't see Intel replacing the hardware for free. This is worse than the infamous Intel floating point math bug.

      I'm now waiting for people to re-run loads of benchmarks after the patches come out to see how much performance was lost.

    4. 9Rune5

      Re: I finally switch from AMD to Intel, and this is what happens.

      2017 was truly AMD's year. First they introduced several interesting CPUs (if you are into multi-core designs), followed by some decent GPUs, and now this.

      I switched from AMD when Intel introduced Core 2 Duo. This year I think i will switch back to AMD. Finally some competition (again)!

      1. JohnFen

        Re: I finally switch from AMD to Intel, and this is what happens.

        Indeed. I've already been leaning toward avoiding Intel processors in future hardware purchases. This pretty much decides it, as I now wish I'd gotten off the fence a few years ago.

        1. Giles Jones Gold badge

          Re: I finally switch from AMD to Intel, and this is what happens.

          The new Ryzen processors are good, but there's not a lot of software optimised for them as of yet.

      2. Anonymous Coward
        Anonymous Coward

        Re: I finally switch from AMD to Intel, and this is what happens.

        "This year I think i will switch back to AMD. Finally some competition (again)!"

        Well, for the last ten years, AMD have been competitive, it's been a trade-off between performance hit on AMD for a security hit on Intel.

        AMD published their performance specs, Intel didn't tell you their hardware was compromised, but made much of their higher performance with regard to AMD.

        Turns out your confidential data has been exposed on Intel hardware for ten years. But you got improved performance. That trade off could have been a commercial decision, Intel concealed the information, that makes it a problem.

        1. jelabarre59

          Re: I finally switch from AMD to Intel, and this is what happens.

          Turns out your confidential data has been exposed on Intel hardware for ten years. But you got improved performance.

          But look at the bright side; it can be compromised that much FASTER!

        2. rnturn

          Re: I finally switch from AMD to Intel, and this is what happens.

          So, it's a case of: Faster, Cheaper, Secure... pick two.

    5. Dinkrex

      Re: I finally switch from AMD to Intel, and this is what happens.

      If you bought a Coffee Lake CPU, then it's not affected.

    6. FelinoErse

      Re: I finally switch from AMD to Intel, and this is what happens.

      Since the 19 nineties, I have personal experience with the shady side of Intel, hence I have stayed loyal to AMD. Many former Intel employees have voiced their knowledge of Intel's dark side.

      1. Peter2 Silver badge

        Re: I finally switch from AMD to Intel, and this is what happens.

        I have a Ryzen, and have yet to notice any noticible performance problems, be those from unoptimised software or just generally.

        And i'm running Win7 (which apparently can't be done...?) so if there is a patch released to cripple my machine then i'm not installing it on the basis that this bug doesn't affect AMD chippery anyway.

        And a point? The opposition has just slowed down by between 5% to 30%, depending on workloads. I think this has just handed AMD's Ryzen processor the performance crown.

        While I tend to roundly ignore benchmarks on the basis of them being utterly artifical and very unlike real world conditions i'd be very interested to see how much of a difference this makes.

        1. Naselus

          Re: I finally switch from AMD to Intel, and this is what happens.

          "While I tend to roundly ignore benchmarks on the basis of them being utterly artifical and very unlike real world conditions i'd be very interested to see how much of a difference this makes."

          Not enough. AMD's top offerings benchmark about 25% lower than Intel's. Unless Passmark have added a lengthy SQL operations section to their benchmarking this year, AMD are unlikely to be taking the top spot.

          In price-per-Ghz, on the other hand, they were already running away with, and this has just turned that into an even more substantial lead.

          1. kain preacher

            Re: I finally switch from AMD to Intel, and this is what happens.

            Watching video rending test shows that that it's more like 5% difference. and I mean test with people doing encoding actual not simulated test.

  4. Custard Fridge

    Can you hear it?

    That’s the sound of the world slowing down...

    1. Paul Herber Silver badge

      Re: Can you hear it?

      Well, that just about wraps it up for blockchain mining!

      1. Anonymous Coward
        Anonymous Coward

        Re: Can you hear it?

        I assume block chain mining can be done on custom os if really needed. Else other work arounds?

        1. werdsmith Silver badge

          Re: Can you hear it?

          I assume block chain mining can be done on custom os if really needed. Else other work arounds?

          Intel CPUs haven't been anywhere near powerful enough for blockchain on Bitcoin for many years. GPUs have also been left well behind.

          It's all ASICs.

        2. Mpeler
          Paris Hilton

          Re: Can you hear it? blockchain

          AMD should change the name from Threadripper to Chainripper.....

          Here's Paris looking for some chains right now............................................^

      2. Doctor Syntax Silver badge

        Re: Can you hear it?

        "Well, that just about wraps it up for blockchain mining!"

        I'd have thought that something computationally intensive would be least affected as it would make fewer syscalls.

      3. James 47

        Re: Can you hear it?

        > Well, that just about wraps it up for blockchain mining!

        Blockchain mining is CPU-intensive, not syscall intensive (if it is then you're doing it wrong)

    2. elDog

      Re: Can you hear it?

      And apparently the earth's core (magnetic, not DDR) is slowing down enough to cause massive earthquakes in 2018.

      I imagine that if one of those plate tectonic things decides to nudge its neighbor a bit more forcefully than usual then we won't really give two shits about a couple of nano-seconds off our processor speed.

      1. Destroy All Monsters Silver badge
        Devil

        Re: Can you hear it?

        And apparently the earth's core (magnetic, not DDR) is slowing down enough to cause massive earthquakes in 2018.

        Oh hey, someone found another copy of "Nostradamus' Terror Predictions That Are The Same As Last Year" while cleaning the attic on the 1st?

        I predict war with Iran on behalf of Israel btw. My bookie says odds are good.

        1. jelabarre59

          Re: Can you hear it?

          Oh hey, someone found another copy of "Nostradamus' Terror Predictions That Are The Same As Last Year" while cleaning the attic on the 1st?

          I've heard 2018 is the year of the USABLE MSWindows Desktop

    3. 45RPM Silver badge

      Re: Can you hear it?

      **Intel Marketing Memo - Strictly Confidential**

      OPERATION SNAILPACE

      You’ll have read in the press about this new ‘bug’ which cripples the performance of our CPUs - this applies, of course, only to older models for which we are no longer making any money. Unfortunately, customers had begun to notice that our latest chips are not significantly faster than our older models. With this exceedingly cunning plan we are now able to market our new silicon as 50% faster than the old stuff (after adding on the standard 20% hyperbole)

      This isn’t a one off either - from now on each tock will come with a crippling bug that destroys performance of older CPUs and each tick will fix the problem.

      But remember - this is top secret so don’t let the press find out.

  5. Inventor of the Marmite Laser Silver badge

    Dear Intel

    You owe me five laptops and one desktop.

    Please.

  6. Anonymous Coward
    Anonymous Coward

    Is it time?

    To just leave my Windows 7 install offline (except for games... I'm not expecting too much exploits through there) and Linux for online?

    I'll need a bigger SSD for the dual boot. :( But at least I'll be safe and avoid slow downs (30% on webpages in linux is ok, but not in games :( )

    1. Captain Obvious

      Re: Is it time?

      Read the article - Linux is affected too as well as Mac O/S

      1. Anonymous Coward
        Anonymous Coward

        Re: Read the article

        He did. Re-read his post.

        1. Peter2 Silver badge

          Re: Read the article

          If your running Amazon S3 or Microsoft's cloud then you can't possibly ignore this. The threat is really in multi user enviroments where one user could run software that compromises another.

          However, this is not so critically serious threat for a single user desktop. Ok, the flaw exists and can be exploited and could be as serious as a keylogger. But... we've been dealing with that with AV software since forever and one could choose to take a view that they could accept the risk of a malware infection that could exploit this in a single user enviroment.

    2. Pomax

      Re: Is it time?

      Short answer: no. The problem is in the cpu, not the OS, so your course of action is to either buy an AMD cpu, or use an older version of an OS that doesn't apply the throttling and then make sure you only use trusted software (e.g. an audio or video production workstation where you control every application that is installed and you don't browse random websites). Switching from Windows to a *n*x while keeping your affected cpu trades the same problem for the same problem.

    3. Flakk

      Re: Is it time?

      To just leave my Windows 7 install offline (except for games... I'm not expecting too much exploits through there)

      Ben, you might want to consider some additional research. Malware targeting online games and digital marketplaces has been around for quite some time. Comparatively speaking, game consoles probably offer a somewhat reduced attack surface, but hacks of both the PlayStation Network and Xbox Live attest that nothing is 100% secure.

  7. Dwarf

    How convenient

    Intel likely to sell a bunch of new chips - $PROFIT$

    How about a free issue replacement chip of the appropriate generation to everyone so that we don't have to have a performance penalty or for their mistake - think its called warranty. MS will probably need to disable the hardware change = new licence thing though.

    Intel could also regain trust by wrapping in the fixes for other big screw-ups too - like the management chip, which can be disabled or better still removed.

    Oh and don't forget all the microcode changes too.

    1. Anonymous Coward
      Anonymous Coward

      Re: How convenient

      Intel could also regain trust

      What, after this? And following so quickly on the Puma 6 fuckup, and the Intel Management Engine fuck up, and a good fistful of older mistakes. Intel are as trustworthy as Microsoft, Google, or even Uber. The US tech sector at its finest.

      Intel: Fuckups R Us.

    2. JohnFen

      Re: How convenient

      "Intel could also regain trust by wrapping in the fixes for other big screw-ups too - like the management chip, which can be disabled or better still removed."

      That wouldn't regain my trust at all. Trust is only regained over time, by having a track record of not doing bad things.

      1. Doctor Syntax Silver badge

        Re: How convenient

        "Trust is only regained over time"

        And a lot, lot more slowly than it gets lost.

    3. ~mico
      Flame

      Re: How convenient

      Ahh, an opportunity to phase out all those old, exposed and patched NSA backdoors with a bunch of new ones, globally, all while making nice profit selling new CPUs without upping any specs. How convenient indeed.

      1. CrazyOldCatMan Silver badge

        Re: How convenient

        all while making nice profit selling new CPUs without upping any specs

        What is this "selling" you speak of? I think you mean "replacing free of charge while not admitting liability..".

        1. ~mico
          Pint

          Re: How convenient

          replacing free of charge

          I don't see that happening, ever. Especially not for skylakes and older. The cost would be exorbitant, especially for all the machines where it's soldered on, like my new laptop. At best, they'll make a deal on class lawsuit, giving everyone $5 for their troubles.

      2. Eddy Ito

        Re: How convenient

        ... selling new CPUs without upping any specs. How convenient indeed.

        Technically it is upping the specs since the new processors wouldn't need to be kneecapped by software in order to be "secure". I imagine the marketing line will be something like 'our new processor run as fast as the old one was supposed to without pissing ring-0 data!'

        1. rnturn

          Re: How convenient

          You mean something like "the most secure Windows ever", then? (Until the next chip-level screw-up.)

          1. kain preacher

            Re: How convenient

            Well in all fairness if your hardware is compromised before the OS even loads it would matter what OS you use. This does affect linux too.

    4. Teiwaz

      Re: How convenient

      Intel could also regain trust by wrapping in the fixes for other big screw-ups too - like the management chip, which can be disabled or better still removed.

      That would be a step in the right direction, getting rid of their mis-management chip might help clear complications in design.

      It's like that damn IOT, always adding new 'features' and 'snoop'.

      When exactly did good sensible engineering go out the window in favour of marketing ideas which seemed great in endless ego preening meetings and then were badly implemented in a hurry on the way to the next ego preening session,..

      ...Just asking....I've not bought Intel since Atom. The only d/w purchase I regret of late, an Nvidia GPU, nothing but an ugly boot up and a series of weird incompatibilities...

      1. Doctor Syntax Silver badge

        Re: How convenient

        "When exactly did good sensible engineering go out the window in favour of marketing ideas"

        Probably about the time model numbers were replaced by names.

      2. Mark 85

        Re: How convenient

        When exactly did good sensible engineering go out the window in favour of marketing ideas which seemed great in endless ego preening meetings and then were badly implemented in a hurry on the way to the next ego preening session,..

        Relatively speaking....around the time that "return shareholder value" became a corporate catch-phrase and started being used in just about every corporate operation manual and press release.

    5. CrazyOldCatMan Silver badge

      Re: How convenient

      How about a free issue replacement chip of the appropriate generation

      Which *might* be OK for desktops and mini-PC formats (assuming that the processor isn't soldered in place) but isn't going to work for laptops (I've yet to see a laptop made in the last 20 years where the processor isn't soldered in place).

      Nope - it's going to have to be a nice new AMD-based MacBook Pro for me, paid for by Intel..

      (And 4 new Xeon chips for my server, without the bug plus compensation for the downtime and effort of replacement - probably easier for Supermicro to just send me a new server sans drives and let me just swap them over..)

      And 400 new processors for work.

      1. Peter Gathercole Silver badge

        Re: How convenient @CrazyOldCatMan

        You may be right about soldered processors in Ultra books or NetBooks, but I can assure you that many business laptops from people like IBM/Lenovo, HP and Fujitsu still have their processors in sockets.

        It's just the ones where the supplier does not care about maintenance and also tend to use glue to hold the systems together that don't.

      2. Vince

        Re: How convenient

        "Nope - it's going to have to be a nice new AMD-based MacBook Pro for me, paid for by Intel"

        Do you know something we don't about Apple's plans, because last I looked there was no AMD based MacBook Pro, and I doubt there will be.

  8. Anonymous Coward
    Anonymous Coward

    Want to bet Apple is considering expediting their homegrown A series chips into products that currently use Intel processors?

    Apple just released their iMac Pro that starts at $5000. How happy are they going to be telling their customers they’re about to see a 30% processor performance hit?

    Intel has been the Gold standard in processors, turns out it’s Copper Inside(TM).

    1. zarchasmpgmr

      Bet 1 Infinite Loop is rethinking their decision to switch from the Power chip. If Ginny were smart (we know she isn't), she'd be on a flight right now to Cupertino, with the latest Power and Z chip info.

      1. kain preacher

        The issue was making PPC laptop chip that was faster that would not cook your nads and kill you patter. That's why they were stuck at G4 when the desktop was at g5. then there was price and scale. Apple was going to get price on intel chips since they made way more then what IBM made.

    2. Anonymous Coward
      Anonymous Coward

      Apple has Intel at their beck and call via the implied threat to switch to AMD or their own SoC, they might be able to get Intel to supply replacement CPUs if the ones in the just-released iMac suffer from the bug. Issuing a recall and replacing the CPU for free would be good PR after the black eye from the iPhone battery business, and wouldn't cost a whole lot because they couldn't have sold that many of the new iMacs yet.

      1. lsatenstein

        It could be an expensive repair. The CPU chips are likely soldered in. Changing a cpu requires extraction wihile unsoldering, If there was a CPU socket, the repair is simplified

        1. Anonymous Coward
          Anonymous Coward

          The CPU isn't soldered in

          See the teardown: https://www.macrumors.com/2017/12/28/owc-imac-pro-teardown-2017/

          So not that difficult to replace, though they might want to replace the whole module that includes the CPU, GPU and common heatsink to make things simpler in the field.

        2. Peter Gathercole Silver badge

          @ lsatenstein

          I think you'll find that Core, i series and Xeon processors are all installed in sockets.

          Atom processors are designed in packages intended to be soldered onto system boards. Everything else is in sockets that allow the processor to be replaced. But the problem here is that Intel keep changing the socket design, so you just can't put new processors into old motherboards.

          This means that if you are upgrading a system piecemeal, rather than all at once, you end up having to replace not only the processor, but also the motherboard and probably the memory as well.

          I would very much like Intel to be forced to support older sockets for longer, so you could give a system a relatively non-intrusive processor upgrade without having to tear the whole system down.

          1. Teiwaz

            Re: @ lsatenstein

            But the problem here is that Intel keep changing the socket design, so you just can't put new processors into old motherboards.

            To be fair, AMd do that too, all that 'AM' number malarky so you're never 100% certain what you've bought is actually going to fit what you've got until they're both sitting in front of you and it's 'meccano time' Then there's all that fun with fans and coolers that make me sweat.

            1. kain preacher

              Re: @ lsatenstein

              do you read ? an AM4 cpu goes in an AM4 MB Am3 CPU in an AM3 board. it's really simple.

          2. collinsl Silver badge

            Re: @ lsatenstein

            The i5 soldered into the motherboard of my Lenovo x220 begs to differ

            The i7 models are the same too. And the x230 if memory serves.

        3. Hans 1

          It could be an expensive repair. The CPU chips are likely soldered in.

          That was by Apple's design, ach Schadenfreude ...

        4. CrazyOldCatMan Silver badge

          It could be an expensive repair

          Yup. Cheaper by far to replace the whole motherboard in one go. Unless your SSD is also soldered on. In which case it's a tad more complex.

          And would you trust your data to a hardware replacement company? Let alone having a problem with a Bitlocker or APFS-encrypted drive where the local key is in the TPM locker.

          I forsee that it could get very expensive for Intel, very, very quickly.

        5. Doctor Syntax Silver badge

          " If there was a CPU socket, the repair is simplified"

          Never mind the quality feel the (lack of) width.

    3. Mike Pellatt

      Intel has been the Gold standard in processors.....

      That was a joke, right ??

      Going right back to the original 80386 which had a pretty serious Virtual 8086 mode bug (it broke the EMM emulators, needed a motherboard fix), onto the Famous FP bug - "it's not a problem, it only happens every few million instruction executions...."

      All Intel have offered that's a "gold standard" is backwards compatibilty, and the only time they tried to drop that (at least in the hardware - Itanium), it didn't end well and let AMD in to define the 64-bit x86 architecture.

      Although, to be fair, the Itanium issues were more about the the difficulties with VLIW architecture.

      1. Dave K

        >>Intel has been the Gold standard in processors.....

        >That was a joke, right ??

        There have been other black marks too. The 3.8GHz Prescott P4s that throttle under repeated high load. The whole dirty Rambus saga, the 1.13GHz PIII that had to be recalled due to stability issues, the CPU serial number privacy scandal, etc.

        Although Intel seemed to have turned a corner since Core 2 Duo came along, they've made loads of previous muck-ups.

        1. Roo

          "Although Intel seemed to have turned a corner since Core 2 Duo came along, they've made loads of previous muck-ups."

          *cough*

          https://www.theregister.co.uk/2007/06/28/core_2_duo_errata/

    4. Adam 1

      Not sure Apple would be too concerned. There are easier ways to get root.

    5. CrazyOldCatMan Silver badge

      Intel has been the Gold standard in processors

      Not for those of us that remember all the errors they have made in the past (and the fact that you could heat your house off some of the pentium range of chips..).

  9. Anonymous Coward
    Joke

    Titsup?

    > At one point, Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka FUCKWIT, was mulled by the Linux kernel team, giving you an idea of how annoying this has been for the developers.

    Total Inability To Supply Usable Processors

  10. philthane

    No joy from Intel

    About 15 years ago I worked for a graphics software co that discovered a bug in Intel graphics chipsets. Our drawing software used a command (new I think in Win98) to draw a rectangle with a single command. Our competitors continued to use the old method of drawing four lines in consecutive steps (automatically from the user POV, but slower). Intel hadn't implemented the new command so our software suddenly crashed if a user tried to draw a rectangle. Other less elegant applications worked fine. We of course were blamed despite our devs making a simple demo app whose only function was to draw a rectangle, crash and log the problem. Intel refused to talk to us even after the company sent a copy of the app on disk via registered mail. We sent out an upgrade that probed the hardware before deciding which command set to use, which would have slowed the operation slightly but fortunately not really significantly.

    If your 'Intel Inside' PC suddenly goes 30% slower what chance they'll talk to you?

    Glad I use Linux on AMD.

    1. HmmmYes

      Re: No joy from Intel

      I worked for Intel.

      Other parts of Intel would not talk to us, even when we were finding significant issues with the silicon.

      The way intgl works is every now snd thrn, it thorws lots of silicon at the wall. Some stick. Some fall off. Some slowly slide down.

      Once a product meets an internal gate - poof - all the people go off and wotk in other stuff.

      1. Anonymous Coward
        Anonymous Coward

        Re: No joy from Intel

        In another life time I did onsite warty fix for IBM PC/laptops for Intel. We would get the occasional laptop wi fi does not work. We get the lap top in and it worked fine. Then one day we found out that all of these laptops were not working at star bucks. So you can guess what we thought. Then we found out that certain intel wi fi chips used an buggy driver that will no work on certain Cisco AP if channel 7 or 11 is used. Kind of like kissing a frog under a blue moon will cause the destruction of the earth. Turns out intel did have a driver update burred deep in their webs site. Kicker is you can never update the driver from IBM on windows again else you ran the risk of wi fi not working when waking up from sleep.(solution was another driver update from intel that was well hidden) You would thinking being we were fixing computers for intel some at intel would of told us.

      2. Anonymous Coward
        Anonymous Coward

        Re: No joy from Intel

        That's not new. All SoCs come with an errata sheet of hardware bugs that must be corrected by software. Be it Intel, AMD, ARM, Infineon, Qualcomm ... there is no such things as bug free hardware. That's because hardware validations are much more costly than software ones. A CPU vendor will not modify a verified design if a bug can be easily workaround with a software patch.

        That said, this Intel bug is of epic proportions. A huge optimization flushed down the toilet.

  11. schafdog

    Intel cheating like VW?

    Has they been doing this for years knowingly for performance gain against competition?

    1. Anonymous Coward
      Anonymous Coward

      Re: Intel cheating like VW?

      While possible it seems more a "don't ask don't fix". As the performance difference of fixing it in silicone I assume is a percentage point or two difference. But the percentage difference above is noted as 30% for some in software.

      So while Intel has an advantage, I think they could afford to give in that tiny bit and still lead. But if it slipped through... they could only keep going for risk of big problems if found out. And after 10 years? Well even I think the little "problems" will just go away... to then get told by tge Dr they are worse. :(

    2. Anonymous Coward
      Anonymous Coward

      Re: Intel cheating like VW?

      They cheated on their compiler already (it would not generate efficient code for non-Intel variants for things like SSE extensions), and got caught, and had to agree not to do it again.

      see for example http://www.agner.org/optimize/blog/read.php?i=49#49

    3. jelabarre59

      Re: Intel cheating like VW?

      Has they been doing this for years knowingly for performance gain against competition?

      It sounds closer to what I would call a "Pinto Defect" were I to make up a clever term (without all that nasty exploding gas tank business of course). I suspect Intel may have known, and hoped no one would notice (it was cheaper to ignore it tan to fix it).

  12. Anonymous Coward
    Anonymous Coward

    Where is the recall

    Is there actually a single intel chip that performs as advertised?

    What about their other platforms, do they make anything remotely secure, I ask as I seriously wonder if intel actually make anything that works properly or even just as advertised.

    For years intel has been allowed to hide it's fails and personally I think it is high time for their ignored coustomers to be put first for a change.

    1. HmmmYes

      Re: Where is the recall

      Nah.

      Stuff eaches the errata years later.

      Youll get a term like In certain situation this impossible to work around problem occurs, causing you to spend millions looking for a software error.

      1. kain preacher

        Re: Where is the recall

        "Stuff eaches the errata years later."

        You left out signing a NDA to read the real and or full errata

        Just imagine having to sign an NDA to read about a 5 year bug.

        1. whitepines
          Megaphone

          Re: Where is the recall

          Or, you could just develop on processors from a company that actually cares about transparency. Get a Talos with POWER9 and you know *exactly* what's going on in every corner of that chip. Or, stay with Intel and AMD and wonder just which proprietary blob or NDA-restricted and hidden silicon bug is interacting with your application in bad ways or leaking your GDPR-protected data....

          Or, use ARM. NXP has some nice little 2U boxes for sale, and there's lots of Chromebooks and such with ARM inside. Literally anything is better than x86 right now!

          1. Anonymous Coward
            Anonymous Coward

            Re: Where is the recall @whitepines

            IBM have had their share of processor bugs.

            I was working on an HPC account when we had to break it to the customer that there was a fault in one of the complex floating point instructions in Power 7 that could, under certain sequences of instructions, lead to unreliable results. The fix was to put a No-Op after each of the affected instructions (added by the compiler), resulting in a low single digit percentage performance hit.

            Because they were an HPC customer (with a very large number of processors in their systems), who were doing large amounts of floating point arithmetic, this was a concern to them.

            IBM ended up paying damages (I think it was by reducing the maintenance charges) to the particular customer I was working with. Not sure what happened to other customers.

            But at the end of the fiscal life of these systems (they were only about three and a half years old, but hey, there was new money to spend), they were still providing more than adequate performance, and the customer was a little sad to see them go (as was I, as it was the end of a very enjoyable assignment).

    2. lsatenstein

      Re: Where is the recall

      I believe that Intel makes a best effort. If not, rumors would have already destroyed the company.

      They hire engineers, these are mostly talented designers. A project is created to release a cpu update (same chip, only internal cpu number is up by one). All kinds or work and testing goes into the chip upgrade until freeze date. Thereafter, whatever is fixed is part of the new version number. If chip volumes are still significant, a new project would be created for the next bug fix release.

      You cannot have a trickle of fixes to silicon occurring as discoveries are found. The real attempt is to fix the problem with microcode updates.

      No, I consider that one releases versions, so as to be able to manage the manufacturing, distribution/supply chain and microcode releases.

      1. Flocke Kroes Silver badge

        Re: Where is the recall

        Employing the best engineers is no use when PHBs insist on RDRAM. I cannot see rumours doing Intel any damage whatsoever when headlines across the tech press never did any serious damage before. Take a look for Intel's previous epic cockups in the main stream news. If they are mentioned at all it is only a few words because non-techies will tune out the moment a news reader tries to explain what speculative execution and virtual memory translation buffers are. Outside the tech news this will be forgotten by Monday. Customers will keep buying Intel despite FUCKWIT because most of them do not realise they have a choice.

        Almost everyone who bought or sold Intel kit will pay for this mistake and only a small portion of the damage will land on Intel. A few of the big players like Google and Amazon might get a financial apology from Intel - if they can switch their orders to AMD/ARM. If you do not believe me, join the class action lawsuit and three year from now watch Intel settle ... with the lawyers.

    3. Anonymous Coward
      Anonymous Coward

      Re: Where is the recall

      "Is there actually a single intel chip that performs as advertised?"

      What is "advertised" ? Where have you seen the precise definition ?

      Yes, there are HW bugs, yes they suck and have been forever. And yes, this one is quit massively epic.

      But frankly, the "works as advertised" stance is meaningless. I'm sure 100% of your home appliances have also flaws, and and they are a LOT less complex, therefore more inexcusable.

  13. Chairman of the Bored

    Why not just hire a VW engineer...

    ...and just cock up the benchmarks to match? My bet is that you can get one just coming off parole really cheap. Just kidding. I hope.

    1. Anonymous Coward
      Anonymous Coward

      Re: Why not just hire a VW engineer...

      They did. Have you not seen Optane?

      (Though I admit it has potential in the future, all current benchmarks are cherrypicked)

    2. Giles Jones Gold badge

      Re: Why not just hire a VW engineer...

      So the benchmarks planning a car racing game will be good so long as you have the wheels facing forward?: )

  14. Steve Davies 3 Silver badge

    Slowing the CPU Down?

    Oh well, another few thousand lawsuiits will be heading in Apple's direction.

    (sic)

  15. Anonymous Coward
    Anonymous Coward

    New Laptop will use a Ryzen chip

    When the top end Intel chips have the software fixes applied and get the 5-30% performance hit the AMD Ryzen CPUs will out perform them. Can we adjusted benchmarks now?

  16. IGnatius T Foobar
    Facepalm

    Novell got it right

    Apparently, the folks at Novell got it right ... every program that ran on Netware was basically just a kernel extension. No userland to switch back and forth to. *grin*

    1. Adam 1

      Re: Novell got it right

      Back 15ish years, I had a part time job helping to maintain a Novell network. Mostly clearing jammed print queues, changing backup tapes, keeping Windows and AV signatures up to date and sorting out the big boss with a new monitor every other week. Oh, and every morning resetting the clock on the Novell server that lost near enough to 10 minutes a day. And every time a user signed in their local PC time got synced to the wrong time. By the time I would get back into the office it could be out by 30+ minutes.

      We got it fixed eventually. CMOS battery I hear you ask? No, nice try but guess again. Ah, your UPS? No, that was fine too. Come on, what's the obvious cause that you're missing? Oh of course, there must be a bug in the CDROM driver running on the wrong kernel ring and causing the ticks to be slightly slower than they should. Well spotted.

    2. Anonymous South African Coward Silver badge

      Re: Novell got it right

      Lovely ABEND errors if something did something naughty :)

  17. Michael Thibault
    Facepalm

    Ahhh, the beauty of a monoculture! Everyone suffers equally.

    "Suffice to say, this is not great." The article could -- probably should -- have started with that sentence.

    2018 is shaping up to be a major doozy for Intel. At least.

    1. Destroy All Monsters Silver badge
      Paris Hilton

      Re: Ahhh, the beauty of a monoculture! Everyone suffers equally.

      But people will be looking at optimizing code again.

      This *could* be a big deal in interesting applications that have real time constraints. Maybe.

  18. aaaa
    Happy

    Refunds and Compensation

    Companies like Apple that offer a 'no questions asked' refund policy are going to be very very busy refunding every Christmas gift with an 'Intel insude'. You think Apple (and other vendors) are just going to take that hit? Intel will be paying compensation to vendors for sure, certainly for every chip shipped in the past 3 months - but more likely 6-12 months since this will affect the pipeline and inventory too. Who's going to buy anything with 'Intel inside' unless the vendor can guarantee that it's new silicon?

    Consumer law will also come into play as Aqua Marina detailed in "I wonder where we stand legally now?" (above).

    But the really interesting thing will be whether companies like HPE go to bat for their enterprise support customers. Because that'll be a killer whitebox shakedown. i.e.: 'I bought HPE and they replaced my server CPU' and 'I bought a whitebox and now it runs 30% slower and I've got no recourse'. It's little cost to HPE and a marketing windfall - they just have to jump on the cueball-intel bandwagon.

    This is going to be good fun to watch.

    1. JLV
      Trollface

      Re: Refunds and Compensation

      Wow, this seems like a bad one. The PII floating point instruction was, IIRC, somewhat of an unlikely bug to happen, which is why it took a long time to spot - it really didn't affect most people too often and Intel could probably claim it worked well enough for most users. In any case, quoting Wikipedia

      On December 20, 1994, Intel offered to replace all flawed Pentium processors on the basis of request, in response to mounting public pressure.[5] Although it turned out that only a small fraction of Pentium owners bothered to get their chips replaced, the financial impact on the company was significant.

      A really nasty security exploit doesn't have that unlikely-ness protection - every black hat is going to have at it.

      If Intel did the decent thing and replaced the CPUs (very unlikely) to their OEMs and assuming warranty/fit-for-purpose protections do their job and force vendors to make good (equally unlikely)...

      then Apple may suddenly rue their tendency to solder things everywhere. Ditto for the Surface and its well-publicized glue-it-all.

      1. Adam 1

        Re: Refunds and Compensation

        One of the compilers that I use still has an option for Pentium safe floating point division. A lot of people didn't bother swapping them over I guess because OS and compiler vendors whacked together a quick work around and pulling out a CPU is beyond the technical knowledge of most.

        Either way, I'm not looking forward to this patch. No customer is going to call support and say "hey there, because of Intel's screw up we're not getting adequate performance". It's going to be a bunch of your product is a bunch of ... Fix it yesterday.

      2. PNGuinn
        Trollface

        Re: Refunds and Compensation @JLV

        PSSST!

        Q. How many Intel Enjineers does it take to change a lightbulb?

        A. None. Someone broke in and stole the new lightbulb.

        Go on - you know you want to ...

    2. Anonymous Coward
      Anonymous Coward

      Re: Refunds and Compensation

      Apple would be able to force Intel to provide replacement CPUs to them to deliver into purchases over the last x days/months, thanks to their implied threat to switch to AMD or their own SoC. Maybe even pay the costs of the recall.

      Intel will just ignore the PC OEMs, because they can't make changes overnight to switch and will forget about it by the time it could happen when Intel throws some marketing dollars their way.

    3. Flocke Kroes Silver badge

      Re: Refunds and Compensation

      Take a look at what happened with the memory translation hub. Intel will watch calmly while the smaller vendors get sucked into the wood chipper. Even if the big distributors get free replacement chips from Intel, the cost of distribution and installation will land on the distributors. Anyone - big or small - who soldered Intel CPUs to the PCB is in for a world of hurt.

    4. Nick Ryan

      Re: Refunds and Compensation

      Given that when Cisco was royally screwed over by Intel's Atom issues and subsequently has just passed the costs onto buyers of their kit, what do you think will happen with this latest Intel failure? Pretty much the same and I'm pretty sure that Intel's contracts (hidden under several miles of NDA) will disclaim any responsibility for anything.

  19. Down not across

    10 years?!

    It is understood the bug is present in modern Intel processors produced in the past decade. It allows normal user programs – from database applications to JavaScript in web browsers – to discern to some extent the contents of protected kernel memory.

    That's taken long time to surface then.

    Guess it has been quite useful for 5-eyes.

  20. Herby

    Genetic Diversity?

    Given that a major share of the CPUs out there are from one vendor, this is what you get. A hardware bug that permeates over several chips. Nice to see that AMD (minority report) doesn't have the problem.

    Maybe Chipzilla Intel is too big and needs to be sliced and diced.

    Thought experiment: What would Intel be if IBM had picked a different processor for its PC back in 1981 (Motorola 68000?)?

    1. Pascal Monett Silver badge

      Re: Genetic Diversity?

      And that would change what, exactly ?

      We'd be griping about a bug in Motorola processors instead. Whoop-de-doo.

    2. Trilkhai

      Re: Genetic Diversity?

      >What would Intel be if IBM had picked a different processor for its PC back in 1981 (Motorola 68000?)?

      I'm guessing Intel would be a footnote in that case… Question is, how would the market have turned out if IBM had chosen Motorola's 68000 or Texas Instruments' 16-bit TMS9900?

      1. Dan 55 Silver badge

        Re: Genetic Diversity?

        There'd have been Amigas and Macs everywhere as software would have been easy to port and nobody would have bought a PC if they could have chosen one of the other two machines.

        Also Microsoft wouldn't exist as they only got where they were today by making quick and dirty ports onto x86 and Windows.

        It'd have been brilliant.

        1. Destroy All Monsters Silver badge
          Paris Hilton

          Re: Genetic Diversity?

          Nah.

          National Semiconductor's 320X CPUs were pretty nice. And if Moto had finally succeeded in doing the 880000, who knows.

      2. Robert Sneddon

        68000 versus 8086

        The 68000 wasn't ready for production when IBM were looking for a CPU for the desktop PC (Back in the early 80s I played around with a dev board where the 68k was clocked down to 4MHz, half its rated speed). Motorola also didn't have the support chips needed to build a complete system so everything like interrupt controllers, floppy disc controllers, UARTs, graphics chip drivers etc. would have to be implemented with lots of TTL.

        The 8086 (and the version IBM actually used, the 8-bit-bus 8088) was designed to use existing 8080-series support chips, being bus-compatible with the older device. In addition its internal registers and addressing modes were also backwards-compatible so migrating existing programs from 8080-series CP/M versions was piss-easy. The 68000's "clean sheet" instruction set and internal register structure meant everything would have to be rewritten from scratch, especially boot code, low-level device drivers and kernel code.

        1. Peter Gathercole Silver badge

          Re: 68000 versus 8086 @Robbert Sneddon

          Whilst I don't have the experience of the 68000 that you obviously had, I believe that there were a significant number of support chips from the 680X 8-bit family that worked with the 68000.

          I'm trying to think back, but I'm sure I saw a working 68000 system around the time that the IBM PC was new. Of course, that could have been because small companies were more agile than IBM, but I think that the IBM PC was a very quick development which didn't start until 1980, a year after the 68000 was released.

          No, I think that the reason why IBM went with Intel was mainly cost.

          If the 68000 had been chosen for the single-tasking, floppy disk only original IBM PC, I think that we would have had multi-tasking desktop systems much earlier, because the 68000 was designed as a 32 bit family of processors from the outset, rather than being an 8/16 bit kludge of a processor that the 8088 and 8086 processors were (and became worse still with 32 bit and 64 bit evolutions)

          1. Phil O'Sophical Silver badge

            Re: 68000 versus 8086 @Robbert Sneddon

            Whilst I don't have the experience of the 68000 that you obviously had, I believe that there were a significant number of support chips from the 680X 8-bit family that worked with the 68000.

            There were indeed, the 68K was designed to be compatible with them, and would switch to a synchronous bus cycle when it detected a 68xx peripheral. I remember using 68xx-series UARTs with them, as well as the 68230 parallel/timer chip.

            I'm trying to think back, but I'm sure I saw a working 68000 system around the time that the IBM PC was new.

            The Sun-1 would have come out around the same time, with the Sun-2 and Sun-3 roughly aligning with the PC-AT and PC-XT286s.

          2. jelabarre59

            Re: 68000 versus 8086 @Robbert Sneddon

            No, I think that the reason why IBM went with Intel was mainly cost.

            I had been to a talk some years back (probably like 25 years ago) given by one of the original IBM-PC designers. The story I heard there was even more ironic, given the situation these days. IBM had been concerned at the time about having multiple sources for all the components. At the time the 68000 was only sourced from one location, while Intel had licensed the 808x processors to multiple manufacturers.

            Ironic in that Intel has long since decided they wanted to be the only manufacturer of their chips. Had the manufacturing situation back then been like it is now, IBM would have gone with the ARM (OK, the equivalent would probably have been the Z80).

        2. Stoneshop

          Re: 68000 versus 8086

          Motorola also didn't have the support chips needed to build a complete system so everything like interrupt controllers, floppy disc controllers, UARTs, graphics chip drivers etc. would have to be implemented with lots of TTL.

          Bollocks. With peripherals there are some support chips you actually want from that particular CPU family to make life easier, but as long as those UARTs, FDCs, video controllers etcetera use the same signal levels and are roughly compatible with regards to clock speed, then you can just mix and match with maybe a bit of address select and glue logic. And custom chips to do the heavy lifting regarding tacking all those things together were quite common back then already

          Look at the Acorn BBC B: 6502 CPU. 6845 CRT controller. 6850 ACIA (UART). 6522 VIA. Two custom ULAs, which replace several tens of 74xx logic gates each. uPD7002 ADC. 8271 FDC.

          And the IBM PC? It was actually using that same Motorola 6845 CRTC for its MDA and CGA interfaces.

          1. Robert Sneddon

            Re: 68000 versus 8086

            ULAs weren't available in the early 1980s hence the IBM's use of lots of TTL to get it to work at all. Yes the 68000 eventually got a number of dedicated support chips but that was a long time after the original IBM PC was in production. I think the 68008 (the cut-down 8-bit-bus version of the full-sized 68k) which any 68k-based IBM desktop would have used was also late.

            The 68000's bus was asynchronous, relying on a data-available strobe from each peripheral and memory controller which was tricky to make work with regular clocked peripherals. It had advantages, it made mixing slow and fast devices on the CPU bus easy but it didn't work easily with the simpler existing chip families, not even the Motorola 8-bit designs like the 6800. It could be bodged to do so (I designed circuitry to do just that back in the day) but it took extra glue logic and wasn't elegant.

            IBM had to go with what they could buy in predictable quantity numbers at a decent price that would do the job and the 68000 just wasn't there when the door closed.

            1. Stoneshop

              Re: 68000 versus 8086

              ULAs weren't available in the early 1980s hence the IBM's use of lots of TTL to get it to work at all.

              So the ZX81 and BBC B were built with technology that didn't exist? Interesting.

              Now if IBM decided to just use standard components, that's another matter. But ULAs and other MSI-level custom chips were definitely available at the time the PC was designed.

              1. Peter Gathercole Silver badge

                Re: 68000 versus 8086

                ULAs (Uncommitted Logic Arrays) were a UK innovation, mainly designed by Ferranti.

                They allowed some of the layers of the wafers to be a common design, with the last few acting as a customization to get the chip to do what was needed. You could think of them as a half-way house to an FPGA, but with the configuration baked into the last few layers of silicon rather than after manufacturer.

                I don't believe that any US company really bought into using ULAs, but they were used, as already pointed out, for the ZX81, BBC Micro, ZX Spectrum and Acorn Electron to reduce the chip count.

                But production problems with ULAs were one of the main reasons why several of these systems were delivered late. Ferranti eventually disappeared into Marconi, which was sold off when that company went bust, so the technology disappeared.

    3. alain williams Silver badge

      Re: Genetic Diversity?

      Thought experiment: What would Intel be if IBM had picked a different processor for its PC back in 1981 (Motorola 68000?)?

      Oooh - that would have been nice. An unsegmented 32 bit memory space, unlike the intel 16 bit, then memory segments, ... Although the Intel CPUs came with a defined MMU (Memory Management Unit) which the M68k chips did not; I seem to remember 3 different sorts of M68k MMUs floating around.

      If IBM had gone M68k, would Bill Gates have been able to get in on the act ? We might be living in a very different world in which Amiga was the big boy.

      1. Brian Miller

        Re: Genetic Diversity?

        Of course Bill Gates would have gotten in on the IBM PC if it had used the 68000. The problem was with Digital Research not signing an NDA. So Gates would have still made a DOS for IBM.

        1. Doctor Syntax Silver badge

          Re: Genetic Diversity?

          "So Gates would have still made a DOS for IBM."

          Not "still made". Just "made" instead of "bought".

      2. Nick Ryan

        Re: Genetic Diversity?

        Well we'd have a much nicer assembly language to deal with. I still cry on the, admittedly now very rare, occasions that I have to drop down to x86 assembly level debugging and suffer the brain ache of an architecture that produces code that often seems to spend more time swapping values between limited registers than doing anything overly useful.

    4. Doctor Syntax Silver badge

      Re: Genetic Diversity?

      "What would Intel be if IBM had picked a different processor for its PC back in 1981 (Motorola 68000?)?"

      Z8000?

    5. Dave 13

      Re: Genetic Diversity?

      Monoculture os a knife with no handle, incredibly sharp, but prone to the occasional loss of a finger.

  21. Paratrooping Parrot
    Mushroom

    List of CPUs affected?

    Is there a list of CPUs affected? I have an old Arrandale based Core i3 laptop. Would that be affected? Do we have to wait for the embargo to be lifted? Will Windows 7 be updated as well?

    1. TonyHoyle

      Re: List of CPUs affected?

      Presently it's assumed to be all intel CPUs, with newer ones (<2 years) having extra instructions that drop the hit on benchmarks to 'only' 30%.

      Windows 7 is on extended support, so should get a patch, but that's up to microsoft.

  22. Anonymous Coward
    Anonymous Coward

    So mcuh bullshit, so little time

    Remember the P67 Chipset. I laid down big $$ for a i7 2600k and had to yank my intel mobo and send it back to Newegg then I had to relicense WinDoze on the replacement board they sent me.

    The P67 failure and complete recall details were always reported sketchy but allegedly the speed of the chipset degraded 6% over two years.

  23. Anonymous Coward
    Anonymous Coward

    Remember the P67 Chipset fiasco/recall. I plunked down $$$for an I7 2600k and had to yank the mobo and send it back for a new one, then deal with microshaft for another Windows 7 license. Details released on the design flaw of the P67 were sketchy but the fact intel stood by was the recall wwas due to the fact that the speed of the chipset reuce 6% of 2 years.

    Never got even an apology from anyone.

  24. DXMage

    NSA specific bug?

    I have to wonder if this wasn't something that the NSA insisted get put in under the whole umbrella of "National Security".

    1. tim292stro

      Re: NSA specific bug?

      > I have to wonder if this wasn't something that the NSA insisted get put in under the whole umbrella of "National Security".

      No, No.... you don't get it. The NSA doesn't need to "put things in". The Clipper Chip demonstrated to them that if they applied themselves a bit like they do with TEMPEST, they could find the stuff idiots put in themselves, and just get back to work reading things plain text. As "idiots" who didn't work for the NSA were able to crack the protections. This demonstrated that their adversary was more technically capable than they expected themselves to have to be.

      In the computer world companies are pretty well matched on what they can do within a given instruction set architecture, so they have to find ways to "cheat" more performance out of a given ISA in order to get their competition over a barrel. There is an engineering axiom "You don't get ANYTHING for NOTHING". What we have here is the problem being improperly constrained from an engineering standpoint - someone said: "Let's get more performance without using more power or area on the die." Nobody said: "Let's get more performance without using more power or area on the die, and without impacting security".

      It's a common theme seen all over tech that security is considered an after-the-fact-add-on, rather than integral to the design. The NSA knows that, and they can demand the full documented ISA from Intel and we'd never know it - the government are also not obligated to inform Intel of any problems found. Kind of like the FBI doesn't need to tell Apple how they cracked those phones after the terrorist shooting. They can just quietly go about their jobs and no one needs to be the wiser (one of the reasons I wish the FBI would just shut up about the encryption back-door thing). I think these agencies talk too much for their own good.

  25. CheesyTheClown

    Counting chickens?

    First, this is news and while I don’t buy into the whole fake news thing, I do buy into fantastic headlines without proper information to back it up.

    There are some oddities here I’m not comfortable with. The information in this article appears to make a point of it being of greatest impact to cloud virtualization, though the writing is so convoluted, I can’t be positive about this.

    I can’t tell whether this is an issue that will actually impact consumer level usage. I also can’t tell whether there would actually be 30% performance hit or whether there would be something more like 1% except in special circumstance. The headline is a little too fantastic and it reminds me of people talking about how much weight they lost... and the include taking off their shoes and wet jacket.

    Everyone is jumping to conclusions that AMD or Intel is better at whatever. Bugs happen.

    Someone claims that the Linux and Windows kernels are being rewritten to execute all syscalls in user space. This is generally crap. This sounds like one of Linus’s rants about to go haywire. Something about screwing things up for the sake of security as opposed to making a real fix.

    Keep in mind, syscalls have to go through the kernel. If a malformed syscall is responsible for the memory corruption, making a syscall in another user thread will probably not help anything as the damage will be done when crossing threads via the syscall interface.

    Very little software is so heavily dependent on syscalls. Yes, there is big I/O things, but we’re not discussing the cost of running syscalls, we’re talking about the call cost itself. Most developers don’t spend time in dtrace or similar profiling syscalls since we don’t pound the syscall interface that heavily to begin with.

    Until we have details, we’re counting chickens before they’ve hatched. And honestly, I’d guess that outside of multi-tenant environments, this is a non-issue otherwise Apple would be rushing to rewrite as well.

    In multitannant environments, there are 3 generations Intel needs to be concerned with.

    Xeon E5 - v1 and v2

    Xeon E5 - v3 and v4

    Xeon configurable

    If necessary, Intel could produce 3 models of high end parts with fixes enmass and insurance will cover the cost.

    Companies like Amazon, Microsoft and Google, may have a million systems each running this stuff could experience issues, but in reality, in PaaS, automated code review can catch exploits before they become a problem. In FaaS, this is not an issue. In SaaS this is not an issue. Only IaaS is a problem and while Amazon, Google and Microsoft have big numbers of IaaS systems, they can drop performance without the customer noticing, scale-out, then upgrade servers and consolidate. Swapping CPUs doesn’t require rocket scientists and in the case of OpenCompute or Google cookie sheet servers shouldn’t take more than 5 minutes per server. And to be fair, probably 25% of the servers are generally due for upgrades each year anyway.

    I think Intel is handling this well so far. They have insurance plans in place to handle these issues and although general operating practice is to wait for a class action suit and settle it in a fashion that pays a lawyer $100 million and gives $5 coupons to anyone who fills out a 30 page form, Amazon, Google and Microsoft have deals in place with Intel which say “Treat us nice or we’ll build our next batch of servers on AMD or Qualcomm”.

    I’d say I’m more likely to be effected by the lunar eclipse in New Zealand than this... and I’m in Norway.

    Let’s wait for details before making a big deal. For people who remember the Intel floating point bug, it was a huge deal!!! So huge that after some software patches came out, there must have been at least 50 people world wide who actually suffered from it.

    1. Anonymous Coward
      Anonymous Coward

      Re: Counting chickens?

      The KPTI patches force all syscalls to go through a translation so the kernel gets mapped in/out of memory for each call. This is expensive, and up till now would have been called pointless.. there's a reason Linus wanted to call it 'Fuckwit'.

      Do you imagine Linus would have let this in if it was as low impact as the floating point bug? He'd have had one of his famous rants and told them to go away and think again. Instead he basically fast tracked it - even into the stable kernel which is a major deal in itself. Microsoft have done the same..

      1. Dwarf

        Re: Counting chickens?

        Talking about chickens, don’t processors have an array of “chicken bits” to allow chunks of functionality to be disabled, I wonder if those would help resolve the issue at a lower cost than the rumoured 30% performance hit

      2. rob_leady
        Linux

        Re: Counting chickens?

        Reading the comments on the kernel mailing list, it doesn't appear that it was just Linus who wanted to call it Fuckwit, if at all...

        https://lkml.org/lkml/2017/12/4/709

        2) Namespace

        Several people including Linus requested to change the KAISER name.

        We came up with a list of technically correct acronyms:

        User Address Space Separation, prefix uass_

        Forcefully Unmap Complete Kernel With Interrupt Trampolines, prefix fuckwit_

        but we are politically correct people so we settled for

        Kernel Page Table Isolation, prefix kpti_

        Linus, your call :)

        https://lkml.org/lkml/2017/12/4/758

        On Mon, Dec 4, 2017 at 6:07 AM, Thomas Gleixner <tglx@linutronix.de> wrote:

        >

        > Kernel Page Table Isolation, prefix kpti_

        >

        > Linus, your call :)

        I think you probably chose the right name here. The alternatives sound

        intriguing, but probably not the right thing to do.

        Linus

      3. stephanh

        Re: Counting chickens?

        Amen. A 5%-30% performance impact, with major changes to fundamental kernel operation? And no epic Linus rant on even the merest suggestion to merge this, but rather fast-tracked and back-ported to a stable kernel version?

        Let's face it: hell has indeed just frozen over.

        1. Dan 55 Silver badge

          Re: Counting chickens?

          Don't worry, Hell has thawed, Linus has just ranted.

          1. Intractable Potsherd

            Re: Counting chickens? @Dan 55

            Not really a rant, though, is it - more of a "WTF?"

          2. anonymous boring coward Silver badge

            Re: Counting chickens?

            I think most of us know that Linus has little time for idiots and PR, and being PK isn't very high on his agenda either. More power to him!

    2. tim292stro

      Re: Counting chickens?

      @CheesyTheClown

      > The information in this article appears to make a point of it being of greatest impact to cloud virtualization, though the writing is so convoluted, I can’t be positive about this.

      Imagine you are running your company's data sharing with manufacturing in a cloud hosted server on shared hardware. This bug basically means that if any other service run in user-space on the same shared hardware had the code required to poke at the kernel, it could bypass ALL virtualization boundaries and take ownership of the whole platform at Priv-0 level. Essentially, if this bug is not quashed and RAPIDLY, the entire virtualization market on these Intel platforms is at risk - as well as the sanctity ad security of the data currently trusted to this market.

      > Keep in mind, syscalls have to go through the kernel...

      Yeah, and now imagine that you have to stop everything that needs an interrupt so the kernel can lock down and handle kernel level operations while the rest of the user-space tasks sit there and twiddle their thumbs... every time this happens. That's potentially a 5 millisecond hit every 15 milliseconds, and that's where the potential of the performance impact lies. Systems that have a kernel-level VM handler running at Priv-0, will have to UNLOAD anything belonging to a less privileged worker so that it can flush the speculative cache, then handle the kernel task and flush again to continue with the VM guest tasks.

      There are some systems that will have a much worse impact than others, for example machines that run over-provisioned guest VMs that need to share a common resource pool will be impacted more during the VM switching (reduces the value of each VM host), machines that run VoIP bridges have a 125uSec interrupt for analog sample-to-packet timing. Machines that do anything with a physical serial port will trip interrupts constantly.

      > I think Intel is handling this well so far. They have insurance plans in place to handle these issues and although general operating practice is to wait for a class action suit and settle it in a fashion that pays a lawyer $100 million and gives $5 coupons to anyone who fills out a 30 page form, Amazon, Google and Microsoft have deals in place with Intel which say “Treat us nice or we’ll build our next batch of servers on AMD or Qualcomm”.

      Well you may be bitter and think that your buying dollar (or Krone), doesn't provides any power anymore, but the truth couldn't be farther from that. Yeah, so you're aware that Intel will slime their way out of it, that has a PR cost. Yes AMD has CVEs, but I can't recall them having a Pentium 90 math coprocessor issue like Intel, a SATA failure like SandyBridge, a Floating Point bug that needs to be fixed in SW (by third parties), a Management Engine that can't be turned off that leaves systems exposed unless you stop feeding the system power, and now this cache accelerator bug that can adjust performance numbers down to 0.66% of the advertised specs under the only SW fix available (again done by third parties). I'm also aware that the tempo of fairly embarrassing problems are increasing, so if I were a person building a system and saw an increase in the level of ineptitude from a multi-national company, and they only left me with a stack of paper to fill out for my $50 and a still broken POS system that 30% slower than the day I bought it, I'd be so jaded I wouldn't buy their crap any more (and I wouldn't be alone).

      If I worked for the Intel PR team in the EU, the first thing I would have thought when reading this article is "uff da..." Even Apple can't get away with a known design flow affecting the product near the end of the design life - see their battery fiasco as of late. Allowing your lawyers and your insurance to cover your screw ups only works a few times... Personally I foresee an investor meeting where someone's head is going to need to be offered as a result of the stock price hit.

      1. david 12 Silver badge

        some systems that will have a much worse impact

        >There are some systems that will have a much worse impact than others, for example machines that run over-provisioned guest VMs that need to <

        Hmmm. Does this mean it will have no impact at all on my WinXP virtual macines on ESXi 4, because (apart from the fact all components are out of support), wasn't this context switch on every interupt the reason XP ran so crap on ESXi 4 ?

        1. tim292stro

          Re: some systems that will have a much worse impact

          > Hmmm. Does this mean it will have no impact at all on my WinXP virtual machines on ESXi 4, because (apart from the fact all components are out of support), wasn't this context switch on every interrupt the reason XP ran so crap on ESXi 4?

          If you're running an ESXi that old and an OS that old, it doesn't sound like "patching" is in your world-view, so yeah it wouldn't "impact" you more than knowing your system is more vulnerable today than you knew it was it was yesterday. ;-)

          1. david 12 Silver badge

            Re: some systems that will have a much worse impact

            >so yeah it wouldn't "impact" you more than knowing your system is more vulnerable today than you knew it was it was yesterday. <

            Well, interesting point: if it was this relentless context switching that made XP run slower than Win7, and made XP run like crap on VMWare, it would seem to indicate that XP is immune.

      2. Anonymous Coward
        Anonymous Coward

        Re: Counting chickens?

        "Yes AMD has CVEs, but I can't recall them having a Pentium 90 math coprocessor issue like Intel, a SATA failure like SandyBridge, a Floating Point bug that needs to be fixed in SW (by third parties), a Management Engine that can't be turned off that leaves systems exposed unless you stop feeding the system power, and now this cache accelerator bug that can adjust performance numbers down to 0.66% of the advertised specs under the only SW fix available (again done by third parties)."

        So much this! (PS - I'm sure you meant 66% rather than 0.66%)

    3. Dan 55 Silver badge

      Re: Counting chickens?

      Initial benchmarks say there's an 18% hit on I/O heavy operations on Linux.

      https://hothardware.com/news/intel-cpu-bug-kernel-memory-isolation-linux-windows-macos

      Click through to Phoronix to see more Intel share price graphs.

  26. The Kernal

    no news

    I'll be surprised if this shows up anywhere besides El reg. if it does make the majors here in the states they will trivialize the issue and in the end, all the tech inept populace will ignore the baffling techno jibber-jabber they just heard because it wasn't explained in a catchphrase.

    1. Anonymous Coward
      Anonymous Coward

      Re: no news

      They already have a witty catchphrase: FUCKWIT.

      The networks will have to censor it a bit to pass the priss factor, but with a name like "Fartwit" to toss around the public will be all over it like... well... like Intel on a math error. *Cough*

      1. Dave 126 Silver badge

        Re: no news

        But really, for the tasks the average user puts their laptops to, they won't notice a performance hit. They might notice a battery hit, but many CPUs are faster than their user's needs. The enthusiasts (gamers etc) and professionals may notice, and they the types more likely to read tech blogs.

        1. CrazyOldCatMan Silver badge

          Re: no news

          and professionals may notice

          And *all* the big cloud providers will now need to buy 25-30% more hardware to meet the expected capacity plan. I don't imagine that Google/Amazon/Microsoft are going to be too chuffed with Intel right now. And since they (with Apple/Twitter/Facebook et. al) are probably the biggest buyers with the most clout their voice is going to count.

          If they all switch to buying AMD (assuming AMD has the capacity to build that many processors) or re-tool for ARM then Intel sales are going to nosedive.

    2. Dave 126 Silver badge

      Re: no news

      The story is on Slashdot and Gizmodo. As for the awareness of the mass populace, it might come to them when more details arrive - or they have available headspace following the FCC's Net Neutrality shenanigans.

    3. Ken Hagan Gold badge

      Re: no news

      21 hours after you posted that, I can report that it is on the front page of the BBC news website and at least one major UK newspaper. Yes, that surprises me, too, but perhaps it is just too good a *story* to pass over and, after all, even normal people use computers these days.

    4. el_oscuro

      Re: no news

      https://www.reuters.com/article/us-cyber-intel/intel-working-to-fix-security-flaw-in-its-chips-without-slowing-computers-idUSKBN1ES1BO

  27. Will Godfrey Silver badge
    Happy

    Phew!

    Fortunately, last November I'd already decided my next computer would be an AMD Ryzen. It's being built this month.

    1. whitepines
      Big Brother

      Re: Phew!

      Don't finish that sigh of relief. Your new Ryzen box is under the permanent control of anyone with AMD's signing keys via the PSP. Think remote network access below the hypervisor, in a critical processor inside your processor, just waiting to be exploited.

      Scared yet?

      1. conscience

        Re: Phew!

        @whitepines

        You mean like Intel's Management Engine? I'd much rather have AMD, at least they work as advertised and (as yet) aren't known to be full of security flaws like the Management Engine is. Obviously I'd rather have no 'security' processor whatsoever inside my CPU, but given the known bugs with Intel's Management Engine I'd still rather take my chances with AMD.

        Ryzen is already a far better deal than Intel's offerings, especially when you factor in this latest flaw that makes Intel's chips run even slower than advertised. Intel trying to flog buggy, half-working hardware is getting beyond a joke.

        1. whitepines
          Stop

          Re: Phew!

          @conscience

          Oh, I fully agree on the ME, but AMD is just the other side of the same coin. You need to look beyond x86 to have any chance of getting away from the security problems and general bugginess of both Intel and AMD.

          The simple fact is, the ME just got done being put under the microscope in 2017, and it was found to be swiss cheese. It wasn't even looked into for the previous near-decade it was present on Intel platforms, and for all that time it looked impenetrable / no one cared.

          Read that last sentence again. Something can have 0 CVEs published just because none of the "good guys" bothered to try to hack it.

          Before assuming the PSP is better "just because it's AMD", wait for the PSP to eventually go under that same microscope. I'm sure at least one critical bug will be found, that's really the nature of having closed-source secret sauce "god-mode" security processors built into your chips.

          For what it's worth, I prefer civil discussion to anonymous downvotes, too!

        2. Captain Obvious

          Re: Phew!

          What has stopped me from the Ryzen which I almost bought the 16 core for $699 on sale was the fact it had issues with Hyper-V running 32 bit VM's and other Hyper-V issues such as features not supported on AMD. If they had the full support, Ryzen 1950x would certainly have been my next choice.

    2. Anonymous Coward
      Anonymous Coward

      Re: Phew!

      So you think the security problems in the world don't matter other than the influence of which processor you buy. So shallow. Sad!

      1. Doctor Syntax Silver badge

        Re: Phew!

        "So you think the security problems in the world don't matter other than the influence of which processor you buy"

        Focus. Tackle each issue in its own place. We've discussed other security issues in other contexts. Actually, in this context, the issue isn't so much the security issue, because like many others, it can be fixed, but the cost of fixing it.

  28. sveinskogen

    Designed on a P54c?

    Isn't it time that the Intel chip designers stop using the P54c chips intel couldn't flog off to unsuspecting idiots?

  29. robjcamb

    Already exploited?

    I wonder if anyone at the NSA/GCHQ/<insert government surveillance agency> is pissed about this being publicly discovered.

  30. tim292stro

    So Intel ME is broken, and the VMM is broken, sounds like Intel completely forgot how to make CPUs while they enjoyed their market dominance - probably a good time to switch out to Power or take another look at AMD again IMHO.

    1. Trilkhai

      I agree... I decided just last night to start hunting a replacement for my failing Thinkpad T400 with a newer (used) laptop, and I'll definitely be giving the AMD options a more serious look than I would have otherwise.

      1. whitepines

        What about switching away from x86 and putting the security disasters inherent in this particular over-complicated duopoly permanently to rest?

        1. ecofeco Silver badge

          Suggestions? Sincerely.

          1. Brian Miller

            Seriously the only suggestion is to jump to ARM. The Qualcomm 44-core will be coming out this year. As for realistic alternatives, there's only AMD and Intel. We'll have to wait and see what the real impact is, based on benchmarks.

            1. Anonymous Coward
              Anonymous Coward

              Seriously the only suggestion is to jump to ARM.

              Or SPARC?

            2. JonHendry

              Somewhere at Intel some poor sod is thinking "Now is Itanium's chance to shine!"

          2. Doctor Syntax Silver badge

            "Suggestions? Sincerely."

            He's been pushing Talos. Providing they have a product in the format you need supported by the S/W you need...

            1. whitepines
              Linux

              @Doctor Syntax

              On the desktop and server end absolutely, but that's an awful big chip to stuff in a laptop. For laptops or small desktops I've been recommending ARM mostly, since ppc doesn't have anything decent in that space. Of course, if you run Windows you need x86, but if you run Linux you're probably mostly set to switch already.

              ARM just got a lot more competitive against a 30% slowed Intel laptop processor, that's for sure!

          3. d3vy

            Ecofeco.

            My suggestion is wait a few months for people who are concerned about this issue to replace their CPUs with whatever intel brings out (or AMD).

            I'm expecting the second hand market to be flooded with cheap intel chips in the next few months. I might be able to upgrade my 2nd gen i7 for something much faster (even with the performance hit) for very few ££!

      2. collinsl Silver badge

        Just get a T420 and be glad, or an X220 if you want smaller.

        Come over to /r/thinkpad and check out your options!

  31. Anonymous Coward
    Devil

    If these news came before xmas...

    ... I would have liked to see the impact on PC sales...

    I can't believe they could change how the kernel/user space communication works - and test it - in just a few weeks.

    Consumer protection agencies should really give a deep look into this.

    1. Mr Flibble

      Re: If these news came before xmas...

      It did.

      It's just that people were being fairly quiet about it all at the time, preferring to get the patches done…

      1. Anonymous Coward
        Anonymous Coward

        'preferring to get the patches done'

        And don't disturb a gorilla like Intel, both because FOSS software gets a lot of help from it, and commercial one is strongly tied to Intel as well....

  32. Dr Mantis Toboggan

    Intel based mobiles

    They are really going to feel the heat with a 30% hit.

    How about Microsoft surface garbage with intel chipsets, their shite performance is now really gonna suck.

  33. Anonymous Coward
    Anonymous Coward

    Impact on virtualized systems?

    Let's say that I am already running workloads on a virtualized x86, say in EC2 or GCE. Doesn't that make me immune to a first approximation because I'm not really running on "true Intel"?

    I say "first order approximation" because under the covers my cloud hoster is. So I am exposed insofar as say Amazon's servers could be compromised and then they could come for me.

    I'm trying to work out which parts of this are a cluster and an opportunity at the same time for AWS and friends.

  34. This post has been deleted by its author

    1. Dan 55 Silver badge

      Re: let's see how this turns out.

      Well Bloomberg and The Grauniad have had a go, both citing The Reg.

      Murdoch also had a go, citing their own special expert who got everything arse about face while he handwaved some technobabble claiming all vendors are bad as each other (well, the other vendor is AMD and their CPUs don't have this problem).

  35. lolwhat

    So, about that being able to access kernel memory bit...

    Does that mean that any VM running on an Intel-based machine with this vuln, could access the memory space of any other VM? What does that do for, oh, EC2, or Azure, or Digital Ocean, or...

  36. Destroy All Monsters Silver badge
    Thumb Up

    Holy Shit

    Literally an Outside Context Problem.

    With the UFOs.

  37. Destroy All Monsters Silver badge
    Headmaster

    A pretty good writeup I think

    Except for this part:

    Whenever a running program needs to do anything useful – such as write to a file or open a network connection – it has to temporarily hand control of the processor to the kernel to carry out the job.

    Not a good way to think about this IMHO.

    The way to think about this is that the CPU is in charge, but gets dragged along by the code (alternatively, there is a token being handed down the instruction path) (alternatively, the CPU plays "parser" of the code, leaving a foliation of the changing memory state along the time dimension). The switches between protection rings just follow a small finite state machine, where the transitions occur on kernel call, interrupt or return-from-kernel.

    1. diodesign (Written by Reg staff) Silver badge

      Re: A pretty good writeup I think

      I think we're both right - but i disagree that the CPU is in charge. The CPU isn't in charge of anything, it's just obeying code. Who is in charge - the horse or the person riding the horse? ;)

      C.

      1. Destroy All Monsters Silver badge

        Re: A pretty good writeup I think

        That's why "it's being dragged along".

        But yes. Same as with parser. If you parse text from the Internet, it's the text from the Internet that's in charge, not your parser...

      2. Rob Daglish

        Re: A pretty good writeup I think

        Some of the horses I've ridden, definitely the horse...

  38. Anonymous Coward
    Anonymous Coward

    If true then this is a monumental cock up. 30% performance hit is huge and costly - I can't see corporate customers walking away from this without demanding compensation or new chips. If you sold a car to someone and its performance was 30% less than advertised you wouldn't get away with it, and at least in the EU there is little protection for Intel. This is essentially a manufacturing defect within the limitation period of EU law.

  39. Unicornpiss
    Meh

    F00F

    I think I'll keep buying AMD for a bit longer... and possibly avoiding any kernel updates for a bit too.

    1. Dan 55 Silver badge

      Re: F00F

      An if has been committed which disables the changes for AMD.

  40. Doctor Syntax Silver badge

    Apart from the hit on performance what's the likely effect on power consumption and hence battery life and heat generation? Clearly the CPU is going to have to do more work to achieve the same result.

    1. bazza Silver badge

      It depends on what's going on in a system. If it's IO heavy, this could be quite bad (lots of interaction with the kernel). If it's compute heavy, possibly this isn't too bad. And it also depends on whose code is running. It's only a problem if you run someone else's code arbitrarily on one's computer.

      For Google this isn't too bad. The bulk of their machines are running Google's own code and dishes up search results to Internet clients. For search, maps, Gmail servers Google could take the risk and ignore the patches because they're not running arbitrary code. That's a good thing because the bulk of Google's costs is energy.

      For outfits running other people's code (Amazon?) this could be bad because they're all about running other people's code for them. So they need the patches, it will slow them down. And a lot of their cost is energy, so their cost is going to rise.

      For the rest of us mere users our computers are going to be slower and therefore use more energy for the same tasks.

      The real killer is if this exploitable in Javascript because a huge amount of what happens these days relies in users having Web browsers that are configured to accept and run Javascript from anywhere. Which all of a sudden looks hideously dangerous. That could be a massive problem for Google; if we all switch off Javascript then Google's services don't work. And nor does anyone else's.

      1. Brewster's Angle Grinder Silver badge

        This is not going to be exploitable in pure javascript. (With sufficient understanding of the VM you could control the machine code that's executed. But you can't get the VM to execute arbitrary instructions. So its very unlikely this will be exploitable without help from a bug in the VM.)

        WASM, on the other hand, might afford you enough flexibility. It will depend on the nature of the bug.

      2. Doctor Syntax Silver badge

        "It depends on what's going on in a system."

        Firing up top in Linux shows several processes, mostly daemons, actively using CPU with nothing actually being done with the system so even in the absence of IO there's context changes taking place even if it's just a matter of waking up daemons to find that there's nothing to do. I'd guess that much the same situation applies with Windows.

  41. Anonymous Coward
    Anonymous Coward

    Dodged the bullet

    Only Intel system in the house is my 5 y/o's decade old Xeon based system; which other than the £11 for the cpu, cost me nothing.

    I doubt if they will bring out any coding for stuff that old, and I doubt I would install it if they did.

  42. Dyson Lu

    Class Action Lawsuit Please

    If true, then the performance is pretty significant. Now, all of a sudden, many consumers end up with a product that offers much less than what they paid for. There should be a class action lawsuit seeking compensation.

    1. CrazyOldCatMan Silver badge

      Re: Class Action Lawsuit Please

      There should be a class action lawsuit seeking compensation

      Which will net the consumers 12 1/2p (plus two part-sucked gobstoppers) in compensation while the lawyers get to buy a nice new island each..

  43. Dig

    I don't quite get all this griping about one company or another such as this company doesn't give one hoot about security much better with this.

    If one thing that can learned from various security warnings over the years is that everyone suffers from them, in some case they can be patched without issue in others (which is unfortunately the case here) the patch causes a performance hit.

    For those crowing about AMD here was a security issue on their Opteron

    https://www.theregister.co.uk/2016/03/06/amd_microcode_6000836_fix/

    Luckily for them it could be fixed with a microcode update.

    A lot of big American companies are risk averse due to the large fines that can be imposed for negligence, however humans are involved in all parts of the process so mistakes can, will and are made.

    Lessons will be learned but unfortunately another issue will slip through.

    1. Giles Jones Gold badge

      But a you pointed out, it could be fixed in the CPU. That's not the case with this Intel fix and changing every x86 OS in the world isn't a great fix.

  44. Queeg

    Haven't done a full read through so don't if this has been raised...

    Apple are facing class action suits for slowing their CPU's because of old batteries.

    Other than not telling Apploids what they were doing I see no huge problem with that.

    I wonder when the first CA is going to hit Intel.

    I've been using AMD cpu's since the K series in the late 90's damn I feel old now

    Smug but old :)

    1. Byron "Jito463"

      Re: Haven't done a full read through so don't if this has been raised...

      "I've been using AMD cpu's since the K series in the late 90's **** I feel old now

      Smug but old :)"

      I know what you mean. I've been using solely AMD since my 486 DX/2 66MHz CPU.

      What can I say, I like supporting the underdog.

    2. Flakk
      Joke

      Re: Haven't done a full read through so don't if this has been raised...

      >I've been using AMD cpu's since the K series in the late 90's

      As you're a long-time AMD fan, would you satisfy my curiosity? Was the increase in your electric bill through the use of Bulldozer-class CPUs offset by the ability to supplement your furnace with your computer during the winter?

      1. kain preacher

        Re: Haven't done a full read through so don't if this has been raised...

        In my case yes. seriously My room was consistently 10 degrees warmer then the rest of the house. Toss in a descent video card and I had to use monster after market cpu cooler or the damn CPU would over heat and shut down.

      2. Queeg

        Re: Haven't done a full read through so don't if this has been raised...

        Hell yes, I've worked in some frigid little icebox cubicles in my time thanks to ferked up AC.

        My home office is always toasty. :)

  45. eldakka

    > That would allow ring-3-level user code to read ring-0-level kernel data.

    What about reading ring level -3? Could this be used to access the IME?

  46. crashatau

    Can you hear that sound.....

    Can you hear that?

    That is the sound of AMD fanboys gloating gleefully. :)

    1. Anonymous Coward
      Anonymous Coward

      Re: Can you hear that sound.....

      It's kind of a soft, humming sound, possibly accompanied by the sound of a bucket of pop corn being reached for...

  47. mirage

    Excellent use of example

    “Think of it like god sitting in the clouds”

    While humans have been going into space since decades ago, god is still stuck in the clouds. Interesting, to say the very least.

    1. peterkin

      Re: Excellent use of example

      Magellanic clouds?

  48. Field Commander A9

    Ask for refund?

    The Complete Care package for my Alienware 15R2 (i7-6700HQ) expires on April 2018. Do you think I can ask Dell for a refund for my laptop for this reason?

    1. Jonathan Richards 1 Silver badge
      Go

      Re: Ask for refund?

      Oh, certainly you can ask. Don't expect a returns label to be issued before, say, April!

  49. JonHendry

    Is the Linux fix optimal?

    Just wondering, what are the chances that the Linux fix is the best possible? Perhaps Apple and/or Microsoft will come up with a faster solution, perhaps a better general solution which could be applied to Linux as well. Or, perhaps OS-specific fixes taking advantage of characteristics of Mach or Windows that Linux doesn't happen to have. (Not a slam on Linux, just noting that the OSes have different architectures and features that could conceivably come into play in designing a fix.)

  50. herman Silver badge

    Maybe enlisting the ME as a co-processor for I/O can speed the chips up again.

  51. Jamie Jones Silver badge

    yippee

    Only a few months ago I bought a KabyLake - only my second intel purchase ever... ho hum

  52. Anonymous Coward
    Anonymous Coward

    VMS is calling

    There's a reason AMD didn't follow Intel down this hole. They've known about it for nearly 20 years and Intel did too and chose to implement anyway. Find an old copy of VMS Internals and Data structures. If VMS couldn't keep you out, it killed itself to limit the damage. "Page Fault IPL too High". Intel got the engineers but AMD got the IP when the lab/fabs were sold off. Evidently, AMD paid attention.

    1. Stoneshop

      Re: VMS is calling

      Intel got the engineers but AMD got the IP when the lab/fabs were sold off. Evidently, AMD paid attention.

      The DEC engineers that ended up at Intel were, for a large part, from the software side of things; the compiler group went over almost lock, stock and barrel. AMD got a number of Silicon Wranglers who had been working on AXP and chipsets; several AMD processor subsystems bear a strong resemblance to their AXP counterparts.

      1. Flakk

        Re: VMS is calling

        The idea of where an ancient bug rears its head depending largely on the migration destination of a bunch of DEC hardware veterans is positively fascinating.

      2. MasterfulShog

        Re: VMS is calling

        More than you know... I believe, without knowing, that early AMD64 and Alpha processors were designed to be pin compatible. Certainly if you looked at the motherboard for early AMD64 you would see an Alpha southbridge.

        I reckon there was a lot of IP sharing, and Jim Keller of course.

        1. Anonymous Coward
          Anonymous Coward

          Re: VMS is calling

          "early AMD64 and Alpha processors were designed to be pin compatible."

          Close enough. See Athlon, Hypertransport, and such.

          Start at e.g. https://en.wikipedia.org/wiki/Athlon

          "The Athlon architecture also used the EV6 bus licensed from DEC as its main system bus. Intel required licensing to use the GTL+ bus used by its Slot 1 Pentium II and later processors. By licensing the EV6 bus used by the Alpha line of processors from DEC, AMD was able to develop its own chipsets and motherboards, and avoid being dependent on licensing from its direct competitor."

  53. qwert1234sd

    Not so smug now are you?

    Where is DOC HOLLOWOOD now? Hahahahahaha

  54. Whoisthis

    Typical

    Just got myself a new laptop in the boxing day sales...

    Is the 8th gen series ok? Could not find info anywhere. Specifically Intel® Core™ i5-8250U Processor

    Thanks pals

    1. JonHendry

      Re: Typical

      I think the 8th gen are okay.

  55. Anonymous Coward
    Big Brother

    Those pesky kids

    NSA/GCHQ/Mossad/PLA - "Oh, cock!"

  56. The Unexpected Bill

    What about fringe makers of x86/x64 CPUs?

    I'm greatly curious to know how or if companies like VIA (or maybe even DM&P) and their microprocessor products might be affected by this.

  57. Anonymous Coward
    Trollface

    Old skool....

    Looks like I'll be keeping my o/ced Q6600 workstation for a while yet...

    1. Ryan 7

      Re: Old skool....

      They're affected too...

  58. Anonymous Coward
    Anonymous Coward

    Intel.

    Isnt that why intel was better at benchmarks basically? And why most of people took the bait ? Im curious how benchmarks will look after the kernel fixes.

    1. Aitor 1

      Re: Intel.

      It seems they have decided to penalize all processors, inuding amd... now, they will use certain optimizations on intel micros so tjey only het about 18% slower. So amd will go 30% slower for no reason at all.

      1. Alan J. Wylie

        Re: Intel.

        all processors, inuding amd

        This post on the Linux Kernel Mailing List, from Tom Lendacky at AMD says "AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against"

  59. Glad Im Done with IT

    Lots of testing work to be done then?

    As it is .Not spends about 30% in kernel according to TaskManager when loaded and working hard, how much will this cripple .Not, M$ pushes the fact that the code is secure, and this security is done in the kernel.

    It is certainly going to be amusing to watch the fallout from this,

    1. ilmari

      Re: Lots of testing work to be done then?

      It's the move to and from kernel that is penalized, time spent inside kernel and time spent outside kernel isn't penalized. Of course, hardly any system monitoring programs will tell you how many syscalls or context switches different programs cause.

  60. LewisCowles1986

    Nobody Else pissed about the God reference?

    > Think of the kernel as God sitting on a cloud, looking down on Earth. It's there, and no normal being can see it, yet they can pray to it.

    No I won't because I understand how a fucking kernel works. This is a remarkably stupid comparison; especially when we know how kernels work. We can evidence their existence, there are books relating to the design of them by mere mortals. They do not care about trivial areas of our lives!

    I'm more mad about this than the 20-30% of CPU limiting that's going to go on.

  61. This post has been deleted by its author

  62. Anonymous South African Coward Silver badge
    Trollface

    *slow clap*

    And this hoo-haa triggered this memory of the Usenet Oracle and Windows 95...

    The original can be found here : https://internetoracle.org/special/windoze2.cgi

    The Usenet Oracle has pondered your question deeply.

    Your question was:

    > O great Oracle, the one who sees all and knows all, please accept

    > this humble question from thy grovelling supplicant...

    >

    > Why is Windows 95 Beta so bug-ridden it's not funny?

    And in response, thus spake the Oracle:

    } THE SCENE: A dark antechamber of the Gates estate, dimly lit by three

    } 20" monitors suspended from the ceiling. In the middle of the room is

    } a Pentium/100Hz, sheathed in a black casing. Three programmers dance

    } around the machine, chanting horribly. Their pale, clammy complexion

    } is cast hideously by the light of the monitors, rendered even more

    } repugnant to the watchful eye bye the 60Hz flicker of the monitors.

    }

    } FIRST PROGRAMMER: Thrice the brinded net hath mewed.

    }

    } SECOND PROGRAMMER: Thrice, and once the Warp-pig whined.

    }

    } THIRD PROGRAMMER: MacHarpier cries. 'Tis time, 'tis time!

    }

    } FIRST: Round about the terminal go;

    } In the poisoned upgrade throw.

    } Code, which by a student done

    } In minutes numbering sixty-one.

    } Run-time error, protection fault,

    } Crash ye first, crash ye shalt.

    }

    } ALL [as they dance around the Pentium]:

    } Double, double, toil and trouble;

    } Tempers burn and data bubble.

    }

    } SECOND: Fillet of a Sound Card bake,

    } In the Pentium no sound make;

    } Point of arrow, click of mouse,

    } Scream of user, frightened spouse,

    } OS/2's net use appeal,

    } Steve Jobs' look and Wozniak's feel.

    } For a charm of powerful trouble,

    } Like a hell-broth boil and bubble.

    }

    } ALL: Double, double, toil and trouble;

    } Tempers burn and data bubble.

    }

    } THIRD: Click "Start" button, speed of slug,

    } You would think you forgot the plug.

    } Multitasking, ha ha ho

    } If just one worked you'd be good to go.

    } This should grab those straggling few

    } Who aren't using DOS 6.22.

    } Now we shall the Mac eclipse,

    } While curse words cross our users' lips.

    } Leave the errors in so we can fix

    } And sell more...Windows 96!

    } And so we will release the Beta

    } For corruption of their data.

    }

    } ALL: Double, double, toil and trouble;

    } Users buy, our profits double.

    }

    } SECOND: Compile it with errors through,

    } Since the users have no clue.

    }

    } [Enter BillGate to the other three programmers.]

    }

    } BillGate: O, well done! I commend your pains,

    } And everyone shall share i' the gains.

    } And now about the program get,

    } But NEVER use it on OUR net.

    } Security is scarce put in.

    } [Beeps of PONG heard in the background.]

    } [Exit BillGate.]

    }

    } SECOND WITCH: By the usage of my UMBs

    } Wicked Windows this way comes.

    } Open locks,

    } Whoever knocks!

    }

    } [Fade to black.]

    }

    } Remember, Obsolescence isn't an accident, it's an art form.

    }

    } You owe the Oracle a signed, handwritten manuscript of MacBeth, and a

    } copy of the Windows upgrade for the P6.

  63. Philip Mather
    Mushroom

    "PS: It appears 64-bit ARM Linux kernels will also get a set of KAISER patches,"

    Why has no one asked the most critical question... do I need to patch my Pi?

    Also, given the number of recent SNAFU's like this and Apple's login cock-up etc... I'd like to request a new +1 level of FAIL icon so that we can ring in 2018 with a new, appropriate level of numbnuttedness that the existing FAIL icon er... fails to encapsulate this new level.. Something like a double face palm icon?

  64. Anonymous Coward
    Anonymous Coward

    Typical Intel

    Many years ago when I was a hardware developer we used to call this the Intel Factor. In the spec sheets you used to get min / typical / max figures. You knew that when the production chips came to replace the test ones the figures would be the least advantageous. You had to always design for the very worse case + 10%

  65. ForthIsNotDead

    Can I return my laptop?

    And for that matter, my 8 racks of Intel-based servers in the server room?

    Seriously, that was my first thought.

    If this were a car, and, under certain circumstances the brakes were applied without instruction from the driver, there would be a recall, and the problem would be fixed, with the manufacturer taking the financial hit.

    Why is it different with computer hardware? Why does the world just shrug its shoulders and just go "Oh well"?

    I've got a lovely Lenovo I3 laptop that runs Linux Mint beautifully, and I'm delighted with it. This has majorly pissed me off.

    In the server room, we run racks of Wintel HP servers running mission-critical SCADA software, and it looks like we're suddenly going to get a lot less bang for our buck.

    Why can't we return them the manufacturer, who in turn returns them to Intel?

    It's a rhetorical question, I suppose. I mean, what would they be replaced with, since Intel has no iron that, you know, actually works *properly*.

    But that's the point, isn't it. Why should we put up with this?

    Mistakes happen, of course. But there's no reason why we should just "put up with it".

  66. Anonymous Coward
    Anonymous Coward

    Unusual stock trades

    Intel's CEO dumped a load of stock in late November, and it was considered odd even before this news broke...

    https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx

    1. James 47

      Re: Unusual stock trades

      This is most likely due to changes in US tax law. Goldman Sachs also distributed bonuses early for the same reason.

      1. Tom 7

        Re: Unusual stock trades

        What? Goldman Sachs distributed bonuses early to avoid the lower tax rates?

    2. Lee D Silver badge

      Re: Unusual stock trades

      Correlation is not causation.

  67. Mystic Megabyte
    Linux

    Back from the dead

    I was going to throw out two old HP AMD dual core laptops. Now I think I'll just replace the backlights and keep them. (they run Ubuntu or Mint perfectly well) In the meantime maybe it's safer to browse the web with a Raspberry Pi than this Lenovo with Intel inside.

  68. Giles Jones Gold badge

    Class Action

    Hopefully a lot of people are going to sue.

    Intel is getting complacent again, good job AMD have had a bit of a revival.

  69. Alan J. Wylie

    kernel patch from early December

    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c313ec66317d421fb5768d78c56abed2dc862264

    Author: Dave Hansen <dave.hansen@linux.intel.com>

    Date: Mon Dec 4 15:07:34 2017 +0100

    x86/mm/pti: Disable global pages if PAGE_TABLE_ISOLATION=y

    Global pages stay in the TLB across context switches. Since all contexts share the same kernel mapping, these mappings are marked as global pages so kernel entries in the TLB are not flushed out on a context switch.

    But, even having these entries in the TLB opens up something that an attacker can use, such as the double-page-fault attack

    ...

  70. Third Electric

    Intel CEO insider trading?

    Looks like the CEO of Intel dumped most of his stock 2 days before this news dropped!

    Isn't that insider trading?

    https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx

    1. Anonymous Coward
      Anonymous Coward

      Re: Intel CEO insider trading?

      Almost certainly not, Executive Officers of corporations are required to announce share sales in advance according to a set timetable, they can't just dump it on a whim.

  71. Anonymous Coward
    Anonymous Coward

    Handbrake users beware

    For thos who use Handbrake to do video conversions, this will really hit you. Lots of CPU and tons of I/O.

    Now, where's that new PC I promised myself for new year.....

    1. ilmari

      Re: Handbrake users beware

      Funny, I thought video conversion would be minimally hit, as it consists mostly of:

      read(very many bytes); process (very long cpu intensive code); write(very many bytes)

      Where, if the read and write are implemented as sending big requests to the kernel, should be minimally affected. The processing portion of it is surely 99% of the whole processing time anyway?

      I could believe things like a database would slow down, when it's hopping all over the place on disk looking for/writing data. I could believe facebook slows down alot, because browsers are doing lots of itsy bitsy tiny reads and writes to both disk and net, and lots of small updates of the screen to animate all the gifs and what not.

      1. BinkyTheMagicPaperclip Silver badge

        Re: Handbrake users beware

        It's already been established on Phoronix that games are not affected - if it's mostly user mode code there isn't going to be a noticeable impact. I would have thought video editing/transcoding also fit into that category.

        Personally I'm more worried about virtualisation.

  72. EduQuint

    Which exact Intel processors models are affected by this kernel leak problem?

    I could not find any reference to this list of processor models anywhere in the Net,

    1. Anonymous Coward
      Anonymous Coward

      I could not find any reference to this list of processor models anywhere in the Net,

      That's because the actual details of the problem have not been publicly disclosed yet.

    2. GreenReaper

      Pretty much everything which runs X86 built in the last two decades. There is debate over which of the Pentiums are impacted, and whether Atom counts, but the very first of the P6 chips (Pentium Pro) listed speculative execution as a feature.

  73. Daniel Gould

    VMWare ESXi

    If people are running their servers in a virtual environment (VMware ESXi), does this issue potentially open VM to VM communication vulnerabilities, or if the hypervisor still effectively isolating privileged memory correctly between VMs? I can understand that this may still leave the issue open inside the VM OS if those are unpatched, but as long as the hypervisor is still providing isolation, the risk is restricted to issues inside the VMs themselves.

    1. Anonymous Coward
      Anonymous Coward

      Re: VMWare ESXi

      That's the best question I've heard asked here. What about Hyper-V as well? Host hypervisors themselves would have their own exposure to this bug. Hijacking a VM is one thing, hijacking the Host Hypervisor is something of a different order. I'll bet VMware and MS Hyper-V are testing the crap out of this as I type.

    2. gordonsj

      Re: VMWare ESXi

      Precisely. Many vSphere engineers will be on the edges of their chairs waiting for an update from VMware about this. Patching all Windows and Linux VMs with a potential 30% performance hit will be bad enough, but if it applies to the ESXi hosts as well! Lets see.

  74. Cmenard

    Xeon

    Does bug present on Xeon chips?

    1. collinsl Silver badge

      Re: Xeon

      We don't know yet. Wait for the announcement.

  75. DJ Smiley

    So I think I found a video of the bug in action....

    I took a little time in my lunch break to try and figure out what was so big that it had intel and co running scared....

    I found a Video from 2017 (wow that long ago!) showing reading a EC2 instance from an EC2 instance without any kind of permissions...

    Is this what the fuss is about? It looks pretty scary to me!

    https://www.youtube.com/watch?v=yPZmiRi_c-o

  76. John Styles

    Fe fi fo faction

    I smell the blood of a f****ing enormous class action

  77. rav
    WTF?

    Is this latest Intel BUG really a surprise????

    Intel is obviously cutting back on it's hardware validation procedures in their rush to put products on the market to compete with AMD Ryzen, Threadripper and EPYC processors.

    As a for instance, AMD took almost 3 years to validate Ryzen and EPYC prior to launch. Intel seems to be taking less than a year.

    Of course QC will suffer. In fact this bug has been known for several months.

    1. HmmmYes

      Re: Is this latest Intel BUG really a surprise????

      When i worked at intel, apart from the fabs, which were given a pass, mainly as sod all people worked in them and they were so key to Intels profit, the rest if intel operated in a lunatuc, ranknrate, paranoia, run around hell.

      Intel need to realise that their core comoetence is running software.

  78. This post has been deleted by its author

    1. JLV

      Re: TRUMP??? Seriously?

      We need a Godwin2 for morons who insist on dragging in the orange moron on every subject, no matter how unrelated.

  79. Colin 29

    Recommended benchmark

    Can anyone recommend some good benchmark software I can run pre and post update to assess the impact on my home machines?

    I'd like some evidence to present if I need to ask for compensation.

    TIA

    1. This post has been deleted by its author

  80. commonsense
    Holmes

    Co-incidence?

    https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx

    Hmm

  81. I Am Spartacus
    Mushroom

    So, they stop selling all failing CPU's

    Presumably, knowing that the CPU's have a fundamental design flaw in them, Intel must now ask all vendors to cease selling defective processors.

    It's one thing to discover a problem in your processor that requires an OS change to fix. It is entirely another to knowingly sell any more of these defective chips.

  82. Pig Dog Bay
    FAIL

    Y2K For Real This Time!

    This is quite a big story as when the updates eventually get rolled out we will see significant drop in computer resource availability. I expect to see

    - Websites / services becoming slow or going offline

    - Lower productivity, workers waiting even longer as their computer grinds away

    - Increased business cost to cover the loss of computer resource

    - When the embargo is lifted and details of the bug become known, there will be a slew of new malware, especially targeting those who refuse to update

    -Big jump in AMD shares price and a crash in Intel's

    -But no SEC insider dealing investigation into why the Intel CEO sold his shares before Christmas

    1. misterinformed

      Re: Y2K For Real This Time!

      "- Websites / services becoming slow or going offline"

      Good point about going offline. A server currently running under high CPU load could have its throughput reduced below the required workload and then there will be backlogs or service unavailability. This could be a headache for admins who will have to decide whether servers can tolerate the performance hit before installing the patch.

  83. Duncan Macdonald

    Intel playing bad boy again ?

    According to HotHardware.com (see https://hothardware.com/news/intel-cpu-bug-kernel-memory-isolation-linux-windows-macos) the linux page table isolation is being applied to all x86 CPUs not just the intel ones with the problem - and according to the linux kernel diff log the patch was submitted by an Intel engineer (see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c313ec66317d421fb5768d78c56abed2dc862264)

  84. MrReal

    And people worried about their iPhones slowing down..

  85. Alan J. Wylie
    1. Ryan 7

      Re: POC announced

      Specifically, https://twitter.com/brainsmoke/status/948564783527276544

  86. gordonsj

    VMware

    The one vendor not mentioned at all in this article or any other about this is that I have read is VMware. How will this affect systems virtualised on VMware esxi?

    1. Dave 13

      Re: VMware

      Or Hyper-V. Potentially all host hypervisors are at some risk. Details will definitely sort this out in the near future and a lot will depend on what sorts of exploits this actually enables.

    2. Criggie

      Re: VMware

      https://xenbits.xen.org/xsa/ shows XSA-253 is prereleased but embargoed, so Xen knows something.

  87. Jerichofr

    Can't go AMD anyway.

    Haven't used AMD in a long time, but as AMD can't really be used in a hackintosh, won't be switching to AMD any time soon. Besides, I've had trouble with every AMD processor I've ever had, and not with Intel, so going to stick with Intel unless AMD gets better and can be used in a hackintosh as easily as an Intel processor.

    1. JonHendry

      Re: Can't go AMD anyway.

      Someone recently posted screenshots of their 4 processor, 64 core AMD Opteron Hackintosh.

  88. Florida1920
    Thumb Up

    Whew!

    I've been using nothing but AMD CPUs since 2001, just because. Yeah, I still use Windows 7 SP1, but at least this attack vector won't affect me.

  89. Anonymous Coward
    Thumb Down

    Probably doesn't matter...

    ...as Intel's ME provides a far more satisfying attack vector. Once you have that, you have everything.

    ARM is the future.

    1. BinkyTheMagicPaperclip Silver badge

      Re: Probably doesn't matter...

      ARM is also affected by this, has no discoverability of built in devices on many platforms, and is infested by binary blobs for many devices. Its documentation is generally appalling.

      Its only saving graces are the lower power and the price. Passable for a phone that everyone accepts is landfill after two years (idiocy, but the prevailing opinion), unforgivable for general computing devices.

  90. Anonymous Noel Coward
    Boffin

    Encryption

    I can't help wonder how this will effect people who've encrypted their entire hard drive with VeraCrypt, or at least run something out of an encrypted file 24/7.

    Because surely the reading and writing, not to mention the use of an encryption driver will be pretty heavy on system calls.

  91. Anonymous South African Coward Silver badge

    One question - does this "feature" allow you to access the hypervisor host's memory (RAM, HDD) from a VM?

    1. AdamWill

      I've read at least one claim that someone has managed to do this, for whatever that's worth.

  92. jms222

    Drive encryption should not require more system calls than before being just further processing. But there Is the theoretical possibility of user land i.e. browser discovering your keys then somebody physically thieving the machine.

    ARM may have issues but being a forty year old 8 bit micro with stuff lashed on isn’t one of them. Well it has evolved but started as a 32 bit (26 bit address limited earlier) machine.

    The hypervisor is in a fuzzy way kernel so in an unqualified way I think it can leak just the same but I may be wrong.

  93. JLV

    upside for AMD?

    (I rather like AMD, used them preferentially back when I was building my own kit, in P4 days. I've been thinking of building a mini-ITX with my son and was already preferring AMD's Ryzen).

    Once the dust settles, this may end up more negative to Intel than positive to AMD, sadly.

    - it will be a big hit on Intel's financials

    - assuming that it is relatively easily to design and implement a fix in silicon, this is a massive suck on Intel's current CPU lineup, but won't affect them much once the fix is in.

    - Intel won't lose OEM business on existing systems (though the OEM's sales might drop). It need not lose business on future systems once they've fixed their silicon. It's vulnerable on a narrow range of systems where the choice of CPUs is still not finalized.

    - Apple's rumors of switching to ARM arch concretizing? That would be a massive hit on Intel, but would do nada for AMD.

    - OEMs may not at all be happy, but at least Intel has the $ to indemnify them, should it be decide to do so, or be forced to. AMD's $400M/Q losses just wouldn't allow it.

    - Intel has always won because most premade system use them. A big part of that is their Intel Inside bribery incentive program. After this, they will just double down on spending big $ to wine and dine the OEMs and there's little AMD can do about it. Yes, massive reputational damage to Intel, but will it stick? Marketing $$$ is Intel's strength.

    This will distract Intel, for sure. And it will cost them too. But will it change things a lot, much as we'd like more competition in the X86 space?

    On the plus side for AMD, this couldn't have happened at a better time for them. They've had their moments when they were significantly better than Intel and right now is very much one of them. Had this happened 2 years ago, they would have had little to capitalize on.

    Now, with the new Ryzens they have a much better story to tell to customers. If they can develop that into more OEM opportunities long term that'll be awesome.

    1. Anonymous Coward
      Anonymous Coward

      Re: upside for AMD?

      Its not a flaw -- its an NSA demand! How else can they spy on the whole world easily.

      Just keep in mind that all those used computers/CPUs being sold by CHina and Russia very new silicon guts with their hardware hacks. Yup innocent American set up by hardware as fifth column attackers.

      Conspiracy anywhere 2 people gather. ROFLAMAO

  94. HmmmYes

    Hmm,

    Made bbc front page

    http://www.bbc.co.uk/news/technology-42553818

    Note to semifabbers - dont let your fuckup be found in a slow news week.

    Intel must be running short of feet to shoot.

    1. IDoNotThinkSo

      According to that BBC article "Semi-conductor chips are found in many of the world's computers".

      Obviously someone out there is still using valves...

  95. jms222

    VAX ?

    I’d like to see this as an opportunity for non x86 even IBM with Power or Z, ARM, VAX...

    Nothing against AMD but it’s flogging the dead x86 horse.

    1. Anonymous Coward
      Anonymous Coward

      Re: VAX ?

      VAX. Sure.

      Web browser? Productivity suite? Minecraft?

      x86 may be a dead horse. but that carcass is being flogged with an enormous amount of software.

      Didn't I see something recently about VMS being ported to x86?

      1. Anonymous Coward
        Anonymous Coward

        Re: VAX ?

        VMS to x86 happened the first time back in the late 80s. USAF unit was working with weighed running an air combat simulation model designed for VAX on x86 hardware for about $5000 plus cheaper version of software for x86 at about $25K. Even live support was cheaper by factor of 1/3.

        But as always study directors assumed General level staff would be more impressed if we ran on Genuine VAX equipment that we got an incredible bargain of about $250K plus the bonus that software on VAX hardware was x20 the price as well on government contract.

    2. Observation2015

      Re: VAX ?

      Virtualization science is approaching the point that -- soon native instruction sets will not matter much. Heck in 20 years you will probably be able to 3D print your own designed CPUs at home. Then with a little generic Virtual Mapping and kernel-hypervisor building assisted by COTS software on another computer...you can then run VMs on your own unique instruction set CPU.

      Mind you for 7-10 years those VMs will probably still be running mostly x86 software. But eventually Computer Scientists and hobbyists will get their dream of running software based on whatever arbitrary symbolic operations language is currently in vogue or that they want to invent (Forth Reborn etc)...and X86, ARM and all those hardware vendor instruction sets will be dead.

      But in the mean time going rogue to avoid 90% of current software invention needs more specific needs than "I hate big groups and companies" and "I want a smaller pond so I look like a bigger fish". So low cost low power embedded or supercomputing still tend to be the more common refuges from x86.

  96. Anonymous Noel Coward
    Trollface

    Oh!

    And then there's Denuvo...

  97. Anonymous Coward
    Anonymous Coward

    A different kind of "speculative" processing...

    Speaking of speculative processing... I know it sounds like some wingnut conspiracy stuff but one does have to wonder if some group like the NSA (or the Russians/Chinese if you want to be really crazy) insinuated an ubiquitous yet subtle design bug into the core design back a decade+ ago during the height of the CARNIVORE craziness? This could have allowed them covert access nearly worldwide for almost any Intel based Windows, Linux, and Mac systems apparently. Just an idea from my food-for-thought processor. ;-)

  98. daveyeager@gmail.com

    Why not just use memory fences?

    I don't know the details about this bug, but if speculative execution from user to kernel mode is triggering the issue as described in this article, then wouldn't memory barriers fix the problem? Couldn't they just insert them at the start of system calls, interrupts, and context switches? There must be more to it.

    1. GreenReaper

      Re: Why not just use memory fences?

      I believe it's speculative execution within the kernel, resulting in information disclosure to user mode due to a timing attack on the shared processor cache which can undermine KASLR.

      So they split the user/kernel page table set, which had always been shared before for performance (and only split to provide 4GB/4GB space for both on x86-32, which suffered the same kind of impact).

      One interesting way to approach this might be to limit the cache allocated to certain processes, but that's an advanced feature found only on recent Xeons, and I don't think anyone's actually planning to do that - it might have an even worse impact.

  99. Ichijikuibo

    This is being very over exaggerated

    I have an Intel i7 3770 and have been running the Windows Insider preview which has apparantly had the patch applied since November and I haven't noticed any performance drop in anything. Even testing since I heard of this I can't find anything more that 1-3% which can easily be for other reasons. Even gaming with a cpu intensive game (BF1 64player multiplayer on amiens) which maxes my CPU out I can't see any difference. Servers and virtualized enviroments might be different but there will be little or no effect on standard desktop use.

    1. diodesign (Written by Reg staff) Silver badge

      Re: This is being very over exaggerated

      Gaming is pretty much unaffected - it doesn't involve the kernel, you're talking direct to the GPU. Most desktop apps are not IO intensive so you won't see a big hit. It's not great news for stuff that slams the disk and network, or works in real time - however, as we said, if you have PCID supported, the hit is minimized.

      C.

      1. Aitor 1

        Re: This is being very over exaggerated

        It does affect me. Compiling times will increase and all our servers run on xeons... are quite sensitove to time, run virtualization sw and are io intensive. Great.

  100. 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!

  101. Anonymous Coward
    Anonymous Coward

    30%?

    It's actually closer to 65%.

    https://twitter.com/grsecurity/status/948170302286172160

    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.

  102. 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.

  103. Alan Sharkey

    Why just now and will MS/Linux be intelligent?

    If the fix is just

    <If CPU=Intel, do this

    else

    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.

  104. Anonymous Coward
    Anonymous Coward

    PR gone wild

    Intel's press release is a masterpiece.

    https://newsroom.intel.com/news/intel-responds-to-security-research-findings/

    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

  105. sisk

    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.

  106. Anonymous Noel Coward
    Alert

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

    https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html

    https://spectreattack.com/

  107. jchevali
    Childcatcher

    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

      Re: Bad journalism

      @jchevali

      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:

        https://newsroom.intel.com/news-releases/industry-testing-shows-recently-released-security-updates-not-impacting-performance-real-world-deployments/

        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?

  108. 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).

  109. qwerty123123

    There are other OSs to consider as well

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

  110. Anonymous Coward
    Anonymous Coward

    NSA?

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

  111. 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 :)

  112. Anonymous Coward
    Anonymous Coward

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

  113. Maelstorm Bronze badge
    FAIL

    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).

  114. Luiz Abdala
    Stop

    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?

  115. Anonymous Coward
    Anonymous Coward

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

    Will we see further patches over time which reduces this?

    Or is it a "NOPE, SO LONG, AND THANKS FOR BUYING INTEL!" thing?

    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.

  116. Cobalt

    I came to piss you off. Have fun!

    Ryzen > Intel

  117. selangley

    More Info

    ICYMI:

    Helpful website explaining the issues by Graz University of Technology

    https://meltdownattack.com/

    AMD's response to these issues:

    https://www.amd.com/en/corporate/speculative-execution

    1. Dan 55 Silver badge
      Meh

      Re: More Info

      Hurray, we've now got a logo.

  118. 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?

  119. 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.

  120. 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!

  121. 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?

  122. This post has been deleted by its author

  123. paddypawprints

    Hypervisors?

    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.

  124. 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.

      C.

  125. 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).

  126. Augie
    Go

    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

    https://www.amd.com/en/corporate/speculative-execution

  127. Brent Beach
    FAIL

    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?

  128. 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.

  129. nkz15

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

    KB4056892

  130. 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.

  131. PeterM42
    Facepalm

    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.

  132. JoshS

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

    to get around this very serious problem.

  133. GrapeBunch
    Thumb Up

    Phlogiston

    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.

  134. 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) -- https://support.apple.com/en-us/HT201222

    Reference (with fixes listed for CVE-2017-5754) -- https://support.apple.com/en-us/HT208331

    "Kernel

    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"

  135. MysteryGuy

    Does Windows 7 have PCID optimization?

    Is PCID supported for Windows 7? I've updated two Windows 7 systems on CPUs that claim to have both PCID and INVPCID support, but that support doesn't show as enabled.

    I used the Powershell 5.1 Get-SpeculationControlSettings function to check. (See https://support.microsoft.com/en-hk/help/4073119/guide-to-protect-against-speculative-execution-side-channel-vulnerabil ).

    "Speculation control settings for CVE-2017-5754 [rogue data cache load]

    Hardware requires kernel VA shadowing: True

    Windows OS support for kernel VA shadow is present: True

    Windows OS support for kernel VA shadow is enabled: True

    Windows OS support for PCID optimization is enabled: False

    Suggested actions

    ...

    BTIHardwarePresent : False

    BTIWindowsSupportPresent : True

    BTIWindowsSupportEnabled : False

    BTIDisabledBySystemPolicy : False

    BTIDisabledByNoHardwareSupport : True

    KVAShadowRequired : True

    KVAShadowWindowsSupportPresent : True

    KVAShadowWindowsSupportEnabled : True

    KVAShadowPcidEnabled : False"

    I booted Mobile Windows 10 on one of these systems, and under Windows 10 it does show

    "Windows OS support for PCID optimization is enabled: True".

    So, I was wondering if they've omitted PCID optimization under Windows 7.

  136. anonymous boring coward Silver badge

    I would hate to defend Intel, but let's face it, most of our performance hits so far have been thanks to the WWW and browsers allowing lot's of sh*t (see: Google). Spying and tracking costs massive amounts of cycles, and irritating latencies.

  137. rpark
    Alert

    Unleashed

    ...and we're all still waiting for the power of the Pentium to be 'unleashed'.

  138. EnternalOptimist

    Boffins?

    Great article, even though it's going to cause a lot of nuisance work for me. Never heard of the word "Boffins" before. Apparently it's British, but now I can use it on my nerdy friends here in the US. They will claim offense, but none should be taken!

  139. Brabus
    IT Angle

    2 vulnerabilities down, how many more to go?

    The question now is?

    1>Will new chips be vulnerable?

    2>When will we get new chips woyout the vulnerabilty?

    3>When to buy your new PC, as if your like me I just cancelled the order of my new iMac.

    How much more can we take? It's all getting a bit boring!

  140. stefanreich2

    What if we stopped running untrusted code? It's possible.

    1. Anonymous Coward
      Anonymous Coward

      Can we stop running speculatively running that code though?

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

Other stories you might like