This site may earn affiliate commissions from the links on this page. Terms of use.

Intel CPU Wafers

Spectre and Meltdown are two of the most serious security flaws we've seen in years. While it'southward not clear how often we'll run into either exploited in the wild, they're unsafe because they target the fundamental function of the afflicted fries themselves rather than relying on whatsoever software flaw. Meltdown can be addressed by a patch, while Spectre's attack methods are still being analyzed. Building CPUs that aren't vulnerable to these attacks under whatever circumstances may not be possible, and mitigating some threat vectors may crave fundamentally new blueprint approaches.

Over at ZDNet, Jason Perlow argues these latest failures are proof the x86 standard itself needs to be destroyed, root and branch. He compares the flaws in x86 with a genetic disorder and writes:

Essentially, the just cure — at least today — is for the organism to die and for another one to have its place. The bloodline has to die out entirely.

The organism with the genetic disease, in this case, is Intel's x86 chip compages, which is the predominant systems compages in personal computers, datacenter servers, and embedded systems.

Perlow goes on to hash out how software companies like Microsoft have pivoted towards the cloud (which doesn't require x86 compatibility for backend services) and ultimately calls for the advent of new hardware evolution based on open-source hardware standards like RISC-V, which is completely open source. After discussing how OpenSPARC had promise, but withered on the vine following Sunday'south acquisition by Oracle, he declares: "Nosotros need to develop a modern equivalent of an OpenSPARC that any processor foundry can build upon without licensing of IP, in order to drive down the costs of building microprocessors at immense calibration for the deject, for mobile and the IoT."

It's an interesting argument but, I'd argue, not an accurate 1.

x86 Isn't Going Anywhere

While it's true the rise of ARM has expanded the overall consumer CPU ecosystem, thus far, the two CPU families live in dissimilar worlds. The ARM server market place is, for the moment, nearly nonexistent. And while it'due south theoretically possible for x86 to be pushed out past a superior CPU compages, there are some pregnant barriers to that actually happening.

Among them: Emulated x86 performance on a device like the Windows ten Snapdragon 835 will never match native code, emulation support isn't extended across the unabridged legacy stack of Win32 applications, there's a huge corporeality of x86 legacy code in-market, and precious little interest from anyone in a wholesale interruption with the past, particularly when there's no evidence such a break would pb to meaningful improvements in CPU security (more on this after).

Intel made 4 attempts to design non-x86 architectures that were either explicitly intended to supersede it or, at the least, could have replaced it if x86 had run out of steam and these other CPUs met their design goals: iAPX 432 (1981), i960 (1984), i860 (1989), and Itanium (2001). Itanium was specially discussed every bit a long-term replacement for x86 in the stitch to its own launch. Back then, before AMD created x86-64, Intel was resolute that 32-bit was the terminate of the line for its x86 chips, with Itanium taking over all 64-bit workloads in the future. Didn't happen that mode, just it wasn't for a lack of trying on Santa Clara'due south part.

PowerPerfTrade

CPU operation is dictated past design decisions much more than than ISA.

Furthermore, ISA comparisons performed several years agone showed equally far as efficiency is concerned, CPU architectural decisions have much more of an bear upon than ISA. That'due south why the Cortex-A15 uses significantly more ability than the sometime Cortex-A9 in the graph above, and it's why the Core i7′ s ability consumption is and so much higher than Cantlet (Bonnell microarchitecture) or AMD's Bobcat. Getting rid of x86 might still exist worth information technology if the x86 CPU families were specially or uniquely broken, just they aren't — which brings us to our next signal:

No One is Getting Rid of Out-of-Order Execution

The flaws that make Intel CPUs particularly susceptible to Meltdown accept to do with how Intel implements speculative execution retentiveness accesses. The flaws that let Spectre to part aren't item to Intel or fifty-fifty to x86 at all. They impact CPUs from ARM, AMD, and Intel alike, including Apple's custom CPU cores that are based on ARM merely offer much college per-core performance than any other ARM SoC available in the consumer market.

Without diving into also much detail, these attack methods work past exploiting certain CPU intrinsic behaviors that are closely linked to many of the performance-enhancing techniques CPU developers have relied on for decades. The reason we rely on them is because alternative solutions don't work besides. That doesn't mean bit architects won't find meliorate solutions, but CPU security is always going to be an evolving game. The assail vectors being used in Spectre and Meltdown hadn't been thought of when OoOE techniques were being developed and refined. And no one is going to build chips that stop using them when various OoOE techniques are more often than not responsible for the level of CPU performance we currently enjoy and the electric current patches don't (yet) seem to hit consumer desktop performance.

IP Licenses Aren't a Major Cost Driver

A 2022 semiconductor cost assay from Adapteva found IP licensing fees and royalty rates aren't a large driver of total chip design or production costs. Royalty rates can admittedly vary, but they tend to do and then depending on the complexity and performance of the chip you're trying to build.

Credit: Adapteva

The $0-$10M range for royalty fees isn't small, merely it's dwarfed by hardware and software development fees, which can run into the hundreds of millions of dollars. This is not to say making cores cheaper wouldn't help some would-be developers, only information technology's not a magic fee to unlocking dramatically better cost structures. Fabs like TSMC, GlobalFoundries, and UMC all earn money on older process nodes for chips that don't demand the latest and greatest technology, with relatively low licensing costs.

An Open Source CPU Doesn't Solve These Problems

Spectre and Meltdown are examples of what happens when researchers accept an thought — attacking specific areas of retentiveness to extract the data they hold — and apply them in new and interesting ways. To the all-time of our knowledge, the difference in Meltdown exposure between AMD, Apple, ARM, and Intel has nothing to exercise with any specific effort to build more secure processors. Everyone is exposed to Spectre regardless.

Making a scrap pattern open source does nada to preclude future researchers from finding assail methods that work against CPUs that weren't designed to mitigate them because the attack methods didn't exist yet. It doesn't automatically provide a means of securing futurity CPUs or even get in more than likely that a scenario for closing the vulnerability without hurting performance volition exist found. The number of people in the earth who are qualified to contribute reasonably practiced code to an open source software project is rather higher than the number of people who are qualified to piece of work equally avant-garde CPU designers in partnership with cutting-edge foundries.

Decision

The idea x86 represents some kind of millstone around Intel and AMD's commonage cervix rests on an intrinsic assumption that x86 is erstwhile and existence erstwhile equals bad. But let's be honest here: While a modernistic Core i7 or Ryzen 7 1800X can still execute legacy 32-bit code that ran on an 80386, at that place'due south no 80386 hardware nonetheless knocking around inside your desktop CPU. Even in scenarios where the CPU is running the aforementioned lawmaking, it isn't running that code through the same circuits. Modern CPUs aren't made with the aforementioned materials or processes that we used thirty years ago, they aren't built to the same specifications, they don't rely on the same techniques to maximize functioning, and referring to the age of x86 is a way of painting an architecture poorly for rhetorical purposes, not an accurate way to capture the benefits and weaknesses of various CPU designs.

There may well come a twenty-four hours when we replace x86 with something better. But it isn't going to happen just considering x86 fries, like not-x86 fries, are impacted by design decisions common to high performance processors from every vendor. Open source hardware is a nifty idea and I welcome the appearance of RISC-V, but there's no proof an OSS chip would've been less susceptible to this blazon of attack. x86, ARM, and the airtight-source CPU model aren't going anywhere and these security breaches offering no compelling reasons why they should.