Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Intel Security

By Next Week, Intel Expects To Issue Updates To More Than 90% of Processor Products Introduced Within Past Five Years (intel.com) 289

Intel said on Thursday that by next week it expects to have patched 90 percent of its processors that it released within the last five years, making PCs and servers "immune" from both the Spectre and Meltdown exploits. The company adds: Intel has already issued updates for the majority of processor products introduced within the past five years. By the end of next week, Intel expects to have issued updates for more than 90 percent of processor products introduced within the past five years. In addition, many operating system vendors, public cloud service providers, device manufacturers and others have indicated that they have already updated their products and services.

Intel continues to believe that the performance impact of these updates is highly workload-dependent and, for the average computer user, should not be significant and will be mitigated over time. While on some discrete workloads the performance impact from the software updates may initially be higher, additional post-deployment identification, testing and improvement of the software updates should mitigate that impact. System updates are made available by system manufacturers, operating system providers and others.

This discussion has been archived. No new comments can be posted.

By Next Week, Intel Expects To Issue Updates To More Than 90% of Processor Products Introduced Within Past Five Years

Comments Filter:
  • by Joe_Dragon ( 2206452 ) on Thursday January 04, 2018 @01:46PM (#55863835)

    Intels updates also slow down AMD chips that don't have the bug as well. And AMD had to come out with there own update to back off the big slow down fix that Intel patch

    • by Anonymous Coward on Thursday January 04, 2018 @02:00PM (#55863915)

      Bear in mind that there are two vulnerabilities, Meltdown and Spectre. Meltdown is currently Intel-only, but Spectre is Intel, ARM and AMD. Both use similar techniques to access kernel memory (Meltdown) and local process memory (Spectre).

      Ref: https://isc.sans.edu/forums/diary/Spectre+and+Meltdown+What+You+Need+to+Know+Right+Now/23193/

      Note that this info came from the above link, and the SANS discussion I attended over lunch today: There's a lot of changes happening with this right now.

      • Doesn't AMD have a hardware feature of encrypting RAM pages, which might mitigate exploits like this (one VM will only get garbage if it manages to access another VM's space, for example?)

        • by Megol ( 3135005 )

          No as "spectre" makes the victim process access data and expose that to the attacker.

          • by Hal_Porter ( 817932 ) on Thursday January 04, 2018 @02:59PM (#55864377)

            The AMD scheme does AES-128 on the fly when reading anything from DRAM (!)

            https://lwn.net/Articles/69982... [lwn.net]

            There are two separate features-Secure Memory Encryption (SME) and Secure Encrypted Virtualization (SEV)-that both use the same hardware support that will be provided in upcoming processors. That support includes an AES-128 hardware engine inline with the RAM and memory controller so that memory can be encrypted and decrypted on the way in and out of the processor with "minimal performance impact". The data inside the processor (e.g. registers, caches) will be in the clear; there will just be a "little extra latency" when RAM is involved.

            It seems like the ASIC (the AMD equivalent of Intel PCIDs which actually predates PCIDs) - is part of the AES key.

            The hypervisor then allocates an "address space identifier" (ASID), which is what identifies the guest (and the key for that guest's memory). That ASID is provided to the secure processor with a request to generate or load a key into the AES engine and to encrypt the BIOS/OS image using that key. The hypervisor then sets up and runs the guest using the ASID assigned; the memory controller, AES engine, and secure processor will work together to ensure that the memory is encrypted and decrypted appropriately.

            On the other hand it's aimed at hiding hypervisor data from guest OSs and vice versa. It's not designed to hide process or kernel data from other processes on the same OS. Then again AMD isn't vulnerable to the KPTI hole as far as I can tell - that's to do with Intel's implementation of speculative execution.

            Of course AMD might be vulnerable to other bugs like this. Like you say, Spectre seems to affect "Intel, AMD and ARM".

            https://www.exploit-db.com/doc... [exploit-db.com]

            Spectre attacks involve inducing a victim to speculatively perform operations that would not occur during correct program execution and which leak the victim's confidential information via a side channel to the adversary. This paper describes practical attacks that combine methodology from side channel attacks, fault attacks, and return-oriented programming that can read arbitrary memory from the victim's process. More broadly, the paper shows that speculative execution implementations violate the security assumptions underpinning numerous software security mechanisms, including operating system process separation, static analysis, containerization, just-in-time (JIT) compilation, and countermeasures to cache timing/side-channel attacks. These attacks represent a serious threat to actual systems, since vulnerable speculative execution capabilities are found in microprocessors from Intel, AMD, and ARM that are used in billions of devices

            If AMD are confident enough in their AES engine to put in in inline with the RAM and memory controller, they could probably work out how to make it do process isolation by encryption. E.g. if you could set it up so kernel memory was AES 128 encrypted with a random key then it would matter less if a user process was able to read it.

            But what happens when you have virtualization? AMD's scheme protects guests from hosts. I'm not sure how you could additionally protect kernels in a guest OS from processes in that same guest OS.

        • by higuita ( 129722 )

          that encrypted RAM pages protect you from someone physically accessing the RAM and steal the data... it is a known weakness for all the hardware and only encrypting the RAM directly protect that.

      • by buchanmilne ( 258619 ) on Thursday January 04, 2018 @02:37PM (#55864199) Homepage

        Bear in mind that there are two vulnerabilities, Meltdown and Spectre. "Meltdown is currently Intel-only, but Spectre is Intel, ARM and AMD. Both use similar techniques to access kernel memory (Meltdown) and local process memory (Spectre)."

        But the patches rolling out now are only for Meltdown, fixes for Spectre are still not merged and are being actively worked on (and require compiler changes, and patched kernels compiled with a suitably-patched compiler).

      • by cdu13a ( 95385 ) on Thursday January 04, 2018 @03:02PM (#55864405)

        Unfortunately there are some things that won't change about it. Mainly the number of people that can't manage to understand what is going on.

        Speaking of which, I have to go buy a few bottles of hard liquor before my mom hears about this on the news and phones me to ask about the bond villains (SPECTRE) that are trying to meltdown the worlds computers.

      • Does anyone know how this is going to affect the embedded world?

        For next generation hardware we're looking at consolidating embedded PPC, 68k, PIC, etc to ARM.

      • by The Cynical Critic ( 1294574 ) on Thursday January 04, 2018 @03:40PM (#55864697)
        A further thing to keep in mind: Spectre, the less serious but more widespread vulnerability, is most serious on Intel. In Google's tests using 3 proof-of-concept variants, one non-malicious and two non-malicious, only the non-malicious one worked universally while the malicious ones only worked problem free on Intel. One of the malicious ones did work on one of the two tested AMD parts, but only in a non-default configuration (while Intel was vulnerable in the default configuration as well).
      • by WaffleMonster ( 969671 ) on Thursday January 04, 2018 @05:18PM (#55865281)

        Bear in mind that there are two vulnerabilities, Meltdown and Spectre. Meltdown is currently Intel-only, but Spectre is Intel, ARM and AMD. Both use similar techniques to access kernel memory (Meltdown) and local process memory (Spectre).

        This description is very misleading because it makes it sound like the two issues are similar when they very much are not.

        Meltdown provides processes with access to memory contents they have no right to access.

        Spectre is merely a side-channel timing attack. Similar issues have been known about for years exploiting static caches, hyper threading, branch prediction, DPA...etc. Spectre is little more than a PR smoke screen for Meltdown. The two are not in the same league and they don't deserve to be described as if they are close relatives.

        • by DamnOregonian ( 963763 ) on Thursday January 04, 2018 @06:07PM (#55865545)

          This description is very misleading because it makes it sound like the two issues are similar when they very much are not.

          No, they are. "Meltdown" should be considered a subset of the "Spectre" class of vulnerabilities.
          While AMD is not vulnerable to Meltdown variants that can be mitigated with KPTI, they're still vulnerable to Meltdown variants that can manipulate the kernel into doing the speculative execution for them- as the Google PoC demonstrated, eBPF with JIT (though disabled by default).

          Spectre is merely a side-channel timing attack. Similar issues have been known about for years exploiting static caches, hyper threading, branch prediction, DPA...etc. Spectre is little more than a PR smoke screen for Meltdown. The two are not in the same league and they don't deserve to be described as if they are close relatives.

          They're both side-channel timing attacks. They both exploit a race condition between instruction retirement after a fault in a superscalar architecture. The difference is that AMDs execution units can't specifically leak the data, because their L1 caches store and honor privilege bits. However, if that speculative execution happens in the kernel context (eBPF JIT) then userspace can still pick up the side-channel leaked data, making even AMD vulnerable to a subset of Meltdown, itself a subset of Spectre. Clear?

    • by Anonymous Coward on Thursday January 04, 2018 @02:31PM (#55864135)

      Intels updates also slow down AMD chips that don't have the bug as well. And AMD had to come out with there own update to back off the big slow down fix that Intel patch

      This is both somewhat true and highly misleading. The team that releases the Linux kernel, headed by Linus, created a patch to address the issue. Programmers paid by Intel may or may not have contributed code to the patch, but regardless, accepting or rejecting their contribution was up to Linux and the normal kernel team. The original patch did not distinguish between AMD and Intel chips, but it was not in any sense an "Intel update." It was just a change to the way the kernel operates which mitigated the bug but also introduced some performance penalties. AMD programmers then provided another patch that bypassed the mitigation patch on AMD processors to avoid the performance penalties. This is standard procedure for not only the Linux kernel but most large software projects. Fix the vulnerability for everyone, then look at whitelisting situations which do not require the fix.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      None of this is right unless you're being sarcastic.

      The fix that (at first) slows down AMD chips is a Linux kernel patch. It didn't come from Intel, at least not directly, and it only matters to Linux. It's likely that that version of the fix won't even get used on most systems because there are already better versions.

      This whole article is talking about a microcode update, which is mini-firmware for the CPU. OS vendors need to deploy the update (you have to get microcode updates through the OS, though only

      • Exactly. The article implies Intel released a microcode update that fixes the problem for 90% of its processors, but that couldn't be further from the truth. They've already determined that the problem can't be fixed with a microcode update. Instead, operating systems have to work around the problem.

        • by arth1 ( 260657 )

          Red Hat just came out with a new kernel and microcode update.

          Only three Intel processors have updates so far:
          Family 6, model 63, stepping 2 (Xeon E5-1650)
          Family 6, model 79, stepping 1 (i7 6950X)
          Family 6, model 85, stepping 4 (i7 7820X)

          Of course, more may be coming.

        • by 110010001000 ( 697113 ) on Thursday January 04, 2018 @03:48PM (#55864747) Homepage Journal
          Exactly. As CERT originally said, the only solution is to replace your Intel processor:

          Solution

          Replace CPU hardware

          The underlying vulnerability is primarily caused by CPU architecture design choices. Fully removing the vulnerability requires replacing vulnerable CPU hardware.
    • by tomxor ( 2379126 )

      Intels updates also slow down AMD chips that don't have the bug as well. And AMD had to come out with there own update to back off the big slow down fix that Intel patch

      I think your mixing things up... this announcement is for microcode update, microcode is specific to a CPU, you can't apply an intel's CPU microcode to an AMD, they are implementation specific and cryptographically signed.

      The AMD slowdowns are from kernel patches that do not discriminate between Intel and AMD, those patches are not from Intel they are efforts of kernel developers of the various major OS.

  • by Joe_Dragon ( 2206452 ) on Thursday January 04, 2018 @01:49PM (#55863845)

    class action time!

    I need one to pay for new MB for ones that don't get bios updates anymore.
    I need one to pay for the lost of speed

  • by Joe_Dragon ( 2206452 ) on Thursday January 04, 2018 @01:51PM (#55863865)

    supermicro I want an 1P EPYC board NOW! Intel is in deep and 2 AMD EPYC cpus is very over kill when 1 can hit the level of 2 intel ones.

  • Marketing (Score:3, Informative)

    by Anonymous Coward on Thursday January 04, 2018 @01:51PM (#55863869)

    Intel hasn't patched anything. Operating systems are trying to work around these bugs, but for some of the bugs, that's essentially impossible, and the only solution is to not run software that exploits these bugs.

  • 5 Years? (Score:4, Insightful)

    by PingSpike ( 947548 ) on Thursday January 04, 2018 @01:55PM (#55863883)

    Does the issue only apply to CPUs newer than 5 years ago or did Intel just decide if your CPU is older than that they don't actually care? I'd previously heard anything since the original pentium up to the P4 was where it began.

    • It affects much older CPUs, but anything older than 5 years is EOL and not supported.

      I am one of the most Intel Fanboi's here (just look at my post history) and even I can't absolve any of this, other than I can accept the flaw is so old no one thought about it in modern CPUs... but now that it's discovered it needs to be handled like the FDIV bug: uC patch what can be patched with no or trivial (less than 2%) performance issue. If it can't be patched it needs to be replaced.

      Not sure how to handle the EOL

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        They really should update everything, but maybe they're just starting with the newer ones.

        Failing that, they should at least go back to Conroe, which was pretty much their first CPU that would actually be useful in 64-bit mode. It also means that there's a simple "core=fixed, pentium=vulnerable" understanding for users. But Nehalem was probably the first CPU that was regularly used with more than 4GB of RAM. Any of those would be, in some way, acceptable, but only going back to Haswell is just going to enco

        • myself included...

        • My gaming computer is still a Nehalem i7 860 with 16GB RAM. It's had a couple of video card upgrades, but the CPU has been good enough up until now.

          I've been hoping it would hold on until the Ryzen 2 is released, but I have no brand loyalty (recently I've built machines for people using both Ryzen and Coffee Lake). The way this gets handled by the manufacturers will feed into my decision strongly.

        • by tomxor ( 2379126 )

          but only going back to Haswell is just going to encourage a lot of people to buy new CPUs. From AMD.

          Indeed, that is my personal conclusion, unless they go back further with the microcode, no more Intel for me.

    • by sl3xd ( 111641 )

      I doubt it's so much that Intel doesn't care about hardware older than 5 years, so much as they're prioritizing newer hardware. (Supporting older hardware rapidly reaches the point of diminishing returns).

      I'm pretty sure my 2007-era Core2 MacBook will never see a fix from Apple or Intel. I could probably "get" a patched OS on it by switching to Linux... but it's easier for me to put the MacBook out to pasture and use my Raspberry Pi 3 instead.

    • by higuita ( 129722 )

      5 years?! no, everything above and including pentium 4 should be vulnerable... so that excludes the all the XXX86, iX86, pentium, pentium 2, pentum III ... and of course, itanium... or maybe not, probably that one is also vulnerable, but no one cares...

  • Aside from games I have a little virtual lab at home running on VM Ware. That and some Virtual Box VMs and a couple Virtual PC ones under Win 7. I'm hoping this doesn't tank my guest' OSes performance. I just upgraded to an i5-7500 and my bro got an i7-4690k last year.
    • by sl3xd ( 111641 )

      Phoronix did a few benchmarks on games [phoronix.com]

      Of course, each game is a different animal, but it looks like there may be reason to hope that games aren't heavily affected.

      • I've heard that the newest Intel CPUs weren't hit as bad. I'm wondering how my i5-7500, i5-4560 and my brother's i7-4690k are going to fair...
        • by sl3xd ( 111641 )

          The thing to look for is "PCID" instruction support. Intel CPU's without the PCID instruction are slowed more than those that have it.

          I've done some looking at various machines at work, home, etc, and have found a Broadwell Xeon E3-1276 that has the PCID instruction but the older Ivy Bridge doesn't. (And I'm sure the PCID support also depends on the model of the CPU -- maybe Xeon has it while i7 doesn't)

          The mitigations for the "Meltdown" bug affect context-switching most: So an application that hits the dis

  • by Anonymous Coward on Thursday January 04, 2018 @02:01PM (#55863921)

    The flaw is concisely explained in this article.

    https://spectreattack.com/spectre.pdf [spectreattack.com]

    In particular, it says the following.

    Here is an example of exploitable code:

                if (x < array1_size)

                          y = array2[array1[x] * 256];

    In this example, the variable x contains attacker-
    controlled data. The if statement compiles to a branch
    instruction, whose purpose is to verify that the value
    of x is within a legal range, ensuring that the access to
    array1 is valid.

    For the exploit, the attacker first invokes the relevant
    code with valid inputs, training the branch predictor to
    expect that the if will be true. The attacker then invokes
    the code with a value of x outside the bounds of array1
    and with array1_size uncached. The CPU guesses
    that the bounds check will be true, [then] speculatively exe-
    cutes the read from array2[array1[x] * 256] using
    the malicious x. The read from array2 loads data into
    the cache at an address that is dependent on array1[x]
    using the malicious x. The change in the cache state is
    not reverted when the processor realizes that the specu-
    lative execution was erroneous, and can be detected by
    the adversary to find a byte of the victim's memory. By
    repeating with different values of x, this construct can be
    exploited to read the victim's memory.

  • The article says that Intel is releasing patches for processors up to five years old. That would suggest that they're going as far back as Haswell. It would have been nice if they were a little more specific as to where the line is drawn.

    I assume these patches are being released in the form of microcode updates that will be pushed out to end-users in the form of system BIOS updates. My worry is that we're going to see the Android-effect where older motherboard manufacturers will simply refuse to provide

    • I think I'm beginning to understand the update process.

      1. Flaw found in infrastructure. Devs scramble for solution.
      2. Devs find a way to fix this but the fix requires OS patching to mitigate the risk first, then the hardware needs an update.
      3. Software players send out notifications they are doing Stuff and Things, OS vendors send out updates, people start rebooting servers.
      4. Cloud vendors who control their hardware platform deploy CPU/BIOS level updates as they've already patched their systems at the Soft
      • Wrong. You cannot fix this flaw using software or microcode. The only way to fix this is to replace the flawed microprocessor. The fixes being released just mitigate the threat.
        • Do these fixes mitigate the threat AND the performance loss?
          • I don't know if they help with the performance loss, or even what the performance loss really is. I'm not an expert, but I do know this isn't fixable in software or microcode. The explanation of the flaw makes this clear. I am talking about the Intel flaw though, not the other one.
          • Re: (Score:3, Interesting)

            by higuita ( 129722 )

            the fix will mitigate the threat... for the intel, the fix will clear the cache after any jump between kernel and userland, so it gives a big performance hit when that happen... there is no microcode that can solve this, its the hardware design in the intel that is broken, it only check if the branch is invalid AFTER loading it.
            AMD is immune to the meltdown because the hardware detects the invalid branch BEFORE loading it

            So without hardware change from intel, you will either have the full performance, but i

            • by jwhyche ( 6192 )

              So how bad a threat is this if just decide to forgo the patch and run naked? I don't run crapwear or download drivers from whatever source has them. All my games come from steam and almost all my other software comes from companies that I've been doing business with for years.

      • 6. Asus, HP, Dell, IBM, Lenovo send out BIOS updates to consumers and business' to upgrade their BIOS with new microcode given to them by Intel which then assists in the patching done prior.

        So are IBM Power and System z processors also affected by this bug . . . ?

        Hey, this is almost like real hardware bugs we had in the good old days, when flies would short out the wiring in room sized computers.

  • Can’t the kernel just hide the password handling and crypto stuff in a separate address space and use the regular method for the boring stuff? Then cache-flushing would only need to happen sometimes rather than every time. Aren’t some big parts of the kernel “who cares if this data is exposed”?

    I’m asking because I don’t know.

    • How would a kernel know what is your gmail password and what is your grocery list?
      • by Kohath ( 38547 )

        It doesn’t (unless it does some of the gmail password handling somehow). It knows about its own internal sensitive data. I thought that was what was exposed.

        Also, I was asking because I don’t know exactly how all this works. If you do, then maybe answer...? If you don’t, then maybe someone else will explain it to both of us.

        • Actually Google has a really good overview: https://googleprojectzero.blog... [blogspot.com]

          The short story is that there is no fix to stop any process from reading the entire memory contents of the machine. You need to replace the Intel processor with processor that doesn't have this flaw to fix this problem.
          • by Kohath ( 38547 )

            Actually Google has a really good overview: https://googleprojectzero.blog... [blogspot.com]

            Saw that. It needs an executive summary.

            I can't find the answer to my question there. Even if I read it carefully, I don't know if it would have the answer.

            The short story is that there is no fix to stop any process from reading the entire memory contents of the machine. You need to replace the Intel processor with processor that doesn't have this flaw to fix this problem.

            Too many people are working on OS changes for that to be believable. If an OS change is irrelevant, then why bother implementing it?

            • You can make it harder to exploit, but the flaw is in the hardware and is fundamental to the Intel architecture. At this point if you are really worried about it you need to replace all your Intel processors that contain this flaw with ones that do not.
            • If the front of your house is made out of completely transparent glass, yes, you can build a fence (and hope nobody brings a step-ladder,) you can install curtains (don't forget not to open them!) you can hire guards to stand around in front of them keeping people away (but hope they don't get bored/inattentive/bribed/lazy/corrupt) and so on, but fundamentally, unless and until you rebuild that wall not to be utterly transparent, it's utterly transparent.
        • It seems the more immediately dangerous exploit (for normal users, anyway. AWS surely has a different viewpoint about what is dangerous) isn't against kernel space, it's an exploit that lets Javascript jump out of its VM: that is, a process attacks itself.
    • Can’t the kernel just hide the password handling and crypto stuff in a separate address space and use the regular method for the boring stuff?

      As soon as you start using these tricky approaches, security gets really hard. For an analogy, look at crypto: in theory you can make it secure, but in practice adding nice little (seemingly insignificant) features suddenly changes the attack surface in a way that makes side-channel attacks possible. Bruce Schneier thus says if you want security, you need to make it as absolutely simple as possible.

      Another example: consider the mechanism of "root" and "userland." In concept, it is clear, but in practice t

      • by Kohath ( 38547 )

        This is a good answer, thanks. But...

        Bruce Schneier thus says if you want security, you need to make it as absolutely simple as possible.

        If the simple way is too slow, then you sometimes have to try something else less simple. I guess I don't believe it's impossible, but you've made the case that it's very difficult.

        Even the openBSD team that is obsessive with security hasn't found a way to stop them.

        There should be a way to mathematically prove a section of code is secure. If there is, then that would imply an answer exists. Perhaps it's too difficult or the result is even slower than the alternative too-slow implementation.

  • Uh what? (Score:5, Insightful)

    by crweb ( 178418 ) on Thursday January 04, 2018 @02:20PM (#55864059)

    Uh, why is Intel pretending like THEY are the ones deploying patches, Operating Systems, and fixes for their flaw?

    I'm really confused.. Did our machines some how auto update the Intel hardware, or is this Intel taking credit for everyone elses effort to act like they were proactive?

    • They are trying to use damage control to stop the falling stock price.
    • Re:Uh what? (Score:5, Insightful)

      by Megol ( 3135005 ) on Thursday January 04, 2018 @02:37PM (#55864193)

      The Intel propaganda machine is working hard, just look at all sites that try to combine the two kind of exploits into one and imply that all processors not only Intel is vulnerable when in reality one type of exploit with less severity is general while the severe one is Intel specific.

      But I have no doubt that Intel engineers are also working hard in order to patch the problems as quickly as possible and with as little performance impact as possible.

  • From what I understand, OSes can update themselves to protect from this bug, and it is also a very low level bug that cannot be fixed easily. How is this possible?

    Also, if intel can update processor firmware that easily, what prevents malware from doing the same?

    • It isn't possible. Intel is desperate to spin this story. There is no software solution to this flaw, but there are mitigation steps that can be done in software.
      • It isn't possible

        Unless the prediction pipe can be patched in microcode. The prediction pipe uses a program stored within static memory inside the processor to try and predict the results based on cached previous runs in low level memory. The Spectre flaw requires training that pipe to pick the wrong answers in a "known" way and to do so in a very specific manner. I'm pretty sure that if Intel came out with a way to fix this, it would be to make the prediction less predicable to anything outside of that specific core and

        • Meltdown cannot be fixed in microcode or software. There are already programs out there that exploit it. It affects all modern Intel processors. The fixes just mitigate the problem. You are talking about Spectre.
  • of your Mobo manufacturer and/or system builder? I've got a newish Asus board for my i5 7500 but my 4560's board is pretty long in the tooth. I'm not expecting updates at this point...
  • Nice excuse to force all your customers to install a binary blob on their cpus. Should we be surprised when this obfuscates access to their management engine.
  • by Anonymous Coward on Thursday January 04, 2018 @03:32PM (#55864639)

    There are PAID intel shills in this forum and on every other one across the net. Intel payolla outlets Anandtech, Tom's Hardware and Arstechnica have all consulted their Intel contacts and VERY late published FAKE NEWS articles letting Intel off the hook. But not every tech site takes large cheques from Intel...

    If anyone here mentions 'SPECTRE', they are an Intel shill. Spectre is an 'exploit' that has no proven attack vector on AMD Ryzen parts, and the THEORETICAL vectors are simply patched on AMD with no performance hit. On Intel, Spectre CANNOT be patched, however. Either way, spectre is another TRIVIAL and insignificant bug- of which many thousands have already been dealt with on both AMD and Intel.

    It is MELTDOWN that is the only issue that matters. Meltdown describes the NSA backdoor built into every Intel CPU designed to allow user code ring-0 access. This is an ARCHITECTURAL design of intel's CPU's, and cannot be fixed except by flushing and state resetting before EVERY virtual memory/IO operation- a massive slowdown of key functionality.

    AMD's memory architecture is completely different, and does NOT allow this NSA requested attcak vector- not now, not ever.

    Linux has gone crazy cos the exploit is a clear NSA backdoor, which Linux types will not accept. Microsoft, as an OS, is riddled with NSA exploits by Microsoft, so doesn't need a CPU hardware vector. Thus MS can happily patch the hole (on Intel only) at the cost of significant performance degradation on all mutli-core mulit-app use cases (which excludes most current games).

    Intel cannot have a 'fixed' CPU til the end of 2019 at the earliest. Roadmapped Intel parts (like icelake) all have this NSA backdoor.

    There is ZERO AMD issue- indeed AMD Ryzen is the future, just as the original AMD64 was the future when intel paid sites like this one to shill for the broken hopeless netburst design.

Premature optimization is the root of all evil. -- D.E. Knuth

Working...