Huge Intel processor design flaw

‘Kernel memory leaking’ Intel processor design flaw forces Linux, Windows redesign.

"Programmers are scrambling to overhaul the open-source Linux kernel’s virtual memory system. Meanwhile, Microsoft is expected to publicly introduce the necessary changes to its Windows operating system in an upcoming Patch Tuesday: these changes were seeded to beta testers running fast-ring Windows Insider builds in November and December.

Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we’re looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features – such as PCID – to reduce the performance hit. Your mileage may vary."

Wow, this looks awful. Hopefully this wont affect home PCs much. RIP security companies :smiley:

In other words - “Don’t sit on your Sandy Bridge and Devil’s Canyon chips. Buy new processors!”

Or older ones XD

milkywayman said in Huge Intel processor design flaw:

Or older ones XD

It impacts all Intel CPUs for the past 10+ years :disappointed_face:

What is crazy is the scale of the security flaw, how severe it is, AND the fact that the software workaround (that is getting patched in Linux kernel and in Windows), causes a huge performance impact. Gaming will be slightly less impacted, but load times will probably increase. Graphics rendering isn’t going to cause as many syscalls, so it should have less impact there. I imagine physics calculations will be impacted though.

This is just nuts. If this was AMD, they would go under immediately.

2 Likes

buttstallion I think some of the performance impact is overblown by the tech journalists. It isn’t going to be a 30% drop across the board. A broad subset of activities (system calls) are going to have performance impact.

We also don’t know everything about the issue yet, since it is embargoed. While I expect some performance impact, and probably a small FPS drop in games, I think we are seeing another case of tech journalists reporting shit.

3 Likes

teh_g Tests showed less than 1% fps drop in games or not at all. Servers, stream machines, maybe low end cpus may suffer more because of smaller and slower memory, but I don’t think it is going to show major drops with home PCs. But we’ll see when a final patch is out and all the tech pros are going to test it :smiley:

buttstallion said in Huge Intel processor design flaw:

teh_g Tests showed less than 1% fps drop in games or not at all. Servers, stream machines, maybe low end cpus may suffer more because of smaller and slower memory, but I don’t think it is going to show major drops with home PCs. But we’ll see when a final patch is out and all the tech pros are going to test it :smiley:

Yup, the tech journalists are sensationalizing it. While there is a HUGE issue, and it will cause a performance hit, it is really people doing more business oriented tasks. Running VMs, web servers, etc.

Ars did a pretty good article on the flaw as it is known so far:

But workloads that call into the kernel a ton will see much greater performance drop off. In a benchmark, a program that does virtually nothing other than call into the kernel saw its performance drop by about 50 percent; in other words, each call into the kernel took twice as long with the patch than it did without. Benchmarks that use Linux’s loopback networking also see a big hit, such as 17 percent in this Postgres benchmark. Real database workloads using real networking should see lower impact, because with real networks, the overhead of calling into the kernel tends to be dominated by the overhead of using the actual network.

1 Like

AMD 4 lyfe

2 Likes

shiftysatchmo I waited for this comment all day, thank you, now I can go to bed :smiley:

4 Likes

buttstallion I aim to please :smiling_face_with_open_mouth_closed_eyes:

AMD joined the party ShiftySatchmo :smiley:

Windows fix is out, installing now (KB4056892)

0_1515068986119_ApplicationFrameHost_2018-01-04_13-29-23.png

buttstallion so it sounds like there is a patch for the Intel specific one, but then there is another one that affects all processors anyway? Meh, at least that fix is get a sweet new CPU someday and not a performance hit :wink:

1 Like

shiftysatchmo said in Huge Intel processor design flaw:

buttstallion so it sounds like there is a patch for the Intel specific one, but then there is another one that affects all processors anyway? Meh, at least that fix is get a sweet new CPU someday and not a performance hit :wink:

The one that impacts all processors is a little less concerning. It basically lets user applications look at user level memory, something that is trivial enough to do if you are on a system anyway. Stealing from here: https://www.reddit.com/r/Amd/comments/7o2i91/technical_analysis_of_spectre_meltdown/

So here’s a brief summary of what, exactly, the three security vulnerabilities are:

Spectre v1: “Bounds-Check Bypass”.
The CPU is tricked into speculatively loading data from outside the bounds of an array which is bounds-checked, ie. at a virtual address chosen by the attacker. The bounds-check means that the data is never actually loaded into registers visible to the program. However, the data can be passed through several subsequent speculative instructions, including loads from dependent addresses, so cache-timing effects can be used as a side-channel to exfiltrate the data. The data, however, must legitimately be readable by the same process.
This vulnerability is difficult to exploit usefully. In most cases where it’s possible to inject code to perform the attack, you can simply inject code to read the data directly, instead. Proofs of concept use JIT compilers (eBPF and Javascript) to implement the attack.

Vulnerable CPUs: Potentially anything with branch-prediction and a sufficiently deep pipeline. This is not an x86-specific exploit. The newer the CPU, the more likely it is vulnerable. In particular on the AMD side, Piledriver, Excavator and Ryzen are confirmed to be vulnerable - but this is nothing special. Potentially even K6 and Pentium Pro are vulnerable, but early Atoms and the Pentium-MMX are not.

Software Mitigation: Bounds-checked array accesses in untrusted JIT-compiled code should be associated with a memory barrier, so that the array access itself is not speculatively executed with respect to the bounds check. This has a small performance impact on JIT-compiled code.

Spectre v2: “Branch Target Injection”.
The CPU is tricked into mispredicting an indirect branch (commonly used to implement ‘virtual’ functions in C++, or jump tables in the kernel) to speculatively execute program code chosen by the attacker. This code can directly read data visible to the process executing the branch, then perform a dependent read to permit exfiltration over the same cache-timing side-channel as Spectre v1. The exfiltrated data may reside in a privileged address space, if the targeted branch happens to be in privileged code.
The architectural results of this speculative execution are cancelled when the true branch target becomes known to the CPU, and true execution resumes from the correct address; it is therefore difficult to detect that the attack has taken place. The branch-target injection can be performed by another process or thread executing on the same CPU core as the target process, since the Branch Target Buffer (BTB) is shared between them.
This vulnerability is potentially useful to a local attacker. It can obtain secret data from a privileged address space, such as cryptographic tokens or the location of a viable Rowhammer target.

Vulnerable CPUs: This attack requires poisoning the CPU’s BTB. This is easy on at least Intel Haswell CPUs (and probably some other Intel CPUs), because BTB entries are aliased in a very predictable way. Some recent ARM Cortex-A series CPU cores are reportedly vulnerable too, for the same reason. It is much more difficult on all AMD CPUs, because BTB entries are not aliased - the attacker must know (and be able to execute arbitrary code at) the exact address of the targeted branch instruction.

Software Mitigation: Indirect branches that can be mispredicted should be removed from privileged code. This is apparently being done in the Linux kernel on vulnerable CPUs. It’s not yet clear what the performance impact is, but it should be small.

Meltdown: “Rogue Data Cache Load”.
The CPU is tricked into speculatively loading data which is in the L1 D-cache, but which is marked as unreadable in the page tables. Such data is typically accessible to privileged code running in the same process (eg. upon executing a syscall), and is left mapped but unreadable as a performance optimisation. As with the Spectre attacks, the attack relies on passing the data through further speculatively-executed instructions to perform side-channel exfiltration, and normal execution resumes with no obvious side-effects once the speculation window closes.
This vulnerability is potentially useful to a local attacker. It can obtain secret data from a privileged address space, such as cryptographic tokens or the location of a viable Rowhammer target.

Vulnerable CPUs: This attack requires that the CPU fails to promptly check security flags while performing L1 D-cache loads for a speculatively-executed instruction. Various Intel CPUs (everything from Nehalem and Silvermont onwards, including Coffee Lake and Xeon Phi) are vulnerable. AMD CPUs are not vulnerable.

Software Mitigation: Operating Systems can fully unmap privileged address spaces, instead of merely marking them as inaccessible, when kernel-mode code is not being executed. This means that the rogue load in the attack code will not find the target data. This carries a significant overhead for each syscall, because switching to the alternative page tables and back requires flushing the TLBs twice. Some syscall-heavy workloads could see 30% or worse slowdown. Workloads which make few syscalls, or which are bottlenecked by other components, will see little or no degradation.

2 Likes

The funny part in this story is how developers mange to blame CPU /Hardware manufacturers only and survive :slight_smile: … but you will notice that both hardware and OS have built in backdoor :slight_smile: … I would not be so concerned about performance at least that will not be issue here … But if someone mange to emulate and implement USB access to PC over the network / internet then we are in world of hell … coz very soon you will have something far worse than Stuxnet worm … for example any of mentioned vulnerabilities mentioned as “potentially useful to a local attackerwill become useful to a remote attacker!! and don’t even think that this is Intel problem only!! It is Hardware (Intel / ARM /AMD / XYZ company) and OS / software developer problem … which is becoming more and more obvious (thanks to more and more Internet connected devices and Internet access functionality (from PC up to stupid fridge or washing machine) and also so called OS / application as service approach) Because both manufacturers and developers think that it is a cool if you can be plugged 24/7/365 on Internet … That was a vary bad idea from start and nowadays you can’t even control device or app connection status or power-state or what any of those thingies doing in background while you are not using damn thing …

1 Like

Total coincidence :smiley:

2 Likes