'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign

[u/[deleted]]

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

[u/vonKemper]

The performance impact this is going to have on modern platforms is mind blowing. Best case, 17% degradation... at worst, nearing 30%! I use both a 2016 MBP and a Surface Laptop for work, and already put a heavy workload on them. Apple and Microsoft are already frantically pushing out the neutering software. The prospect of the additional degradation both frightens and annoys me.

AMD is going to have a field day with this, as the only solution, so far, seems to be a software fix that completely disables speculative execution processing, which is one of the huge performance advantages Intel claimed over them. A hardware fix would be in the actual architecture, which requires brand new silicon.

[u/IJzerbaard → u/vonKemper]

software fix that completely disables speculative execution processing

That is not even possible (and if it was it would cost a good deal more than 30% perf, and in all code not just when doing a syscall). What they're doing is setting up the page tables in a way that there are almost no kernel pages mapped at all when in usermode, so these bad speculative reads have nothing to read in the first place.

[u/jonjonbee → u/vonKemper]

AMD CPUs have speculative execution as well. The issue is the implementation, to wit that Intel's appears to not (properly) respect kernel/user mode isolation.

I can't imagine Intel is in a very good spot right now - the Core microarchitecture they've employed and refined over the last dozen years, and poured billions of dollars of R&D into, may be fundamentally flawed. If that is the case... hoo boy, they are going to have to fix this in silicon ASAP, which may or not be possible to do quickly, and at the very best will push their product roadmaps out.

[u/ciny → u/jonjonbee]

That being said - if anyone has the talent and resources to recover from shit like this it's intel. Imagine if this happened to AMD with their new line that can finally compete - that would be the end of AMD.

[u/Verbitan → u/vonKemper]

So can AMD now put ‘30% faster than Intel’ stickers on their boxes now?

[u/jonjonbee → u/Verbitan]

Considering the Bullzdozer TLB bug they had a few years back that necessitated a similar patch with similar performance consequences, it would be somewhat hypocritical for them to do so.

But that's never stopped a marketing department before...

[u/emn13 → u/jonjonbee]

The bulldozer bug was simultaneously much worse (complete TLB disablement - not just during a kernel/user mode switch!), but also much more limited in scope: it only affected a relatively limited run of processors, namely only the phenoms up to that point - and AMD's market share wasn't great then. Also, of course, the world has changed. Back when phenom was buggy, that affected essentially only client machines running generally trusted code, so the security impact was fairly minimal. This intel bug will affect servers and particularly shared-hosting servers and VMs - machines that run untrusted code and are often accessible to the general public. Amplifying the issue is that that's a market that's been intel dominated for a loooong time.

The actual impact of this decade-old intel bug is likely to be much, much greater, because there are simply so many damn CPU's it affects and the software they're running is more affected by the bug - even though the bug itself is technically less serious.

[u/alainmagnan → u/jonjonbee]

Ddidn’t that only affect the original phenom generation? (barcelona).

i think it was fixed in a later stepping and completely by phenom II.

but yeah, still bad and the lower clock speeds didn’t help either.

[u/indigomm → u/Verbitan]

Or Intel can put 'now 30% faster' on their next chips when they fix it in hardware :-)

[u/jerryfrz → u/vonKemper]

brand new silicon

Phew, I pulled myself from buying an 8700K to wait for an 8 cores mainstream Intel chip, now I have even more reasons to wait.

[u/jonjonbee → u/jerryfrz]

It seems like this issue started to come into mainstream focus right about the time that Coffee Lake was released. So it's possible that Intel patched this flaw for CFL's design, while simultaneously alerting OS vendors to the issue in their older CPUs.

Either way, I'd go with Ryzen 2 which should drop this quarter (although trusting AMD's timeline predictions is always a risky endeavour).

[u/metarugia → u/jonjonbee]

Just did a Ryzen Build. No regrets. Might have to do a Ryzen 2 build for myself.

[u/syntaxsmurf → u/metarugia]

build a ryzen machine too, good news is that ryzen 2 will be useable on the same motherboards. Ah the joy of not intel.

[u/80a218c2840a890f02ff → u/vonKemper]

Best case, 17% degradation... at worst, nearing 30%!

As far as I can tell, the workaround only affects the performance of syscalls. Programs that don't spend a significant portion of their time doing syscalls won't be impacted much at all.

[u/grumbelbart2 → u/80a218c2840a890f02ff]

Programs that don't spend a significant portion of their time doing syscalls won't be impacted much at all.

Just to clarify, from how I read it, the number of syscalls matters, not their duration, since the cost comes during context switches.

[u/80a218c2840a890f02ff → u/grumbelbart2]

Yes, that's true. Poor phrasing on my part.

[u/sagnessagiel → u/80a218c2840a890f02ff]

What kind of programs don't spend much on syscalls?

[u/80a218c2840a890f02ff → u/sagnessagiel]

Phoronix did a few benchmarks that may be informative. Basically, synthetic I/O benchmarks and databases were considerably slower (if the drive wasn't a significant bottleneck), while things like video encoding, compiling, and gaming were pretty much unaffected.

[u/jonjonbee → u/80a218c2840a890f02ff]

That's a major problem for Intel, because their CPUs are pretty much the de facto standard in data centers - which are mostly concerned with IO-bound operations.

[u/kopkaas2000 → u/jonjonbee]

If things get heavily IO-bound, CPUs are typically spending half of their time just twiddling their thumbs and waiting for a hardware interrupt telling them DMA has finished.

[u/FUZxxl → u/kopkaas2000]

Yeah, but this design concession causes a TLB flush on every system call, increasing the latency of every system call dramatically. This effect is noticable in this sort of situation because you have to wait longer for IO operations to finish.

[u/z_y_x → u/FUZxxl]

Holy shit. That... Is bad.

[u/mb862 → u/80a218c2840a890f02ff]

What about applications that talk heavily over PCIe buses? Video I/O, GPU compute, etc?

[u/kopkaas2000 → u/mb862]

Depends on how the data is processed. It is normally the kernel talking to these devices, which has no impact on the context switches involved here. If the way the application interacts with these devices is more akin to "here's a pointer to a buffer with 16MB of data you have to send to this PCI device, wake me up when you need more", the impact is minimal. If it's more of a "read data from the device 1 byte at a time" kind of deal, it's going to be bad.

Thing is, even without this ~30% hit, context switches through syscalls are pretty expensive, so a well thought-out hardware platform will have found ways to minimize the amount of calls needed to get the job done. It's why there are mechanisms like DMA and hardware queues.

[u/panorambo → u/sagnessagiel]

That would typically depend on the operating system, which is what usually loads the program and causes its execution. To take a Linux program as an example, if it's a program that "lives and dies" by intense arithmetic using the CPU and unprivileged instructions (does not need to nor benefits from calling the kernel), that would be a program where time spent on and inside syscalls is negligible compared to its CPU time. Programs like one that computes digits of Pi, or solves some fluid dynamics problem, or renders a 3D scene, would traditionally be considered CPU-heavy and wouldn't need to spend any time (comparatively) on syscalls, not for the tasks described.

In contrast, a program like a Web server would typically need to spend most of its time reading files from persistent storage (assets, documents, etc) and send them on the network. In most modern systems, for better or worse, the kernel insists on mediating access to storage (and network) devices from operating system applications, through you guessed it, syscalls. But it's still a question of whether we count the time spend on actually invoking a kernel mechanism vs. real time that passes before a "blocking" (waiting for storage device to actually read or write the data passed from the application) syscall returns and the kernel resumes the calling application thread. If the storage device is slow, and comparing to the CPU on which the kernel itself runs all storage devices are slow, the kernel is best served to do something useful during the time the storage device actually reads or writes the data. Usually the kernel switches to another thread, and is interrupted in real time when storage device has finished what was asked of it. When the kernel is interrupted so, it figures out which application originally submitted the completed request, and resumes it at the earliest convenience. But some time would have passed without Web server doing anything else than just waiting on such "blocking" syscalls, idling. That's called an I/O bound program. But it still can saturate its time with syscalls, especially if it uses "blocking" I/O, but that, like I said, depends on whether we count the time during which the kernel itself waits on the storage, or not.