• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.
  • The forums have been upgraded with support for dark mode. By default it will follow the setting on your system/browser. You may override it by scrolling to the end of the page and clicking the gears icon.

Major Intel CPU Hardware Vulnerability Found

Status
Not open for further replies.
EPYC news for AMD server offerings! I wouldn't worry too much about your latest gaming PC purchase though.

This. Totally blows for providers that have invested billions in cloud infra. but its going to be great if you buy AMD servers at work! Now your IT dept will have more budget! Always a silver lining :D
 
Meanwhile I'm so happy I haven't bought the 5th generation Sandy Bridge CPU aka Coffee Lake.
 
Very interesting reading. The "rowhammer" type attacks that manipulate protected memory addresses by massively accessing same adjacent physical row(s) in DRAM to cause eventually random bit errors on the target address containing access right controls. This doesn't happen normally, because you are not accessing all the time same memory addresses as fast as you possibly could. Recent years have provided mitigations which make it way more difficult to locate potential target addresses too.

https://www.tugraz.at/en/tu-graz/se...rticle/wenn-rowhammer-nur-noch-einmal-klopft/
 
Very interesting reading. The "rowhammer" type attacks that manipulate protected memory addresses by massively accessing same adjacent physical row(s) in DRAM to cause eventually random bit errors on the target address containing access right controls. This doesn't happen normally, because you are not accessing all the time same memory addresses as fast as you possibly could. Recent years have provided mitigations which make it way more difficult to locate potential target addresses too.

https://www.tugraz.at/en/tu-graz/se...rticle/wenn-rowhammer-nur-noch-einmal-klopft/

Yeah this is cool stuff, I think you could even trigger "corruption" on SSDs doing s similar technique but I dont have the article handy.
 
Yeah this is cool stuff, I think you could even trigger "corruption" on SSDs doing s similar technique but I dont have the article handy.
"We use our knowledge of existing reliability mechanisms in SSDs (including ECC), to show that the attack primitive an attacker can obtain from MLC NAND flash weaknesses is a coarse granularity corruption: unlike in rowhammer, where the attacker can flip a single bit, in the case of this attack the attacker can only corrupt one block of data,” the researchers wrote. “We then show that this weaker attack primitive (when compared to flipping individual bits, which provides a higher level of control to the attacker) is nevertheless sufficient to mount a local privilege escalation attack."

https://threatpost.com/rowhammer-attacks-come-to-mlc-nand-flash-memory/127504/
 
I have made edits to my post, re-read if you have read my previous post.

This won't affect consumers or casual labbers with hyper-v enabled on there home machines. I've been following this and this is seems exclusive to big virtual farms not bare-metal installs.

no 3dmark scores going down im afraid. We also dont know what "35%" performance drop means either since this info is just from linux users and not windows fleets.
Not really, this is specific to virtualization. So unless you own a AWS compute farm your probably not going to shut off windows ervices in task manager any time soon to boost your FPS in fallout 4.
Incorrect. The key word is "virtual" not virtualization, as in "virtual memory" which is used just about every where. If you launch notepad, you have used virtual memory. If you use Firefox, you have used virtual memory. The idea is that every single program you have running on your computer is given its own memory space that's completely separate from other programs running on the same system. It's how two programs can write to 0x000012DF, the exact same memory address, and not have the memory clobbered because the OS translates that virtual address space to something else.

Bad news: the software mitigation is expensive
The primary reason for the old Linux behavior of mapping kernel memory in the same page tables as user memory is so that when the user’s code triggers a system call, fault, or an interrupt fires, it is not necessary to change the virtual memory layout of the running process.

Since it is unnecessary to change the virtual memory layout, it is further unnecessary to flush highly performance-sensitive CPU caches that are dependant on that layout, primarily the Translation Lookaside Buffer.

With the page table splitting patches merged, it becomes necessary for the kernel to flush these caches every time the kernel begins executing, and every time user code resumes executing. For some workloads, the effective total loss of the TLB lead around every system call leads to highly visible slowdowns.

It is understood the bug is present in modern Intel processors produced in the past decade. It allows normal user programs – from database applications to JavaScript in web browsers – to discern in some way the contents of protected kernel memory.

The fix is to separate the kernel's memory completely from user processes using what's called Kernel Page Table Isolation, or KPTI. At one point, Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka FUCKWIT, was mulled by the Linux kernel team, giving you an idea of how annoying this has been for the developers.

Whenever a running program needs to do anything useful – such as to write to a file or open a network connection – it has to temporarily hand control of the processor to the kernel to carry out the job. To make the transition from user mode to kernel mode and back to user mode as fast and efficient as possible, the kernel is present in all processes' virtual memory address spaces, although it is invisible to these programs. When the kernel is needed, the program makes a system call, the processor switches to kernel mode and enters the kernel. When it is done, the CPU is told to switch back to user mode, and reenter the process. While in user mode, the kernel's code and data remains out of sight but present in the process's page tables.

Think of the kernel as God sitting on a cloud, looking down on Earth. It's there, and no one on Earth can see it, yet they can pray to it.

These KPTI patches move the kernel into a completely separate address space, so it's not just invisible to a running process, it's not even there at all. Really, this shouldn't be needed but clearly there is a flaw in Intel's silicon that allows kernel access protection to be bypassed in some way.

The downside to this separation is that it is relatively expensive, time wise, to keep switching between two separate address spaces for every system call and for every interrupt from the hardware. This adds an extra overhead, and slows down the computer.
This has the potential to effect even your common every day desktop computer especially if you are multitasking heavily since this patch pretty much forces far more processor context switches which is very processor intensive to do, it's computationally expensive.
 
Last edited:
I have made edits to my post, re-read if you have read my previous post.



Incorrect. The key word is "virtual" not virtualization, as in "virtual memory" which is used just about every where. If you launch notepad, you have used virtual memory. If you use Firefox, you have used virtual memory. The idea is that every single program you have running on your computer is given its own memory space that's completely separate from other programs running on the same system. It's how two programs can write to 0x000012DF, the exact same memory address, and not have the memory clobbered because the OS translates that virtual address space to something else.




This has the potential to effect even your common every day desktop computer especially if you are multitasking heavily since this patch pretty much forces far more processor context switches which is very processor intensive to do, it's computationally expensive.

Totally missed that! Your right, this will affect consumer end machines then. It also really puts into perspective why AWS and cloud platforms will take a massive performance penalty given that those clusters utilize so much addressing for virtual processes. Let’s hope the fix isn’t too expensive. We as of yet have not had to deal with real world results.

Fingers crossed until the embargo lifts!
 
I imagine it will depend upon how many processes are running on the system, the more processes you have running the more context switches from user to kernel and then back again you have thus incurring a higher overhead. Your typical desktop system will be impacted by this, there is no doubt in my mind that they will be. Obviously not to the extent that massive cloud computing clusters will be impacted but desktops will be impacted just not as severely.

It will be interesting to see the before and after benchmarks to see how much of an impact this security patch has on everyday systems. It would be hilarious if all the recent improvements Intel has made over the last couple of years were suddenly eaten up by this required kernel patch.
 
I imagine it will depend upon how many processes are running on the system, the more processes you have running the more context switches from user to kernel and then back again you have thus incurring a higher overhead. Your typical desktop system will be impacted by this, there is no doubt in my mind that they will be. Obviously not to the extent that massive cloud computing clusters will be impacted but desktops will be impacted just not as severely.

It will be interesting to see the before and after benchmarks to see how much of an impact this security patch has on everyday systems.

Hm I think it would need to be purely synthetic it might be easy for joe smith to control his start up programs but more difficult to control the open thread handles on the system.

Still maybe that still would be a good test, I mean for a lot of us the 3DMark score is what would matter anyway.
 
Is it the speculative execution plus translation lookaside buffer (TLB) causing unprivileged code to access private memory addresses the issue I understood it as?
 
I also imagine that those of us with older (and slower) Intel processors will be impacted more so than those who have newer (and faster) Intel processors since the overhead won't be quite so severe.
 
Is it the speculative execution plus translation lookaside buffer (TLB) causing unprivileged code to access private memory addresses the issue I understood it as?

I'm not sure to be honest with you, I have to read a bit more into it. I was reading it as I was clocking out. I just got home.

I also imagine that those of us with older (and slower) Intel processors will be impacted more so than those who have newer (and faster) Intel processors since the overhead won't be quite so severe.

Possibly, im not sure of the math behind it. I would imagine newer high core count CPUs would suffer more only because the resource exhaustion points are higher. However, im not sure if that slow down would be linear, IE a core 2 duo suffers 30% but a 12 thread coffee lake also suffers 30% because utilization might be relative given a systems resources. What do you think?
 
Not really, this is specific to virtualization. So unless you own a AWS compute farm your probably not going to shut off windows ervices in task manager any time soon to boost your FPS in fallout 4.
Indeed.

Not good for Intel in the data center space. Im wondering if huge companies like AWS(ec2 etc) or or MS(Azure) can then sue. De0ending on how this supppsed 35% affects what loads... that could be a big hit in the short term in overhead/thresholds...load balancing to maintain performance and having to open up more cpu to each vm whose loads are affected...
 
Yep, just talked to the University admin of HPC, the entire cluster will be taken offline for this update at the end of this week. Considering all the runs already piled up it is very bad for most researchers.

FYI it uses Haswell-EP, a 20c40t varient CPU
 
Indeed.

Not good for Intel in the data center space. Im wondering if huge companies like AWS(ec2 etc) or or MS(Azure) can then sue. De0ending on how this supppsed 35% affects what loads... that could be a big hit in the short term in overhead/thresholds...load balancing to maintain performance and having to open up more cpu to each vm whose loads are affected...

There may be ways around it and performance may get better, as I understand it there are two theoretical ways with dealing with the problem.

1: You can simply not patch or disable the work around in the kernel which means you would have to protect yourself higher up the chain.

2: it doesnt seem to be "my PC is upto 30% slower" its that the transactions with virtual memory maybe upto 30% slower. Which might be mitigated by smart coding and requiring less calls to protected kernel space.
 
Which might be mitigated by smart coding and requiring less calls to protected kernel space.
Context switches from user to kernel and back again have always been a performance hit since the beginning of it all, this issue just adds 30% more to that performance hit. Reducing the need to go to the kernel to do something can and will put a bandaid on it and reduce the context switch overhead but this of course will require more intelligent programming on the behalf of the developers. Unfortunately not all developers are made equal. Some can write clean code, others... not so much.
 
There may be ways around it and performance may get better, as I understand it there are two theoretical ways with dealing with the problem.

1: You can simply not patch or disable the work around in the kernel which means you would have to protect yourself higher up the chain.

2: it doesnt seem to be "my PC is upto 30% slower" its that the transactions with virtual memory maybe upto 30% slower. Which might be mitigated by smart coding and requiring less calls to protected kernel space.

I think we are going to see a lot of number one being done.
 
There may be ways around it and performance may get better, as I understand it there are two theoretical ways with dealing with the problem.

1: You can simply not patch or disable the work around in the kernel which means you would have to protect yourself higher up the chain.

2: it doesnt seem to be "my PC is upto 30% slower" its that the transactions with virtual memory maybe upto 30% slower. Which might be mitigated by smart coding and requiring less calls to protected kernel space.
it will be interesting to see how its dealt with... i need to call my peeps still at AWS... :)
 
Intel FANBOY HERE and the matter doesn't touch/bother me at all
 
it will be interesting to see how its dealt with... i need to call my peeps still at AWS... :)

Same! This is super cool shit its what I live for, I'm anxious for the embargo to lift so we can see what had to happen and how its being dealt with, all we have to go on is back tracking upstream kernel commits for *nix which paints the picture for certain, but I want to know what color its going to be. At this point more changes for better or for worse can be committed, however I do admit if they are being approved upstream we may well be seeing what will hit the general public, atleast in linux land.
 
You say that now @Knoxx29 until the kernel patch drops for Linux/Windows. Wonder when this shows for next patch Tuesday?
 
You say that now @Knoxx29 until the kernel patch drops for Linux/Windows. Wonder when this shows for next patch Tuesday?

If my CPU runs DOOM and FIFA 2018 i am fineo_O

Note: Life is just one and for sure this little thing is not going to make me crazy or not let sleep at night, there are more important things in life to worry about.
 
Last edited:
I was never worried about this latest hardware errata. Already lost TSX support for my 4790K through micocode update. What else could possibly cripple it?
 
Status
Not open for further replies.
Back
Top