back to article We translated Intel's crap attempt to spin its way out of CPU security bug PR nightmare

In the wake of The Register's report on Tuesday about the vulnerabilities affecting Intel chips, Chipzilla on Wednesday issued a press release to address the problems disclosed by Google's security researchers that afternoon. To help put Intel's claims into context, we've annotated the text. Bold is Intel's spin. Intel and …

  1. -tim
    Facepalm

    Old is new again?

    Theo from OpenBSD had a rant about Intel and similar problem in 2007. https://www.theregister.co.uk/2007/06/28/core_2_duo_errata/

    And people say I'm crazy for using SPARC.

    1. Anonymous Coward
      Anonymous Coward

      Re: Old is new again?

      > And people say I'm crazy for using SPARC.

      No, Intel have made clear that it's not anything to do with your OS or your CPU - its your source of news. X-ref this El Reg article with, eg, http://www.bbc.co.uk/news/technology-42561169

    2. P. Lee
      Trollface

      Re: Old is new again?

      >And people say I'm crazy for using SPARC.

      I see you've already implemented the 40% performance hit fix. ;)

      1. Destroy All Monsters Silver badge
        Paris Hilton

        Re: Old is new again?

        From BBC FONUIZ: Rush to fix 'serious' computer chip flaws

        Typically, both parties agree not to publicise the problem until a fix has been implemented, so that criminals cannot take advantage of the issue.

        This time it looks like somebody jumped the gun and information was leaked before a software fix was ready for distribution.

        I haven't heard about anyone "this time" mysteriously jumping any gun, what do they mean by that?

        1. RyokuMas
          Mushroom

          Re: Old is new again?

          "This time it looks like somebody jumped the gun and information was leaked before a software fix was ready for distribution."

          Google have got form for disclosing security flaws before fixes are ready.

          I can't help wondering if they have some new AMD-powered Chromebook waiting in the wings to hit the market in a couple of weeks time...

          1. R 11

            Re: Old is new again?

            "Google have got form for disclosing security flaws before fixes are ready."

            Giving the other party 90 days to fix, followed by them going into radio silence up to and beyond the 90 days isn't quite the same what happened here.

            Seems more likely that these bugs affected so many systems that many more folk needed to be told. When so many people have a need to know, a leak becomes almost inevitable.

        2. Anonymous Coward
          Anonymous Coward

          Re: Old is new again?

          > I haven't heard about anyone "this time" mysteriously jumping any gun, what do they mean by that?

          As the article reads like a cut 'n' paste job, it's not worth while trying to analyse it. The layers of obfuscation are geological in complexity, suggestions it's just a software issue, poor Intel with some fearful leaker being nasty to them, suggestions of it all being sorted if only they'd had time etc etc. Even El Reg has had to conflate two separate issues, and each is complex. Expect colleagues, family and friends to start conversations with you today with "I don't understand what they mean..."

        3. Muscleguy

          Re: Old is new again?

          What's the betting the NSA and GCHQ etc have known about this for some time?

          1. Sanctimonious Prick

            Re: Old is new again?

            @Muscleguy

            My thoughts exactly!

    3. Gordan

      Re: Old is new again?

      "And people say I'm crazy for using SPARC."

      Are you sure SPARC isn't vulnerable to this?

      1. Chris Neale

        Re: Old is new again?

        Positive, he's the only person running it :-)

        1. Down not across

          Re: Old is new again?

          Positive, he's the only person running it :-)

          Nah, no he isn't. I have house full of SPARC (and plenty of other non x86) boxen. Come to think of it anything doing any real work is AMD or not x86. Couple of gaming machines do have i5 or i7 but thats it.

        2. CrazyOldCatMan Silver badge

          Re: Old is new again?

          Positive, he's the only person running it :-)

          Nah. We have a couple of old[1] SPARC-based E450's in the computer room doing old[2] Oracley stuff. Fortunately, one of them just got supplanted by a system upgrade so I'll be able to switch it off soon.

          [1] Can anyone else remember when the E450's were new and oooh-shiny? I can..

          [2] As in 'written last century' old. Or as we like to call it "johnny-come-lately new fangled stuff"

      2. Maelstorm Bronze badge

        Re: Old is new again?

        Actually, because of the design of the SPARC processor, it is immune to Meltdown. To be technical, unlike x86, SPARC processors have a separate TLB (Translation Lookaside Buffer) for kernel pages only. That's the source of the slowdown on x86. With the kernel fully removed from the process address space, a full context switch is needed because now you are fully switching address spaces, and the TLB contents are dumped. For a TLB miss, it takes 2-5 memory accesses to read in a page table entry, and at roughly 20ns access time compared to sub 1.0ns access time for a cache hit, you are looking at a performance hit that is two orders of magnitude slower than a cache hit. In case you are wondering, the TLB is the cache that is used by the memory management unit for translating virtual addresses into physical addresses.

        1. PghMike

          Re: Old is new again?

          The Sparc may or may not be vulnerable, but I don't think this explanation covers it.

          The Intel issue comes from a speculative code path loading data into the L1 cache from mapped but protected memory. This has nothing to do with TLBs -- the real question is whether the kernel address space is accessible to speculatively executed instructions.

          Intel's error came from allowing a speculative load to proceed even when the ring # was wrong to allow the access to complete.

      3. Anonymous Coward
        Anonymous Coward

        Re: Old is new again?

        SPARC systems based on SPARC V9 (since 1993) have Kernel page table isolation and so have separated kernel and process address spaces so should not be affected by Meltdown. Heres the documentation : https://books.google.se/books?id=3Ys27a_I1tEC&pg=PT552&lpg=PT552&dq=address+spaces+on+SPARC+systems&source=bl&ots=5mwktQtlHt&sig=mIu8LXvWq1LbN3kqS6PWP-5ldvU&hl=sv&sa=X&ved=0ahUKEwin_9OD2r7YAhXQJ1AKHUcIA38Q6AEIRjAD#v=onepage&q=address%20spaces%20on%20SPARC%20systems&f=false

    4. Gordan

      "as designed"

      Translation:

      "We don't consider it a bug, so unlike back in the '90s when we replaced all Pentium CPUs affected by the FDIV bug, we will not be replacing any affected CPUs, under warranty or otherwise."

      1. DonM.

        Re: "as designed"

        My years of working with crap EMC products spawned a new acronym - WADDI

        "Working As Designed - Designed Incorrectly"

      2. Roo
        Windows

        Re: "as designed"

        If that is by design then they have intentionally broken backwards compatibility with their in-order CPUs... Well played Chipzuki.

  2. Throatwarbler Mangrove Silver badge

    Questions

    If you patch your hypervisor and guest OS, do you take a double hit on performance?

    Also, according to Red Hat's security note, Spectre affects all CPUs that use speculative execution, including AMD, ARM, and POWER architectures. Are they incorrect?

    Finally, if you're going to label one vulnerability Spectre, why not call the other one SMERSH?

    Inquiring minds want to know!

    1. Glad Im Done with IT

      Re: Questions

      "If you patch your hypervisor and guest OS, do you take a double hit on performance?"

      As the bug is all about preemtive execution which happens at the microcode level you should only have to patch the hypervisor. Linux at least is allowing you to turn off the patch, presumably so guest OS does not have to take the hit as well.

      As for Windows that is anyones guess atm!

    2. Griffo

      Re: Questions

      Good question. MS are seeming to indicate that if the Hypervisor is patched, the guest is protected. So will the OS detect that it's running on a patched OS and not "double implement" the memory protection?

      https://azure.microsoft.com/en-us/blog/securing-azure-customers-from-cpu-vulnerability/

      1. Anonymous Coward
        Anonymous Coward

        Re: Questions

        The hypervisor patch protects the hypervisor provider, not the guest OS user.

        The guest isn't protected until it is patched.

        Azure/AWS/Goog etc are all protecting their infrastructure from pivots between customers. If customers don't patch their own systems they are unprotected. Remember cloud providers protect the cloud, customers protect themselves.

        There shouldnt be a double performance penalty though.

        1. teknopaul

          Re: Questions

          Not 100% but I dont think that is correct analysis, if its a hardware bug patched in hypervisor software, you dont need to patch virtual servers built on top. unless the virtualization software has the same bug as the hardware.

          Ie if the hypervisor flushed the data that was speculativly executed, its not there for the vm to abuse either.

          1. keith_w

            Re: Questions

            I think that the VM OS will have to be patched because the Guest will be accessing its own OS's version of the Kernel, not the Hypervisor's.

    3. Anonymous South African Coward Bronze badge

      Re: Questions

      Both Smert Shpionam and the Special Executive for Counterintelligence, Terrorism, Revenge and Extortion will not take kindly to be linked to a buggy CPU line.

      Consequences will be hard and harsh! Expect concrete shoes and chickenwire to be in fashion soon!

      1. John Smith 19 Gold badge
        Coat

        SPECTRE..will not take kindly to be linked to a buggy CPU line.

        Nonsense.

        From their PoV it's a "Business opportunity."

        As their CEO explained to one of their clients when he unilaterally doubled their price for some work

        "Extortion is my business."

        1. AMBxx Silver badge
          Windows

          Re: SPECTRE..will not take kindly to be linked to a buggy CPU line.

          If only the hypervisor needs to be patched, why are Microsoft rebooting affected Virtual Machines on Azure? Surely they can migrate them between patched hosts?

          MS being lazy, or something else?

          PS, I'm a software guy, not hardware or OS, so be kind...

          1. SolidSquid

            Re: SPECTRE..will not take kindly to be linked to a buggy CPU line.

            Not being at Microsoft I couldn't say for sure, but my guess would be the scale of the problem. They might just not have enough servers to migrate people en-mass that way and have found it's quicker and less risky to have a small amount of down time to just patch everything immediately

          2. MyffyW Silver badge

            Re: SPECTRE..will not take kindly to be linked to a buggy CPU line.

            [Intel CEO is invited to explain his share activities to long time investor E. S. Blofeld]

            "We don't take kindly to failure, Mr Krzanich. Security, please show Mr Krzanich my collection of tropical fish. The carnivorous ones will be particularly interesting..."

          3. Bunsen

            Re: HP Loses Another Good Manager

            In Azure, there is no Live Migration facility. Too much of an overhead on the network, hence them powering off the tenant VM, moving to a patched host and powering on again.

            1. Naselus

              Re: HP Loses Another Good Manager

              "In Azure, there is no Live Migration facility. "

              Azure has live migration now - you can pay extra for it.

              I'd guess that capacity and the scale of the issue is the bigger thing here; they need to patch every box in the datacenter and need to do it fast. Easier to just bounce all the hosts at once than schedule a bunch of VMs cascading across the network.

  3. highdiver_2000

    AMD not vulnerable

    What did AMD do, that got it right? Enquiring minds wants to know.

    1. DainB Bronze badge

      Re: AMD not vulnerable

      Probably made a mistake while copying Intel microcode.

      1. G.Y.

        Re: AMD not vulnerable

        X86-64 is an _AMD_ architecture, which Intel had to adopt after Itanium crashed &burnt. Guess who copied from whom ...

        1. Anonymous Coward
          Anonymous Coward

          Re: AMD not vulnerable

          Speculative execution exists in 32 bit mode as well. It's a basic need to ensure caches are kept filled.

          1. Roo
            Windows

            Re: AMD not vulnerable

            " It's a basic need to ensure caches are kept filled."

            Speculative execution keeps pipelines filled, filling caches is down to the memory controllers... ;)

        2. Anonymous Coward
          Anonymous Coward

          Re: AMD not vulnerable

          No doubt HP will be making a fuss about how Itanium isn't affected, while Intel & AMD x86 is. Love the irony.

          1. Anonymous Coward
            Anonymous Coward

            'how Itanium isn't affected'

            Just because it leaves speculation to the compiler. But I wouldn't be sure there could not be issue there as well.

            1. John Styles

              Re: 'how Itanium isn't affected'

              I was trying to work this out... on the whole I concluded I didn't understand enough to know but if the compiler generates code that does speculative loads aren't you still screwed (although of course you can't blame the processor, just the compiler). See https://blogs.msdn.microsoft.com/oldnewthing/20150804-00/?p=91181

              1. Phil O'Sophical Silver badge

                Re: 'how Itanium isn't affected'

                if the compiler generates code that does speculative loads aren't you still screwed

                I'd think not, or much less so. Speculative accesses inside the processor that never get committed could perhaps access memory that the user shouldn't have permission to touch, but compiler-generated speculative loads are going to have to use standard instructions, albeit it out-of-order. They will be constrained by the protections available to whatever context the complete instructions are executed in, i.e. a user process won't be able to access kernel memory.

                They're also easier to fix, either by a compiler patch or perhaps some post-processing of binaries.

                1. Dazed and Confused

                  Re: 'how Itanium isn't affected'

                  With the Itanium processor virtual addresses are global, the bits of the kernel have 1 set of virtual addresses while all user processes have other virtual addresses. The cache tags and the TLB basically know who a bit of addresses space belongs to. Sadly it's been too many years since I played that far inside the Itanium to remember whether there is a region register which is programmable from user privilege level (like there is 1 user programmable space register on PA-Risc) but even if a long virtual pointer were used from assembler the access would be blocked by the TLB's protection mechanism.

      2. DavidPeterRoberts

        Re: AMD not vulnerable

        If you think that then I suggest you educate yourself on chip architecture, x86 64 and kernel before making stupid nonsensical statements.

        1. Warm Braw

          Re: AMD not vulnerable

          The extensive Google Blog post suggests that AMD processors are only "less" vulnerable - and I don't imagine the investigations have yet stopped. Specifically, they found they could use side-channel attacks to get memory contents from the same process on an AMD chip (hardly a big deal, but still a warning flag) and they could read the entire contents of kernel memory on an AMD chip IFF the Berkeley Packet Filter (BPF) Just-In-Time compiler is enabled in the kernel. Is that an AMD bug or a Linux bug? Can you actually assign "blame"?

          Since the entire vulnerability is related to the relative execution time of cached and non-cached operations, it's difficult to believe that there are not other potential exploits to be discovered. The BPF issue is interesting because it means that the ability to inject any abitrary code into the kernel, even code that is statically proven to be "safe" in traditional software terms, is in fact a potential vector for side-channel attacks for which there is no obvious mitigation.

          That's a very big deal for a lot of Linux-based firewalls and probably many other applications.

          1. Loud Speaker

            Re: AMD not vulnerable

            they could read the entire contents of kernel memory on an AMD chip IFF the Berkeley Packet Filter (BPF) Just-In-Time compiler is enabled in the kernel.

            The name "Berkeley Packet Filter" should be a give-away - this is part of the firewall in FreeBSD derived systems, Linux uses a different firewall, as does OpenBSD. This may affect a large number of routers which use BSD derived code - a very high risk since, in most cases, (a) this is not obvious to the owner/user, and (b) they are very unlikely to be patched.

            Routers are a great target for malware - because they are Internet connected and always on.

            The good news is that this should be easily patched IF the manufacturer is threatened with sufficiently serious consequences - which may or may not include "cruel and inhuman torture" - IANAL.

            1. Warm Braw

              Re: AMD not vulnerable

              Linux uses a different firewall

              The Linux kernel supports eBPF since version 3.18 and the exploit was demonstrated using a Debian distribution, though by default eBPF would not be a configured kernel option so it might not be so widely used.

              It isn't necessarily an easy patch (for any architecture) and it applies to any JIT code (not just BPF), so I assume there may be some impact on nft for Linux. ARM recommend changing the code emitted by the JIT compiler using new conditional speculation barriers. I'm not sure what options are being proposed for other platforms, but they could well have performance implications of their own aside from those already being discussed.

          2. Warm Braw

            Re: AMD not vulnerable

            Bad form, I know, to reply to my own post, but there was one other thing that occurred to me.

            Computer architecture has historically assumed that you controlled your computer and the workload that ran on it. The protections in place were there largely to mitigate against mistakes - bugs in your software taking down other software or the computer itself. For the most part, your computer ran software whose behaviour was predictable. The improvements in memory capacity and CPU speed largely depend on that predictability.

            The reason that Spectre, Meltdown and, previously, Rowhammer are issues is mostly because the assumption of ownership is no longer valid. Either you have consciously chosen to run your software on someone else's computer (cloud) or it's possible that ownership of what you believe is your own computer has been ceded to criminals (possibly with the backing of state resources).

            If you control your own computer, it doesn't really matter if you can read the kernel memory from user space. If you don't, pretty much every statistically-based optimisation (whether it's DRAM stability or branch prediction) is up for exploitation by software that's designed to skew the statistics and either gain knowledge that it shoudn't have or deny service (for example by forcing cache flushes).

            Computer architecture hasn't changed a great deal in principle from the days of co-operative time sharing - perhaps it's time it needs to be reinvented for an explicitly hostile environment.

            1. phuzz Silver badge

              Re: AMD not vulnerable

              "If you control your own computer, it doesn't really matter if you can read the kernel memory from user space."

              Until you go to a website that has some dodgy javascript running in user space (natch), which can then start reading stuff in kernel memory (or presumably anywhere else).

              Unless you're writing or auditing every byte of code that runs on your computer, you have to start hoping that you truly control your computer.

              1. MrReal

                Re: AMD not vulnerable

                It is actually possible to get Javascript to do that?

              2. Paul 195

                Re: AMD not vulnerable

                Browser vendors are already rushing to prevent these attacks being exploitable from JavaScript. The attacks require precise timing measurements, so they are reducing the precision of timers available to JavaScript. This will make them very hard to exploit from JavaScript.

            2. Anonymous Coward
              Anonymous Coward

              "historically assumed that you controlled your computer and the workload that ran on it"

              Actually, no. Mainframes could run different workload for very different users, and when they started to rent their "time", they had to ensure separation of workloads.

              But x86 CPU have their roots in simple chips designed with no security at all. When protection mechanism were added, often they weren't use because the incurred overhead was deemed to high in performance terms.

              In many ways, mapping kernel memory to user space but keeping it "hidden" trough the paging mechanism is a kind of performance trick. From a security point of view, having to switch address space fully is much more secure - the problem is that with the current implementations that's slow.

              That's the same reason why the full four rings, segments, etc. were never used, too many cycle required when going through a ring boundary. IMHO CPU design should look at ways to reduce the security checks overhead properly, instead just trying to bypass it.

            3. Dazed and Confused

              Re: it doesn't really matter if you can read the kernel memory from user space.

              Re: If you control your own computer, it doesn't really matter if you can read the kernel memory from user space.

              Hardly.

              Take Berkeley Unix, which is where Unix page based memory management came from. The assumption here is that the computer is owned and run by the CS dept. but used by bloody students who's primary interest is in buggering things up. No OS designed has ever wanted to have it's internal data read by unprivileged user code. If such behaviour was considered a "good thing" then /dev/kmem would be world readable. The kernel often has data which should be private to other processes running on the same system so it damn well should ensure that it's private.

            4. JohnFen

              Re: AMD not vulnerable

              "If you control your own computer, it doesn't really matter if you can read the kernel memory from user space."

              This is true only if you personally wrote and/or did a proper audit of every piece of software your computer runs, and if it doesn't communicate with other computers.

              Otherwise, it matters.

            5. Loud Speaker

              Re: AMD not vulnerable

              Computer architecture has historically assumed that you controlled your computer and the workload that ran on it.

              Unix has historically assumed it was running on the University computer, and every single intelligent student was hell-bent on hacking it.

              Large machines prior to the advent of Wintel faced similar levels of attempted assaults - by people who had detailed knowledge of the architecture - including schematics, and many years of assembler experience with the knowledge that National security was at risk (or possibly CISC :-).

              The combination of developments that is Intel, MS, high level languages and the concept of a personal computer mean that machines developed with the security needs of an Apple ][ are now able to exceed the throughput of a Beowolf cluster of Crays.

              This took place without anyone thinking there might be a need to re-examine a few assumptions and review security consequences of incremental changes (or they did, and were told to keep their mouths shut).

        2. Anonymous Coward
          Anonymous Coward

          Re: AMD not vulnerable

          "If you think that then I suggest you educate yourself on chip architecture"

          there are 8 replies above yours.

          I suggest you learn to make it clear who you are throwing abuse at, to minimise collateral damage.

      3. Lars Silver badge
        Happy

        Re: AMD not vulnerable

        Sadly it doesn't seem to be "just" a microcode error that could be mended in the microcode.

        As for 64bit, AMD was indeed ahead of Intel but one could also point out that 64bit processors were available years before that.

        The Wiki on AMD 64bit:

        "The original specification, created by AMD and released in 2000, has been implemented by AMD, Intel and VIA. The AMD K8 processor was the first to implement the architecture; this was the first significant addition to the x86 architecture designed by a company other than Intel. Intel was forced to follow suit and introduced a modified NetBurst family which was fully software-compatible with AMD's design and specification."

        Ps AMD never copied Intel, the had tp do a "clean room" to do the microcode themselves.

        1. Roo
          Windows

          Re: AMD not vulnerable

          "Ps AMD never copied Intel, the had tp do a "clean room" to do the microcode themselves."

          That's flat out wrong. :)

          Back in the day various entities such as the "Defence" contractors and big vendors required a chip to have a 'second source' vendor. AMD entered into a licensing agreement with Intel to be the second source for x86 parts - thereby enabling Intel to tender for those contracts. At one stage AMD were literally given a set of masks by Intel, and AMD used them to punch out identical - so strictly speaking they did in fact copy the Intel parts, but quite legally as per their second sourcing agreements.

          As time has gone by AMD did some tweaks (eg: faster 286s, 386s, 486s which inspired Intel to unleash the lawyers at various points). Eventually they rolled their own in house designs (K5,K6,Opteron et al) - on the back of those second source agreements. Intel & AMD have continued to spend money in court wrangling over those agreements - but I think that's been settled for a good few years now.

      4. Doctor Syntax Silver badge

        Re: AMD not vulnerable

        "Probably made a mistake while copying Intel microcode."

        It's not microcode. It's hardware hardware. Do pay attention at the back.

    2. This post has been deleted by its author

    3. PghMike

      Re: AMD not vulnerable

      AMD probably check the current ring # allows a read before doing a speculative read. If the speculative path fails at that point, no data has leaked from the kernel.

  4. Jonbays

    The Intel security folks must be glad to be at arms length and McAfee again, all this PR spin no substance makes a mockery of the companies security posture. Someone other than a hacker somewhere must have been able to see the potential for side channel attacks and remediate them in the core design surely?

  5. Alan W. Rateliff, II

    KAISER, huh?

    So, the greatest trick Intel ever pulled was convincing the world its architecture was secure?

    1. Dr Scrum Master

      Re: KAISER, huh?

      KAISER. So, say...?

      1. tony2heads
        Joke

        Re: KAISER, huh?

        If they need a recall what about the KAISER bill?

    2. DropBear

      Re: KAISER, huh?

      Bah, humbug. Can we get back to bashing the usual suspects yet...?

    3. nkuk

      Re: KAISER, huh?

      I predict a riot.

      1. Anonymous Coward
        Anonymous Coward

        Re: KAISER, huh?

        They're on a roll, for sure.

  6. red03golf

    What's Not Mentioned

    I noticed there was no mention of the possibility this was an intentional act to boost product benchmark scores, compared to Intel's rival(s), by purposely avoiding a known processing bottleneck.

    It's certainly not tin-foil hat territory to expect corporations to cut corners to garner a competitive edge of rival products, with the understanding of we'll admit to the insecurity later, after we've made $BILLIONS in profit, and roll out the fix.

    Cynically, I have no doubt of shameful actions such as the above-mentioned, because rapacious corporations, C-level officers, and board members must absolve themselves of any human decency to maintain a position of privilege, and that supplants anything of value.

    1. amanfromMars 1 Silver badge

      Re: What's Not Mentioned .....

      I noticed there was no mention of the possibility this was an intentional act to boost product benchmark scores, compared to Intel's rival(s), by purposely avoiding a known processing bottleneck. .... red03golf

      Will the future cost and markets hit on Intel eclipse the $30 billion charge on VW for their dieselgate affair, for is not the game the same albeit it being played in another arena/industry/market?

      1. jmch Silver badge

        Re: What's Not Mentioned .....

        "Will the future cost and markets hit on Intel eclipse the $30 billion charge on VW for their dieselgate affair"

        That depends partly on whether proof can be found that this was a known vulnerability that was ignored, or just wasn't paid attention to in the rush for speed (willful harm vs [gross?] negligence ).

        Also, almost half the $30bn is in government fines . VW was in deep doo-doo because they circumvnted government-mandated tests. Even if Intel did this on purpose to boost benchmarks, it's not any government-mandated benchmarks so they are unlikely to face such large government fines. On the other hand, if they are subject to class action lawsuits, going over $30bn is quite likely since it involves almost every chip they made in the last 10+ years, meaning in practice almost every Intel chip currently installed.

        That also makes recall / replacement unfeasible because (a) they don't have any non-vulnerable chips to replace the bad ones and (b) even when (if?) they do, the scale would be too great to handle. Say 5 years production of chips just to replace faulty ones, meaning 5 years of zero revenue.

        Normally that would be enough for Intel to go bankrupt but I suspect it will somehow be saved, firstly because US gov will definitely intervene but also because for all Intel's (many, many) faults, the chip hardware industry like any other needs competition. An industry with only AMD and ARM providing chips is very closed-shop. I'd much rather see Intel survive but knocked back a few pegs, to end up with 3 big manufacturers competing on a much more level footing than they are now.

        1. Mage Silver badge

          Re: What's Not Mentioned .....

          CPUs used to plug in.

          Now they are BGA. So only patches, firewalls on servers, script blockers on Browsers are the overall solution.

          Smart TVs: Don't connect to Internet, they mostly won't get updates.

          IoT: You don't want them anyway.

          The mind boggles as to how this will get sorted. Though Intel is a USA company, so maybe they'll mostly ignore it.

          Years ago I thought "Out of Order Execution" was a performance boost at too high a cost. Debugging and timing issues. Messes up Real Time OS, where predicted speed /timing is more important than raw performance, "Out of Order Execution" causes jitter on physical I/O timing unless you have HW timer support and/or HW buffers with own IO CPU etc.

        2. Alan W. Rateliff, II

          Re: What's Not Mentioned .....

          So far as a class-action is concerned, where are the damages? Operating systems are fudging over the problem and there is no proof (yet) anyone was actually compromised with this vulnerability, so the likelihood of a class-action proceeding without real damages seems slim.

          Not saying Intel should not suffer in some manner for producing faulty kit, just that without any harm done there is nothing to claim in court.

          1. JohnFen

            Re: What's Not Mentioned .....

            "So far as a class-action is concerned, where are the damages?"

            Damages are easy to show for commercial users: there's the cost of remediation, and the cost of any reduced performance (which would necessitate purchasing additional hardware to make up for).

            The bigger question, in my mind, is... was there negligence? Honest mistakes and design oversights happen, and aren't necessarily something that you can successfully sue over. If, however, Intel knew, or if they should have known, there was a problem and sold the chips anyway, then we're talking actionable negligence.

        3. ArrZarr Silver badge
          Joke

          Re: What's Not Mentioned .....

          "An industry with only AMD and ARM providing chips is very closed-shop."

          Definitely, otherwise we'd have people going on about requiring more diversity in letters used for Chip Shop acronyms.

      2. Doctor Syntax Silver badge

        Re: What's Not Mentioned .....

        "$30 billion charge on VW for their dieselgate affair"

        That was an entirely different situation. VW isn't a US business.

      3. Dr U Mour

        Re: What's Not Mentioned .....

        I just upvoted amanfromMars ....

  7. oldtaku Silver badge
    Happy

    Thanks - I was eyerolling at the 'corrupt, modify, or delete' misdirection when I read the press release, but it's much funnier (har har, sob) when you do the whole schmear.

  8. Glad Im Done with IT

    "Funnily enough, no one said the security flaws could be used to directly alter data. Instead of talking about what these exploits don't do, let's focus on what they make possible."

    Get access to keys stored in trusted zone? I am sure pirates will not be patching so they can try to wander around areas of the security system not previously accessible by tricking kernel to load pages they want.

    Would the litigious media industry use 'operating by design' as an admission of fault?

  9. John Savard

    My initial reaction was, is this article really necessary? Of course they're going to put a spin on things. But while your first translation was a little harsh, I felt, the others were merely brutally honest.

    Security flaws are hard to anticipate, and processors are designed for performance first and foremost.

    Now, if there were a way to turn off the security fix for software trusted not to be trying to exploit anything, performance hits might be reduced...

    1. Anonymous Coward
      Anonymous Coward

      Come on!

      Intel PR tap dance was hilarious.

      Not to mention dishonest...

      1. John Brown (no body) Silver badge

        "Not to mention dishonest..."

        I'd go further and call it lying. Corporate lying. The person writing the PR may have been writing honestly based on what they had been told, but at least some of the people providing the information either lied outright or lied by omission. Arse covering, plausible deniable, all adding up to corporate lying.

        1. elDog

          You're surely not suggesting that someone higher up the Intel food chain made this cock-up and attempted cover-up happen?

  10. Anonymous Coward
    Anonymous Coward

    How high's the water mama?

    4ft high and Ryzen

    1. Known Hero
      Thumb Up

      Re: How high's the water mama?

      Oh this got a proper laugh from me !!!

      Thank you :D

  11. Merrill

    From Red Hat --

    There are 3 known CVEs related to this issue in combination with Intel, AMD, and ARM architectures. Additional exploits for other architectures are also known to exist. These include IBM System Z, POWER8 (Big Endian and Little Endian), and POWER9 (Little Endian).

    https://access.redhat.com/security/vulnerabilities/speculativeexecution

    1. Anonymous Coward
      Anonymous Coward

      Other CPU architectures affected by Spectre...

      https://tenfourfox.blogspot.co.uk/2018/01/is-powerpc-susceptible-to-spectre-yep.html

      PowerPC too apparently, although I imagine a much smaller install base. I have an old unaffected Atom based board here somewhere that could be used to run a pfSense based firewall or something but I think it contains the Intel Management Engine so err.. maybe not. Surprised this didn't surface as part of the Shadow Brokers releases as surely nation states know about this kind of thing already? Anyway whoever first shares some easily reusable exploit shell-code for 'testing' this spectre vulnerability to grab juicy secrets might be speculatively executed anyway!

      1. Merrill

        Re: Other CPU architectures affected by Spectre...

        Interesting. I wonder whether SPARC, MIPS, Loongson, Sunway, etc. are vulnerable to Spectre?

        We keep forgetting that 1) all scripts and executables shall be executed without modification only from read-only storage, and 2) the read-only storage shall be modified only by a trusted configuration management process.

        1. Jamie Jones Silver badge

          Re: Other CPU architectures affected by Spectre...

          Geeze, at this rate I'll be dusting the cobwebs off the old ZX Spectrum...

  12. really_adf

    Gamers largely unaffected by KPTI?

    I'm surprised at the note in the article (and elsewhere according to an admittedly brief search) that game performance is not significantly affected by KPTI. Talking to hardware such as a storage controller or network card is mediated by the kernel; this is necessary for security and stability. And applications doing this are affected.

    Game code, running on the CPU, needs to continually update the "world" the graphics card draws so, like an application heavy on storage or network I/O, I'd inductively expected games to frequently need kernel transitions and be highly affected. Can anyone enlighten me as to why this is apparently wrong? Is low level access to control the GPU provided into userspace, or are operations batched up to reduce the number of transitions, or..?

    1. bazza Silver badge

      Re: Gamers largely unaffected by KPTI?

      Pure guess here - it may be just one single kernel transition to update the world per frame. Which wouldn't be so bad (50 per second?).

      1. really_adf

        Re: Gamers largely unaffected by KPTI?

        "Pure guess here - it may be just one single kernel transition to update the world per frame."

        Yeah, that's the sort of thing I was thinking of by "batched up". I'm sure once (or even a dozen times) per frame would make KPTI utterly irrelevant from a performance perspective.

    2. Stumpy

      Re: Gamers largely unaffected by KPTI?

      Once the connection to the framebuffer has been established, I'm pretty certain that the game then just talks directly to the video card so likely no Kernel transitions needed at all after the initialisation. Possibly, if the game needs to tear down the connection and re-init the display (eg: if graphics mode has been reset, or if new shaders need to be compiled) .. but generally these chores are done during setup and then left alone during gameplay.

    3. DropBear
      WTF?

      Re: Gamers largely unaffected by KPTI?

      Considering that a certain game I'm having trouble wrestling with performance-wise currently is so network-hungry that the network LEDs never go off and the (beyond miserable) current framerate is actually acknowledged to be server-code-limited (!!!), and also due to its minimum RAM requirements of 16GB it typically trashes the page file so incessantly on anything with less RAM that the main suggested fix on forums is to move that to an SSD (until it melts right through it...) - I'm, erm, SLIGHTLY skeptical that "gamers" need not be concerned.

      1. Baldrickk

        Re: Gamers largely unaffected by KPTI?

        a certain game I'm having trouble wrestling with
        Care to share just what game that is? or is it one in development still and these are problems that will be ironed out?

      2. Alistair
        Windows

        Re: Gamers largely unaffected by KPTI?

        @dropBear:

        Your description puts the game my middle child is all over right now to mind, and being that the game itself is a) Alpha phase b) crowdfunded and c) being built by an agile devops hipster high on maccha most of the time I suspect that the issues will get worse before they get better. And they problems have zilch to do with this pair of bugs, although the bugs will make the game far worse, extend the deveopment time, and increase the crowdfunding demand.

        1. DropBear
          Devil

          Re: Gamers largely unaffected by KPTI?

          Well then, everyone seems to have a perfect grasp on which game it is - yeah, that one... :) And yes, I do know the mentioned issues are of course not caused by these bugs or their fixes, but I do believe the fixes would impact the already piss-poor performance which is why I mentioned it at all. Fingers crossed performance will get finally addressed at some point of course, but at this rate that's effectively the same thing as "never", and until I see effortless high performance in that game my concerns that disk/net access penalties _will_ have an impact remain...

          1. Daniel Garcia 2

            Re: Gamers largely unaffected by KPTI?

            Are you by chance talking about the epic $170M crowdfunded black hole? Just only looking their C# scripts on YouTube videos where they ironed out bugs, you can clearly see where the issue is...

            1. DropBear

              Re: Gamers largely unaffected by KPTI?

              Yup. One of my pet facepalm issues is how some of the bugs they apparently already fixed in one of those videos are somehow still happening right now...

    4. Voland's right hand Silver badge

      Re: Gamers largely unaffected by KPTI?

      Ditto the rather daft comment about joe casual user.

      While he will not notice things slowing down (the CPU has grunt to spare), he will notice a 30%+ battery hit. Some of it from cost of IO (cpu burning more), some of it from cost of idling (going into idle and out now costs more too).

  13. John 104

    And Nothing about Google?

    Those twats are responsible for this late night patch frenzy that my company and countless thousands more, are dealing with. Their excuse for releasing the details is thin at best. So now, instead of a small number of nefarious types speculating about these exploits, the whole world + dog knows and vendors were forced to release their patches out of band. Good job ass holes.

    1. Anonymous Coward
      Anonymous Coward

      Re: And Nothing about Google?

      What's interesting is that their 90 days deadline once again is not enforced when their own systems are at stake...

    2. Destroy All Monsters Silver badge
      Devil

      Re: And Nothing about Google?

      Those twats are responsible for this late night patch frenzy that my company and countless thousands more, are dealing with. Their excuse for releasing the details is thin at best.

      Messenger, blamed, much?

      You seem to be upset. Your company may exhibit panicpants syndrome. Maybe IT is not for you.

      We find that The team said in a blog post that it discovered the vulnerability in May 2017, and quickly notified Intel, AMD, and ARM.

      Sounds like more than 90 days. And what is this "out of band release forcing" you are talking about?

    3. Anonymous Coward
      Anonymous Coward

      Re: And Nothing about Google?

      You didn't have to have a patch frenzy last night. You could have carried on and hoped that it wasn't exploited - that's what you've been doing for the last 10 years anyway?

      Security researchers already new about the issue for at least 6 months, people were writing code into Linux that was visible in the source. There were mermerings from many o=people that something big was about to hit and The Register had already reported the issue yesterday.

      So what most decent sysadmins wanted after that was detail so they could mitigate as much as possible and manage the risk (would you have preferred that the only people who knew about it were security researchers of the "white hat", "grey hat", "government hat" and "black hat" brigades or would you prefer to have a patch that allowed you to get on with fixing it?). Therefore it looks like Google decided to provide that detail. If the patch is available then the vulnerability is known and you would need to have a patch frenzy anyway - if you're on about timing (having to do it at night) then lots of people somewhere will always have the patches landing in the evening or night - something to do with timezones.

      If you live your world of security vulnerabilities by "in band" patch Tuesdays then I suggest your company has more problems than the details of a potentially game changing flaw being released.

    4. James O'Shea

      Re: And Nothing about Google?

      The problem has been known, to some, for months. It’s been known long enough that _Apple_, not known for rapid patching, already quietly patched macOS! Apparently it’s only a partial patch, but it was out _before_ the news broke! And an alleged full patch is due with the next ‘in band’ update, currently in beta! If you boys are so slow that _Apple_ beats your ass to getting updates out, you’re got other problems, mate!

  14. Sceptic Tank Silver badge
    Windows

    SecureString

    Who on earth stores passwords and sensitive info in clear text, even in the kernel? There is always the chance that the kernel memory can be hacked or even just written out to the page file. .NET even has a type called SecureString that constantly decrypts and encrypts its contents and prevents the data from landing up in the page file. The data is kept in unencrypted form for the least amount of time possible. Performance is apparently utterly rubbish but that is the price you have to pay.

    1. Sceptic Tank Silver badge
      Facepalm

      Re: SecureString

      Meh ... I suppose SecureString has to keep it's keys somewhere too ....

    2. Jamie Jones Silver badge

      Re: SecureString

      There is always the chance that the kernel memory can be hacked or even just written out to the page file.

      Pffft. What kinda system still uses swapping to a file? and unencrypted swapping too?!

  15. Anonymous Coward
    Anonymous Coward

    What's not taken into account

    What's not taken into account is the extra time sys admins have to fucking patch systems. Intel are not paying us by the hour.

    1. Anonymous Coward
      Anonymous Coward

      Re: What's not taken into account

      You mean what should be sysadmins normal and everyday job - keeping systems safe and running - is an exception?

      I'm afraid too many look for a sysadmin job just to watch porn at work without being caught by firewall rules and proxies logs... that's probably why they accepted a contract without clear provisions for overtime and off-hours availability....

  16. Anonymous Coward
    Anonymous Coward

    What I want to know is will this effect the performance of Flash and Internet Explorer? Is there going to be a patch for XP?

    Silliness aside won't all webpages server side file system and database calls be hit by this?

    1. BinkyTheMagicPaperclip Silver badge

      Taking your silliness seriously, yes, there *should* be a patch for the supported (embedded) versions of Windows based on XP, as they're still in support until 2019..

  17. Anonymous Coward
    Anonymous Coward

    Daily Telegraph hackette on the BBC World Service this morning

    displayed utter ignorance in trying to explain what was happening.

    1. Anonymous Coward
      Anonymous Coward

      Re: Why can they not...

      Just get it right? Something like "It's like a tiny leak in a cars radiator" or "It's like an MI6 office worker going to the pub and ordering drinks for James Bond Super Spy, and forgetting to keep it secret."

      Mechanics is not the necessary explanation given, just the fact that data is in the wrong place at the wrong time. That tends to be a simple explanation?

      1. Anonymous Coward
        Anonymous Coward

        At TechnicalBen, re: an analogy.

        How about "The maker of your car's engine included a design flaw for the last ten years. They've been caught & admitted it. The fix will rob your engine of up to 30% of it's total power. In other words it won't go as fast, it will get worse mileage, & will have to work harder to do nearly everything. Other professionals in the industry have called it (insert the full length version of the acronym here), a total mouthfull, but it'll be better known by it's nickname of Fartwit."

        It breaks it down to sound bites the public can absorb, gives it a descriptive & catchy nickname, & gives anyone whom wants it the ability to research for more info.

        I just wish American airwaves weren't so strangled by prissy nannies so we could actualy say aloud on the telly "They call it Fuckwit due to the level of utter stupidity involved in the design flaw. Intel knew it was wrong, knew it would bite them on the ass once it was brought to light, & decided to do it anyway because it made their numbers look better than their competition. Only now they're actually *worse* than the competition once the fix is applied, because any speed gains the flaw gave them are entirely destroyed by the fix required to stop it from fucking the rest of us over. Fuckwittery indeed!"

        *Cough*

        Fuck it. my next computer chip is gonna be a Dorito!

    2. Steve Davies 3 Silver badge
      Facepalm

      Re: Daily Telegraph hackette on the BBC World Service this morning

      Rob Enderle (remember him from SCO Days...????) was on Radio 5's 'Wake up to Money'.

      What he said was IMHO, meaningless gobbledegook (aka Marketing Triplespeak).

      From what I've read, onlt certain ARM Cpu's are affected but he implied that all ARM powered phones were vunerable.

      I must remember to switch off entirely when his name in mentioned.

    3. Anonymous Coward
      Anonymous Coward

      Re: Daily Telegraph hackette on the BBC World Service this morning

      Anybody at all "on the BBC" is likely to display utter ignorance, otherwise they wouldn't be working for the BBC or invited to speak.

      If, by some freak of chance, someone who does know what he is talking about gets on air, you can trust the BBC drones to cut them off before they get fairly started.

      1. amanfromMars 1 Silver badge

        Re: Daily Telegraph hackette on the BBC World Service this morning @Archtech

        How very odd that some who be down voters here do not realise the perilous state of parlous play which occupies and governs the BBC.

        Just try to find anywhere on their virtual systems where you can voice an opinion on what they are pushing ....... you know, something as simple and effective as a comments facility which as El Regers will know provides hidden gems of information which prevent crass arrogant and ignorant brainwashing of the masses for a crooked see on worlds their programs would be presenting.

        Anybody here old enough to remember the BBC good old days/better beta times whenever fab forums were aplenty and The Great Debate ruled the news airwaves and discovered all manner of shenanigans and offered virtually anonymous remedies for next day/next week presentations ....... which is probably why the BBC www platform is now practically neutered ...... for one can't have anonymous beings leading the news with their undeniable views whenever corporations are so reliant upon secrets being hidden and tall tales being trailed?

        1. nkuk

          Re: Daily Telegraph hackette on the BBC World Service this morning @Archtech

          ? The BBCs article on the subject does have a comments section: http://www.bbc.co.uk/news/technology-42561169

          1. amanfromMars 1 Silver badge

            Re: BBC's Not Fit for Future Greater IntelAIgent Games Purpose

            The lament is still valid, nkuk, for service provided today is but a sad shadow of its phormer self, and let's not get started on the non state of political comment during the fact.

            Anyone would think there was an active conspiracy to mislead and/or hide the real state of affairs from that and those who would tuning in to turn on.

            1. Anonymous Coward
              Anonymous Coward

              Re: BBC's Not Fit for Future Greater IntelAIgent Games Purpose

              Anyone would think there was an active conspiracy to mislead and/or hide the real state of affairs

              Whatever you do, don't listen to French radio news then. Anything which might show France in a bad light never gets a mention. It's worse than US TV.

          2. Anonymous Coward
            Anonymous Coward

            Re: Daily Telegraph hackette on the BBC World Service this morning @Archtech

            "The BBCs article on the subject does have a comments section"

            Whatever you do don't go there! It's filled with brexit remainers of the far right and left persuasions and is generally devoid of all intelligent life.

          3. Roland6 Silver badge

            Re: Daily Telegraph hackette on the BBC World Service this morning @Archtech

            The BBCs article on the subject does have a comments section:

            The BBC have done several articles on the subject; not all have comments sections:

            Jan 3: Major flaw in millions of Intel chips revealed - No comments section

            Jan 4: Rush to fix 'serious' computer chip flaws - Has comments section

            Jan 4: Intel, ARM and AMD chip scare: What you need to know - No comments section

            Jan 4 - 4 hours ago: Meltdown and Spectre: How chip hacks work - No comments section

            I think you will find that the majority of articles on the BBC don't have comments sections.

        2. kain preacher

          Re: Daily Telegraph hackette on the BBC World Service this morning @Archtech

          Have I been on el reg to long? I've understood the last two post be a man from Mars 1. And this last post made sense.

        3. Shadow Systems

          At the imposter A Man From Mars1...

          Whom are you & what have you done with the real AMFM1? I can tell it's not the real one because I could understand that post!

          Imposter! Tell us what you've done with the real one! =-)p

        4. CrazyOldCatMan Silver badge

          Re: Daily Telegraph hackette on the BBC World Service this morning @Archtech

          Has the "@amanfromMars 1" bot been re-written to do proper language parsing and construction? That's two posts now that appear to be in actual English :-)

      2. John Brown (no body) Silver badge

        Re: Daily Telegraph hackette on the BBC World Service this morning

        "Anybody at all "on the BBC" is likely to display utter ignorance, otherwise they wouldn't be working for the BBC or invited to speak."

        There was a Reg guy interviews on BBC R4 at lunchtime. He seemed to be struggling with explaining it in a way Joe public would understand. He didn't sound too experienced at being interviewed, but then I suppose he's paid to be the interviewer, not the interviewee :-)

      3. CrazyOldCatMan Silver badge

        Re: Daily Telegraph hackette on the BBC World Service this morning

        Anybody at all "on the BBC" is likely to display utter ignorance

        T'missus already has a finely-tuned filter for me griping about technology journalism..

    4. CrazyOldCatMan Silver badge

      Re: Daily Telegraph hackette on the BBC World Service this morning

      displayed utter ignorance

      I've yet to see a mass-media[1] 'technology' journalist that actually knew anything about actual technology. As far as I can see, most of them are just breathlessly regurgitating manufacturer press-releases..

      [1] El-Reg doesn't count as 'mass media'..

  18. Mark 85

    Mixed signals on CPU's

    Is there a definitive list of the affected CPU's by type instead of generic "Intel"? I'm hearing everything from "just few years worth of CPU's" to "all the way to the beginning of time".

    1. A Non e-mouse Silver badge

      Re: Mixed signals on CPU's

      It goes a long way back. If the CPU has:

      * a Memory Management Unit

      * a memory cache

      * a branch predictor

      * Supervisor & User modes

      It's highly likely to be affected. (and the last one might not even be required)

      All of those features have been in CPUs for many, many years.

      1. ilmari

        Re: Mixed signals on CPU's

        So basically every CPU since the Pentium Pro / Pentium II?

        Get a CPU older than 20 years and you'll be fine.

        1. herman

          Re: Mixed signals on CPU's

          I think an Intel 8080 processor running MSDOS 6.2 at 500 kHz should be fine.

          1. Peter Gathercole Silver badge

            Re: Mixed signals on CPU's @herman

            I don't believe MSDOS ever ran on the 8080 processor, which was 8-bit.

            The lowest would have been an 8088, as per the original 5150 IBM PC, which is a 16 bit processor with an 8-bit data bus and an 20-bit address bus, allowing 1MB of physical memory.

          2. elDog

            Re: Mixed signals on CPU's

            And if you limit your connectivity to 8" floppies and perhaps 300baud modems. But no internet!!!!

        2. Roo
          Windows

          Re: Mixed signals on CPU's

          Apparently early Atoms before they decided to bless them with OOO execution are OK.

      2. Anonymous Coward
        Anonymous Coward

        Two different exploits

        There are mixed signals because there are two different exploits. One affects Intel and not AMD, allows reading arbitrary kernel memory, is not difficult to exploit, and the fix has a performance hit which is larger the more often your CPU enters/leaves kernel mode (i.e. syscalls, driver interrupts, context switches, etc.) This is the one that hit the media in the last couple days.

        The second one affects both Intel and AMD, allows a process to read its own memory and while it is very difficult to exploit the prospective fixes have almost no performance impact. Normally you wouldn't care if a process can read its own memory, except in cases where it is trying to run a sandbox - like a browser running Javascript. Rogue Javascript code on a web site could access the browser's memory, though with modern browsers using multiple processes that's less of a concern than it would have been a few years ago. Given how many browser exploits there are that can do much worse, this isn't bad for home users.

        The problem with the second exploit is they aren't sure if it can actually be completely fixed, so it may be something we just have to live with. If so we can always hope this it will be the death knell for Javascript like Steve Jobs was the death knell for Flash!

        1. Pccapso

          Re: Two different exploits

          On the second exploit, it was only confirmed on AMD FX CPUs, no idea whether it applies to their current architecture, but AMD says that the vulnerabilities have "near zero impact".

      3. Loud Speaker

        Re: Mixed signals on CPU's

        My memory may be a bit weak in the management areas due to lack of coffee, but AFAICR:

        * a Memory Management Unit - everything after the 8086

        * a memory cache - everything after the 80386

        * a branch predictor - Probably Pentium 1 and up

        * Supervisor & User modes - everything after the 8086

        I think there is slightly more to the story than what you said. Specifically, the issue

        depends on how the MMU works, and how it is used.

        I have not been involved in CPU design for over 30 years BUT:

        I would not expect user mode code to have any way to be aware of the MMU's internal

        operation.

        * The MMU should disallow access to all virtual pages not in use by the current task.

        * Addresses in the current user address space not mapping to physical memory should map to either a virtual address saying "illegal access" or to one saying "You will need to swap me in before you can read me"

        * there should be NO way to access physical memory that does not go via the MMU - not even for speculative instruction or data fetch.

        The bug reports seem to describe noticing that a speculative fetch that goes unused causes a delay which can be used to identify the value of data FROM THE DELAY. I dont understand this. If the speculative address names is not in cache, then how is fetching it speculatively justified?

        Conclusion - This is not MMU - this is cache management - which SHOULD do a similar thing to what the MMU does BUT ISN'T DOING IT. The bug is (partly) that you can read data in the cache that is not yours. This is not really a risk UNLESS: There is some way to find out whose it is.

        While MMU pages are normally 4k bytes, cache lines are more like 16 bytes. Fetching 16 bytes from "somewhere", with no way to find (or control) which page of whose address space they belong to is not a significant risk, although obviously undesirable. In normal circumstances, your next attempt to do this would probably fetch from a completely different page in a different task.

        Clearly we are not being told the whole truth here.

        It seems more like there is a way to FORCE the caching of other people's address spaces and make that visible to you. That gives you security on a level with a Commodore Pet. If so, then yes, Intel may have to replace every CPU since on chip caching (probably Pentium 1).

        1. Phil O'Sophical Silver badge

          Re: Mixed signals on CPU's

          The bug reports seem to describe noticing that a speculative fetch that goes unused causes a delay which can be used to identify the value of data FROM THE DELAY. I dont understand this

          The results of a speculative fetch of a bit can be used to decide which of two other addresses, accessible to the normal user, are read from while still in the speculative execution branch. Whichever one is chosen will end up in the cache, even if the actual results are discarded.

          Then, after the incorrect speculative branch work is discarded and the program control returns to the user, it reads from both those addresses and times the operations. The one that returns quickly is the one already in the cache, which is the value that was read during speculative execution. That, in turn, allows you to determine what the value of the speculatively-read bit was, even if you can't actually read that bit from the user program. Over time you cycle through the whole kernel address space, bit by bit.

          That's my reading of the PoC, anyway.

  19. Detective Emil
    Thumb Up

    More deconstructions of PR flim-flam, please

    I realise that El Reg has skin in the game on this one, but there's so much stuff out there just waiting to be mauled. Uber's humblebrags offer a prime target; AirBnB emitted something that made my stomach heave yesterday … Disruption? Hah! All these outfits disrupt is my digestion.

    1. Anonymous Coward
      Anonymous Coward

      Re: More deconstructions of PR flim-flam, please

      I think that the previous comment should come with a translation.

      Was it written by AManfromMars under an alias?

      1. Anonymous Coward
        Anonymous Coward

        Re: More deconstructions of PR flim-flam, please

        "Was it written by AManfromMars under an alias?"

        A single line comment by AMFM today on the previous article for this topic was very lucid.

        Ve said "Just a coincidence, A Non e-mouse ........ not."

      2. kain preacher

        Re: More deconstructions of PR flim-flam, please

        I understood it fine. He meant with all the other stuff going on on the tech world why is el reg making a big deal of this one story. Then again I'm able to read most of a man from Mars 1 posts.

    2. NXM Silver badge

      "Disruption"

      My translation of this is "not paying our taxes or the law".

  20. A Non e-mouse Silver badge

    Late to the party

    Translation: We were gonna say something next week, but those bastards at The Register blew the lid on it early

    The speculation had started before Christmas. El Reg was certainly not the first to blow the lid on this.

    1. Mark 85

      Re: Late to the party

      Nor will they be the last. I'm waiting for various government agencies to suddenly realize they have piles of insecure computers.

    2. Adam 52 Silver badge

      Re: Late to the party

      No but the Reg article got picked up by the BBC. At which point real people noticed and not just a bunch of geeks, so Intel had to act.

      This article is proper journalism, one that the Reg should be proud of.

    3. diodesign (Written by Reg staff) Silver badge

      Re: Late to the party

      We made it go mainstream. Our Tuesday report was the basis of Bloomberg, Reuters, NYT, CNBC and BBC coverage - we were even cited and linked.

      I dunno how many people saw your speculation pre-Tuesday but our articles this week are seven-figures in terms of page views.

      C.

      1. ArrZarr Silver badge

        Re: Late to the party

        @Diodesign

        Sorry if this is just me being an idiot, but from what I've seen, there was a planned release date for the flaw on the 9th which has been brought forwards due to articles released on El Reg earlier than that. Isn't making it go mainstream before this date kind of a bad thing?

        1. Allonymous Coward
          Alert

          Re: Late to the party

          Isn't making it go mainstream before this date kind of a bad thing?

          Depends how you define "bad", and for whom, I guess. Their articles this week are seven-figures in terms of page views and they get to write snarky articles about Chipzilla, so I'd say it's working out pretty well over at Reg World HQ. Triples all round.

          I enjoy watching Intel get stiffed for insecure design and PR waffle as much as the next person. I also respect The Register for holding the industry to account, and not just on this issue. But it'd be interesting to be told why they decided to publish early. Not that I expect we will be.

        2. Baldrickk

          Re: Late to the party

          It was going mainstream anyway, The Register were just first to that party.

          Basically, as soon as Linus revealed that there was a kernel patch that would have a notable performance penalty, the whole thing was going to be exposed.

          Apple + MS reporting the same? not so much as it is closed source, but as Linux is open source, any changes are in the public domain as it were.

          To the best of my knowlege, The Register didn't sign any NDA.

          1. John Brown (no body) Silver badge

            Re: Late to the party

            "Basically, as soon as Linus revealed that there was a kernel patch that would have a notable performance penalty, the whole thing was going to be exposed."

            Not to mention the fact that as soon as a FOSS patch is released, the code is available for all to see and read, albeit in this case with the code comments redacted to make it a little more difficult. The various parties involved may have agreed to a dated embargo, but the source code can't be held back till then.

        3. Androgynous Cupboard Silver badge

          Re: Late to the party

          Isn't making it go mainstream before this date kind of a bad thing?

          I'm pretty sure that's how journalism works.

          Biting the hand that feeds IT. It's even on the masthead.

        4. diodesign (Written by Reg staff) Silver badge

          Re: "Isn't making it go mainstream before this date kind of a bad thing?"

          We asked Intel what was going on, twice, and had no response - not even a no comment, or an off-the-record explanation. We were certain with what we had - given the LKML discussions and information from other sources - so, why not warn the world that big changes are coming?

          We offered no exploit code. Just a heads up that important alterations were being made to crucial bits of software. It's not our job to do companies' PR. We can't read minds.

          And these changes were being done in the open, so any bad people paying attention could have known what we knew or more, and started exploiting it.

          A lot of vendors hold us at arm's length, hoping we'll go away. We regularly get the silent treatment from various - but not all - companies. We're not going to sit on stories just because we get a no comment/no reply. Turned out this one was quite a big one. We had no idea it would be this big.

          C.

          1. Jamie Jones Silver badge
            Thumb Up

            Re: "Isn't making it go mainstream before this date kind of a bad thing?"

            I felt almost a sense of pride seeing The Register being quoted all over the place!

            Here's hoping that Apple and the others finally realise ignoring you is not a good decision.

          2. Allonymous Coward

            Re: "Isn't making it go mainstream before this date kind of a bad thing?"

            @diodesign thanks for taking the time to give some more background. I was wondering if it'd turn out to be vendors not treating the news/enquiries with enough respect (in hindsight).

            <Papa loads his shotgun, sighs, shakes head, and takes the PR department behind the woodshed>

          3. ArrZarr Silver badge
            Thumb Up

            Re: "Isn't making it go mainstream before this date kind of a bad thing?"

            @Diodesign

            Thank you for the explanation. It is appreciated.

      2. Boris the Cockroach Silver badge
        Joke

        Re: Late to the party

        I dunno how many people saw your speculation pre-Tuesday but our articles this week are seven-figures in terms of page views.

        -----

        Which is great for the employees of el-reg as they can have the heating on all week and afford to go down the pub friday :)

      3. Roland6 Silver badge

        Re: Late to the party

        >We made it go mainstream. Our Tuesday report was the basis of ... and BBC coverage

        Recommend from listening to the BBC Radio News interview of the El Reg reporter, that El Reg invest in some verbal communication and media skills training. The poor guy obviously wasn't used to talking to the media, but well done for standing up and doing the interview.

  21. Anonymous Coward
    Facepalm

    For shame!

    Andy Grove will be turning in his grave

    1. Destroy All Monsters Silver badge

      Re: For shame!

      ...if the grave is bug-free.

    2. elDog

      Re: For shame!

      But he'll be turning 30% slower!

  22. StripeyMiata

    I have a machine with a Via C7 processor

    It's used as a little fanless media server, although to be honest a Raspberry Pi could probably replace it. Does anyone know if that CPU is affected?

    1. Phil O'Sophical Silver badge

      Re: I have a machine with a Via C7 processor

      although to be honest a Raspberry Pi could probably replace it. Does anyone know if that CPU is affected?

      Seems that neither RPi processor is affected: https://developer.arm.com/support/security-update doens't list A-7 or A-53

  23. Anonymous South African Coward Bronze badge

    Excellent El Reg, keep up the pressure.

  24. Ben 56

    This is why

    I love the Register, it's like Dummies Guide For Buzzword/Bullsh*t Bingo.

    Keep up the fantastic journalism!

  25. ForthIsNotDead

    Still on sale?

    I presume that with Intel being a "responsible company that is committed to customers blah fucking blah" that they have withdrawn all affected silicon from sale until the problems are corrected and new silicon is launched?

    1. GrumpyOldBloke

      Re: Still on sale?

      Only the silicon that is not operating as designed.

  26. Anonymous Coward
    Anonymous Coward

    I wonder how long

    the NSA knew about this????

    1. sveinskogen

      Re: I wonder how long

      I'd guess they knew about it when they designed it? This smells "clipper" all over again.

  27. Anonymous Coward
    Anonymous Coward

    translation

    Intel and other technology companies have been made aware of new security research describing software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operating as designed.

    Translation: When malware steals your stuff, your Intel chip is working as designed. Also, this is why our stock price fell. Please make other stock prices fall, thank you.

    You did better, or well, on translation of other bits of canned statement further down, but the one above is simply a mistranslation, and not even that funny. I'm disappointed, because I expected better, i.e. BITING and SUBTLE humour, not cheap sarcasm. More a nibbling vulture, than a ripping pigeon...

  28. Anonymous Coward
    Anonymous Coward

    When chips get designed by machine intelligence all our security worries will disappear, I'm looking forward to the first generation of Skynet CPUs to go into my Colossus build.

    1. John Brown (no body) Silver badge

      Is that you Prof. Forbin?

    2. Roland6 Silver badge

      > I'm looking forward to the first generation of Skynet CPUs to go into my Colossus build.

      Better hope that A.L.I.E. doesn't get there first.

  29. This post has been deleted by its author

  30. joeldillon

    'Chipzilla doesn't want you to know that every Intel processor since 1995 that implements out-of-order execution is potentially affected by Meltdown – except Itanium'

    Well, yes. That's because Itanium DOESN'T implement out-of-order execution. That was its whole USP, that the compiler would do the instruction ordering not the CPU.

  31. Anonymous Coward
    Anonymous Coward

    Intel: 'Everything works as designed.'

    Same PR as with everything 'IoT'... When are we going to have 'Bowfinger' for the tech industry? Silicon-Valley's Reality-Distortion-Field, Meinf-heads!

  32. Fading
    Paris Hilton

    Gamers?

    Keep seeing that gamers will be unaffected. But surely that only applies to local gaming? Any online multiplayer server will be hitting the I/O hard, and your own network card gets a fairly good workout on a 64 player server?

    Bench-marking multiplayer modes is always difficult (as you cannot standardise the test) - and whilst local frame rates may not be impacted, latency will be?

  33. MrReal

    While the americans search around for some way to blame the Russians or Iran from this I was thinking that there may be an upside:

    As each app is carrying around a copy of the kernel this will use a lot more memory, so splitting them off should result in a single copy of the kernel which should in theory reduce memory usage and help the cache - which should in itself speed up the OS, or at least compensate for the slowdown.

    Any thought?

    1. Anonymous Coward
      Anonymous Coward

      Any thought?

      Apps don't each have a copy of the kernel, they just map the single copy into their virtual adddress space. No duplication.

  34. tomviolin

    Did they KNOW?

    This is clearly a security flaw that many people could have spotted and just didn't. HOWEVER I do believe that this calls for a serious investigation. If there was internal research at Intel or ANY chip manufacturer that revealed this class of flaws and covered it up, this would prove legal liability.

    This could be incompetence on the part of Intel. Sure. But all the information needed to spot this flaw has been out there for some time. The real question we should be asking is: did they know about it and intentionally cover it up FOR SELFISH REASONS. Withholding details of a flaw for a short time — until a fix, workaround, or other mitigation strategy is devised — is standard industry practice. But if they covered it up just to save their own asses, then they should pay the price.

  35. KD_

    Hi all,

    Very interesting article and discussion.

    I have 1 question, is the patch likely to affect online/multiplayer gaming?

    (Yes I understand that regular gaming is not affected, just wondering what happens with network gaming)

    Thanks

    1. GrumpenKraut

      > ...affect online/multiplayer gaming?

      Unlikely. The additional delay (even under pessimistic assumptions), when added to every UDP packet, should not be noticable. Properly programmed games should work smoothly even if the delay gets noticable, being prepared for network latency.

      This will hurt processes with _massive_ amounts of syscalls. Think "find / " and data bases.

  36. Klondike_Mike

    Kernel bypass?

    Would using kernel bypass mechanisms like DPDK, Netmap, etc. mitigate the impact to networking-heavy applications to any extent? Or do the patch fixes need to be installed in all cases, and will still impact performance, regardless of whether you use a kernel bypass mechanism or not? This is mostly a Linux kernel question, just trying to understand the dependencies and whether any mitigation is possible...

    1. James 47

      Re: Kernel bypass?

      You'll need to install the patches anyway just to be safe; but yes, kernel bypass would mitigate the effects of calling the kernel being made more expensive. I'm not sure how much effect kernel bypass would have on virtual machines like AWS though. Maybe someone here could comment, I'm interesting in faffing about with it.

  37. Zippy_UK

    DON'T PANIC! DON'T PANIC!...

    INTEL - the computing equivalent of ENRON...

    "WinTel" - Keeping computing in the Stone age where it belongs /SARC

    INTEL - "At least we are not RBS"

    INTEL - "..it was the Russians what done it.."

  38. Anonymous South African Coward Bronze badge

    The Fall of the House of Intel

    The Rise of the House of AMD

    Game Of CPU's

    1. John Brown (no body) Silver badge

      "Game Of CPU's"

      Game of Silly-Con[e]s

  39. Anonymous Coward
    FAIL

    Non-Event Horizon

    My anus is your Singularity, Kurzweil. Still waiting... maybe it's just a bad system call... blah, blah, blah...

  40. Steve Evans

    "operating as designed"

    So your design was bad then...

    1. Anonymous Coward
      Anonymous Coward

      Re: "operating as designed"

      Can't help wondering how much US security alphabet agencies helped with the design in the first place.

  41. smackbean

    Killed photo's app on HighSierra

    Thank you for filling in the blanks as to why my recently upgraded (to High Sierra) mac book air is now running like a dog and going through the battery in a couple of hours (this is a huge change from before the upgrade when I could comfortable get 5/6 hours from editing using the photos app which was easy and quick to use).

    Apple support are not interested. My mac book air is still under 1 year warranty so I can get a full refund on that (presumedly?) Does anybody know if I will be able to get a full refund for an over 1 year old mac book pro also?

    I think I might return both if possible - anybody tried this?

    Apple support thread...

    https://discussions.apple.com/message/32813718?start=30&tstart=0

    1. BinkyTheMagicPaperclip Silver badge

      Re: Killed photo's app on HighSierra

      It's very unlikely that's the cause, and benchmarks so far are showing a degradation in the order of 10-12% in affected applications. Most user apps won't be affected.

      1. Alan Sharkey

        Re: Killed photo's app on HighSierra

        OK - as a home user, here's a couple of data points for you to consider.

        MS have issued the patch for Windows 10. which takes you from build .125 up to build.192.

        I ran a handbrake video conversion before and after and also ran the passmark test before and after. This was on my I7-3770.

        Handbrake. Before: average FPS 168. Time taken - 18mins.

        Handbrake. After: average FPS 167.5. Time taken 18 mins 20 seconds.

        Passmark. Before After

        Total 3219.7 3228.7

        CPU 8214 8224

        2D 557 561

        3D 3585 3605

        Mem 1752 1758

        Disk 2444 2409

        So, the only thing that seems to have suffered is disk I/O and that by around 1.5%

        YMMV - this is just what I found.

        1. KenJ

          Re: Killed photo's app on HighSierra

          My understanding is that the performance impact from forcing a context switch is highly dependent on the model cpu involved. Newer cpus (whatever that means) see less of an impact. Will be interesting to see a comprehensive analysis.

          1. smackbean

            Re: Killed photo's app on HighSierra

            Well, I purchased mine from Apple only 6 months ago (decent spec), but I think it is the same basic model that has been in existence since 2015 or so- so maybe the impact on my machine is more than on other more recent machines. The performance hit that I've seen is app slowness, quick drainage of battery, and also excessively warm laptop on lap...

            It really is a pile of sh*t now.

        2. Anonymous Coward
          Anonymous Coward

          KB4056892

          KB4056892 is the patch number to go from Win10 1709 build 16299.125 to 16299.192 but seems to include loads of known issues, probably a little too rushed. Certainly worth testing though.

        3. Hawkeye Pierce

          Re: Handbrake

          But that's what I'd expect for something like Handbrake which is not going to be hitting the kernel much. Written efficiently, it will load a chunk of video in from the disk, work through that, spit it out and then load another block. In the broad scheme of things, only that disk access is going to suffer, and that's (simplistically) once per block read or block write. It's not going to be hitting the disk on a frame-by-frame basis, and the kernel's not going to be used for converting the frames.

      2. smackbean

        Re: Killed photo's app on HighSierra

        Thanks but how do you know? My new mac book air has become unusable overnight. An apple support thread indicates this is a common problem. No-one has had any response from Apple. How can I trust the benchmarks - who is producing them?

        It may be a combination of the intel patch and also lack of care in the upgrade process (for OS and app) of course

        1. BinkyTheMagicPaperclip Silver badge

          Re: Killed photo's app on HighSierra

          I know by reading the literature. One of the key parts of confirming an issue is to only change one thing at a time, and you've upgraded your entire operating system. The likelihood is therefore that the OS upgrade is the cause of the issue.

          To be sure, downgrade your OS to the initial release of Sierra and benchmark performance. Then upgrade to the latest Sierra patch and run exactly the same benchmark.

          If performance at this point nosedives, complain to Apple. Otherwise upgrade to High Sierra. Run the benchmark again. Apply the latest High Sierra patch and run the benchmark again.

          I strongly suspect upgrading to High Sierra will be your issue.

          1. smackbean

            Re: Killed photo's app on HighSierra

            ok fair enough, thanks for the info

  42. Mark Pattison
    Joke

    Time to...

    raise the Itanic?

  43. GreenBit

    Inexcusable

    So, major blunder intel, but we'll patch it up in s/w. Nevermind the fact your performance is going back to 2010 levels. So the question is, once they have all the OS's borked to cover their screw-up, will they ever FIX their screw-up? If I had to wager..

  44. ptbbot

    Intel going all Tory on us. Maybe they should have also said they offer a strong and stable microarchitecture that benefits millions of hard-working families? Had enough of experts telling us we've not got it right?

    No contrition whatsoever. Poor show.

  45. Anonymous Coward
    Anonymous Coward

    AV issues/missiing server patches - WTF

    Oh look - you can only get the MS patches if your AV vendor stops making unsupported kernel calls, otherwise the patch will Blue Screen your machine. https://support.microsoft.com/en-us/help/4072699/important-information-regarding-the-windows-security-updates-released

    Not to mention that the only patches available as of today are for Win 7, 8 and 10. No server patches at all. It's going to be a fun month.

    1. thosrtanner

      Re: AV issues/missiing server patches - WTF

      > Oh look - you can only get the MS patches if your AV vendor stops making unsupported kernel calls,

      > otherwise the patch will Blue Screen your machine.

      Well, duh. You dig around in the kernel and call bits of it, your code is going to be very unstable. At least MS have done something so that the users won't unexpectedly be nuked (or at least no more unexpectedly than normal). It's probably rather hard to apply subsequent patches if your system keeps blatting itself because the AV program checks the subsequent patch...

  46. Gary Bickford

    “Works as designed” - of course, that is the usual case.

    From my days of teaching Software Quality Assurance, over 70% of bugs in shipping production code were built into the design at the beginning. IIRC the intent of methods like Extreme Programming was to help catch many of these design flaws by including representatives of the “customer” in the design team and using iterative design.

    There is no reason to expect that the hugely complex chip design process is very different, even though they must of necessity be much more rigorous in their design process and re-use existing modules extensively. This latter allows each module to be debugged independently over time. But the interactions between modules that is a critical performance factor in the modern chip designs must be extremely difficult to 7nderstand, much less account for in the higher level design process. And the chip design process today looks a lot more like software than hardware. Designers must depend on their CAD system (another beast of high com0lexity and its own bugs!) to correctly manage the low level interactions.

    For regular software, the statistics show that if you are using reasonable design methodologies, in shipped production software there is roughly one bug in every 200 lines of code, regardless of the language. (The difference between low level and high level languages was strictly in the impact of a given bug, not the probability.) But about 10-15 years ago MS mentioned they apron about one in 70, I suspect due to their practice of hiring young hotshot SW people who had not learned defensive programming. And again, mod5 of the remains bugs in shipping code came from the design.

    Perhaps most scary: less than 50% of the remaining bugs were likely to be discovered in black box testing.

  47. Lord_Beavis
    Trollface

    Fixe it for you

    Translation: Don't click on any bad links or emails, you rubes. And for God's sake stay off of PornHub!

  48. James 47

    Intel: the new Nokia

    I've hated Intel every since my Virgin Media modem came with a Puma chipset.

  49. Anonymous Coward
    Anonymous Coward

    Basic flaw

    The basic flaw seems to be that the processor allows the cache to be updated by out-of-order and speculative execution before knowing whether that path will be taken and committing the register updates. Seems like anything fetched by out-of-order and speculative execution should be held outside of the cache and only committed to the cache causing a cache update when the path is known to be taken and the registers are committed.

  50. Anonymous Coward
    Anonymous Coward

    Other Vendors

    Will this effect Cisco and other vendors who use the affected chips with a Linux OS sitting on top acting as a firewall, router or switch

  51. JmJohnson

    Installed the hotfix...

    Noticeable performance hit with Entit Framework and SQL Server Developer.

    System Spec:

    Core i7-6700K

    32GB RAM

    2TB 960 PRO NVMe

    Time to disable it... run a full benchmark, re-enable it, repeat.

    I have a feeling my IOP's have suffered.

  52. Michael Sanders

    Games unaffected?

    I'm afraid I don't buy the claim that games are unaffected. Some basic shooter shouldn't be. But the game AI/game mechanically intense, large map or MMORG will. Anything that fills the cache will too.

  53. Tom Paine

    Good grief

    Intel believes these exploits do not have the potential to corrupt, modify or delete data

    The problem with spraying marketing bullshit at people familiar with expressions like "corrupt, modify or delete" is that we're not quite as stupid as the general consumer. We know bullshit when we see it -- possibly thanks to the past 25 years of this sort of crap.

    Come on, Intel. Sir Humphrey would be embarrassed by this sort of crap. Don't insult us; we expect a much better class of bullshit than this.

  54. Anonymous Coward
    Anonymous Coward

    Stock and Options

    In the wake of the Equifax ballsup a few months ago, some Directors of that company caught quite a bit of flak for the obviously innocent selling of stock at $149 just before it crashed to $109.

    The Directors and other senior players in Intel are also honourable men and women. I doubt that any of them have cashed in on their stock in the period between the discovery of this mess and the publicity of the last days. I don't think this would happen.

  55. sloshnmosh

    Raspberry PI

    I have over 30 computers and you're telling me that my Raspberry PI is the most secure device in my house?

  56. ZebraSomething

    First, Thanks to The Register for breaking this story ahead of the "coordinated disclosure."

    Second, Thanks for the translation of Intels response, I needed that!

    These kind of things gets me to the boiling point. The behemoth-corp that basks in self fabricated awesomeness when presenting their latest and greatest then revealing a revolting lack of spine and honesty towards their costumers when something like this occurs. The very same costumers they've built their entire wealth on. Taking a stance like the costumers were their subjects or some cattle that just should get back into the fold. Not a hint of self criticism or acknowledgement of the manufacturer/costumer relations that is the base of the entire operation! Show some dignity, it's good PR, I can guarantee you that!

    Now, I'm not pretending to be knowledgeable in these matters but calling this a bug seems to me like seeing King Kong hanging of a building and saying -Look, a bug. Pentium FDIV was a bug.

    Lastly, the question (and I've seen this floated here and there in various forms). Was this done intentionally?

    This kind of flaw would be any surveillance agencies absolute nirvana, yes?

  57. J.G.Harston Silver badge

    I'm puzzled how something that effects i86 systems also effects ARM systems. They are completely different CPUs translating completely different byte-code streams into actions.

  58. Anonymous Coward
    Anonymous Coward

    Will Intel be held accountable

    Since there is no means to patch the security violation architecture used in Intel CPUs the real question is will Intel be held accountable for choosing to violate roper security design practices to gain a minute increase in CPU performance while literally endangering the entire world? Intel knowingly chose to violate proper security procedures.

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