* pleased face * Major headache for many people who use their pcs for things other than gaming though. I would be interested to see the effects the patch will have on comparative performance between Intel and AMD over the past few, well many, years. Whether anybody can be bothered to look at it is another matter
Someone explained to me that may not be the case with Windows as Linux already ran drivers in user space whereas with Windows the Kernel User space switching of graphics drivers is less clear, IDK how accurate that is or how much difference there is between the way Linux and Windows deal with drivers.
Fair point. If it does make framerates drop in games it could shake up the industry quite a bit. I may have to test some stuff downstairs or at home. Tempted to poke matt and ask him to do this. So far it seems only things like handbrake will be changed but with AMD finally going blow for blow with intel in productivity stuff and even beating them this may be what they need.
https://patchwork.kernel.org/patch/10133447/ AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault. Disable page table isolation by default on AMD processors by not setting the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI is set. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> ---
Oops sorry mate didn't see it. I don't know why, but B-T articles are kinda small, even on my gargantuan monitor lol. They are centred and quite small.
Someone explain to a halfwit like myself, why are OS publishers picking up the mess Intel have in their design? Is there no other way than patching the problem at the OS level? Edit: small screen missing of above post. Well i did say i was a halfwit
Intel cba if i had to guess. Most people will give the OSes flack instead of Intel so they don't "need" to do anything. Technical wise not a clue.
From my limited understanding it's because it's a flaw in the microarchitecture of the CPU and isn't something that can be prevented from happening via a change to the software (microcode) running on the CPU, it's a physical design flaw. Like i said my understanding is limited but from what i can tell it's to do with the way Intel designed their translation lookaside buffer, a type of buffer that's used by programs to speed up access to information in memory, the memory addresses of the information in the TLB was meant to be isolated and i believe some enterprising soul has discovered they can use what is in essence a copy of a table of memory locations. I could have that totally wrong though so don't go quoting me.
Based on my limited understanding my guess is by the time the instruction has reached the CPU or the part in the process where microcode would have an effect it's too late. Microcode is a sign on the bridge saying 'Bridge out' OS-level patch is a sign saying 'bridge out, follow diversion' a mile or so before the bridge.
Not knowing what I'm talking about IDK how accurate the article i just read is but from what little i do understand it seems to do a good job of explaining what maybe going on with this bug.
Ah ha thanks Red, I guess that makes sense. Following that logic the only other way of tackling it would be to make sure the problem isn't there in the design phase and the horse bolted on that one, what, about 10 years ago? Edit: The next thing to know is who knew what when and whether any shares were sold... You know, coincidentally and all that.
Some windows testing here (including games) i7 3960x 1080Ti https://translate.google.com/transl...e-im-prozessor-design.html&edit-text=&act=url
Any chance W7 will get a patch or will that somehow be impossible and it can only be done for W10...?
It wouldn't surprise me if the answer to that one is no - It's another way for Microsoft to force users to migrate over to 10 after all.