Wednesday, January 3rd 2018

AMD Struggles to Be Excluded from Unwarranted Intel VT Flaw Kernel Patches

by
btarunr
 Discuss (142 Comments)
Intel is secretly firefighting a major hardware security vulnerability affecting its entire x86 processor lineup. The hardware-level vulnerability allows unauthorized memory access between two virtual machines (VMs) running on a physical machine, due to Intel's flawed implementation of its hardware-level virtualization instruction sets. OS kernel-level software patches to mitigate this vulnerability, come at huge performance costs that strike at the very economics of choosing Intel processors in large-scale datacenters and cloud-computing providers, over processors from AMD. Ryzen, Opteron, and EPYC processors are inherently immune to this vulnerability, yet the kernel patches seem to impact performance of both AMD and Intel processors.

Close inspection of kernel patches reveal code that forces machines running all x86 processors, Intel or AMD, to be patched, regardless of the fact that AMD processors are immune. Older commits to the Linux kernel git, which should feature the line "if (c->x86_vendor != X86_VENDOR_AMD)" (condition that the processor should be flagged "X86_BUG_CPU_INSECURE" only if it's not an AMD processor), have been replaced with the line "/* Assume for now that ALL x86 CPUs are insecure */" with no further accepted commits in the past 10 days. This shows that AMD's requests are being turned down by Kernel developers. Their intentions are questionable in the wake of proof that AMD processors are immune, given that patched software inflicts performance penalties on both Intel and AMD processors creating a crony "level playing field," even if the latter doesn't warrant a patch. Ideally, AMD should push to be excluded from this patch, and offer to demonstrate the invulnerability of its processors to Intel's mess.
Source: Phoronix Forums

Related News

Add your own comment

142 Comments on AMD Struggles to Be Excluded from Unwarranted Intel VT Flaw Kernel Patches

#76
eidairaman1
The Exiled Airman
R0H1TI wouldn't blame any one person for it, anyway now that the booze's kicked in(?) can anyone analyze the kaiser effect OR to be more precise how AMD would be immune to this?
gruss.cc/files/kaiser.pdf
1 key to this here
www.techpowerup.com/forums/threads/amd-struggles-to-be-excluded-from-unwarranted-intel-vt-flaw-kernel-patches.240187/page-3#post-3777532

By the way, heres another piece

www.techpowerup.com/forums/threads/amd-struggles-to-be-excluded-from-unwarranted-intel-vt-flaw-kernel-patches.240187/#post-3777471

From @btarunr

lkml.org/lkml/2017/12/27/2
Posted on Reply
#77
AnnCore
Staff
So all x64 based CPUs (64 bit) are unaffected? I ask because I read in a few posts "x86-x64" which is confusing me a bit.
Posted on Reply
#82
RCoon
Warning points issued to those incapable of listening to a public request. Last polite public warning.
Posted on Reply
#83
R-T-B
notbI don't see how this would work in a long term. Architecture split? Windows for Intel64 and AMD64? I doubt this is what AMD would want.
Ever heard of a code branch?
Posted on Reply
#84
TheoneandonlyMrK
R-T-BEver heard of a code branch?
I could see intels compiler levelling any field in the future regardless meaning most software will act as they deem suitable anyway.
Posted on Reply
#85
R-T-B
theoneandonlymrkI could see intels compiler levelling any field in the future regardless meaning most software will act as they deem suitable anyway.
GCC is all the linux kernel uses. Ms's compiler is all the Win kernel uses. So irrelevant.
Posted on Reply
#86
jahramika
RejZoRHeh, of course AMD is fighting it off. Why should they get a performance hit for properly doing their CPU's? Of course Intel will do everything to make that happen, so there won't be a massive up to 30% performance gap between their CPU's and AMD's. If they both get penalized, it'll look like nothing happened because the baseline will just be moved 30% lower for both. But if only Intel gets a 30% perfomance hit, that's quite signficant. People should keep an eye on this so the slowdown won't happen for both, but just for Intel. It's their cockup, they should be penalized for it, not AMD. If the issue was reverse, it would be natural to demand or expect the same from AMD. Only making them learn from expensive mistakes will ensure they make shit properly and avoid such awful mistakes...
AMD needs to take Linux to court if they do this.
Posted on Reply
#88
jahramika
AssimilatorOMG IT'S A CONSPIRACY!!!!!!11111111oneoneone

No, it's not. There is no guarantee that AMD CPUs are immune to this flaw, other than a claim from an AMD employee. That points to one of two scenarios:

a) Linux kernel devs have done their own testing and determined that AMD CPUs are, in fact, vulnerable (perhaps not in the same way as Intel's)
b) Linux kernel devs are simply being paranoid/prudent considering the severity of this issue, and will disable PTI for AMD CPUs in a subsequent release once they're certain AMD's chips are not vulnerable

There are literally zero valid reasons for anyone doing Linux kernel development to penalise AMD/prefer Intel; it would destroy their reputation. Similarly, if Intel was leaning on the kernel devs to do this, it would hurt their reputation.



Seriously? Where is your goddamn proof? You're shitposting in this thread like it's going out of style, claiming everyone and their mother are Intel fanboys, yet it's you who's throwing unverified accusations around like confetti.

Adults are talking. Sit down, and be quiet.
Everyone knows that repeater was sent out by Intel
Posted on Reply
#89
Citizenx
notbI don't see how this would work in a long term. Architecture split? Windows for Intel64 and AMD64? I doubt this is what AMD would want.

The 30% figure is a pretty extreme case (a particular load), so it somehow evens out AMD's instruction set disadvantage. It's supposed to be more like 5% in general case - still a lot.

Oh man... you're just running around this forum, posting a link to this story in different threads - some inactive for more than a week. Talking about trolling...
I think 30% performance impact is very reasonable for complex programs and background processes if the kernels now have to prevent branch speculation of certain code from being processed in their typical fashion.
Posted on Reply
#90
EarthDog
jahramikaEveryone knows that repeater was sent out by Intel
Same guy that said AMD wasn't fixing the older games that were borked? :p
Posted on Reply
#91
Patriot
AnnCoreAh. My FX 8350 is an x64 CPU which is just the 64bit version of the x86 instruction set. So basically it's an X86-64 ...
Yes, normally it is referred to as AMD64 as AMD is the owner of the x86-64 instruction set. Though since AMD chips are unaffected by this vulnerability it seems only fair to distance them in the labeling.
Posted on Reply
#92
qubit
Overclocked quantum bit
eidairaman1They did it to keep an anti competitive practice going, theyve been underhanded since super 7 days
I reckon these dirty tactics are possibly the main reason why Intel has remained dominant over AMD since they both started in the late sixties. Can you imagine how much better and cheaper these products would be if both companies had been equal competitors all this time? Of course, the government would then have to ensure that they didn't behave like a cozy little cartel...

For the naysayers on here, there can be many underhanded tactics that either don't make the headlines, or are forgotten over time, but they still happened. They would all add up to put the companies in the positions they're in today, with a much bigger Intel.
Posted on Reply
#93
Gasaraki
So where's the "proof" where this doesn't affect AMD processors. The only "proof" was AMD saying this bug doesn't affect their processors.
Posted on Reply
#94
TheoneandonlyMrK
GasarakiSo where's the "proof" where this doesn't affect AMD processors. The only "proof" was AMD saying this bug doesn't affect their processors.
There's proof on intels side, that's the point, their is none against AMD and both are fairly upfront about issues if pushed in the right way, like the global pr issue way for example as evidenced by both companies extensive errata lists for every sku.
Posted on Reply
#95
Patriot
GasarakiSo where's the "proof" where this doesn't affect AMD processors. The only "proof" was AMD saying this bug doesn't affect their processors.
The part where their ISA does not even support the operation that has the backdoor in it.

Suse also greenlit the patch from AMD...
hardware/comments/7nr7dy/_/ds46kfe
Posted on Reply
#96
notb
qubitI reckon these dirty tactics are possibly the main reason why Intel has remained dominant over AMD since they both started in the late sixties. Can you imagine how much better and cheaper these products would be if both companies had been equal competitors all this time? Of course, the government would then have to ensure that they didn't behave like a cozy little cartel...
Are you 100% sure that you know how AMD got into 8080 and x86? :-)
Moreover, these companies used to be very close competitors for years. It ended in mid 2000s, but not because of any Intel's wrongdoing or a great conspiracy. AMD simply made some bad business decisions.
Posted on Reply
#97
EarthDog
There was the Intel compiler thing which blew up for a minute a few years ago that hamstrung AMD processors...

The reality is, both have done shady things at times and both are sinners. If one can't agree to that, well, can't really help that. ;)
Posted on Reply
#98
64K
notbAre you 100% sure that you know how AMD got into 8080 and x86? :)
Moreover, these companies used to be very close competitors for years. It ended in mid 2000s, but not because of any Intel's wrongdoing or a great conspiracy. AMD simply made some bad business decisions.
It was a combination of bad business decisions on AMD's part like overpaying for ATI and when Intel rolled out their Core 2 architecture and AMD was behind in CPU performance until Ryzen. This forced AMD to sell their chips cheap which just dug them deeper and deeper into debt.
Posted on Reply
#99
efikkan
btarunrThe hardware-level vulnerability allows unauthorized memory access between two virtual machines (VMs) running on a physical machine…
To emphasize, the exploit is related to virtual memory, not virtualization, where kernel memory can be leaked to user-space. Virtualization will be one of several "victims" of such exploits, but virtualization is not the bug here.
btarunr…Ryzen, Opteron, and EPYC processors are inherently immune to this vulnerability, yet the kernel patches seem to impact performance of both AMD and Intel processors.
Are they? Have you looked at the commit?
* On Intel CPUs, if a SYSCALL instruction is at the highest canonical
* address, then that syscall will enter the kernel with a
* non-canonical return address, and SYSRET will explode dangerously.
* We avoid this particular problem by preventing anything executable
* from being mapped at the maximum canonical address.
* On AMD CPUs in the Ryzen family, there's a nasty bug in which the
* CPUs malfunction if they execute code from the highest canonical page.
* They'll speculate right off the end of the canonical space, and
* bad things happen. This is worked around in the same way as the
* Intel problem.
*
* With page table isolation enabled, we map the LDT in ... [stay tuned]
I think your article needs to be updated.
AssimilatorHere's an interesting possibility as to why the PTI patch is applied to AMD as well as Intel: a partially redacted comment in the Linux kernel sources referring to a Ryzen bug that has to be worked around.

git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/include/asm/processor.h?id=5aa90a84589282b87666f92b6c3c917c8080a9bf#n864
I think about two people in the thread referred to the commit, and quite possibly you were the only one to even read it, yet we have two long threads of people bashing Intel over something people don't even understand.

It should be obvious to anyone who spend five minutes checking the source that AMD have a bad bug here as well. The Intel bug is a design fault, simply because the engineers didn't take something into account. When you find a new type of defect in a design, it's not unlikely that competing designs might include similar mistakes, so it doesn't surprise me that AMD have a related bug of their own. Investigating such defects usually spawns new useful approaches to find more bugs.

Do you remember "Heartbleed"? It caused people to go look for similar problems and resulted in finding dozens of other bugs, some even worse.
theoneandonlymrkA question worth asking:) what of qualcom too and the arm derivatives are they to be penalised for intels shoddy workmanship.
Check the source, and you'll see it's specific to the x86 kernel.
Posted on Reply
#100
TheoneandonlyMrK
efikkanTo emphasize, the exploit is related to virtual memory, not virtualization, where kernel memory can be leaked to user-space. Virtualization will be one of several "victims" of such exploits, but virtualization is not the bug here.


Are they? Have you looked at the commit?



I think your article needs to be updated.


I think about two people in the thread referred to the commit, and quite possibly you were the only one to even read it, yet we have two long threads of people bashing Intel over something people don't even understand.

It should be obvious to anyone who spend five minutes checking the source that AMD have a bad bug here as well. The Intel bug is a design fault, simply because the engineers didn't take something into account. When you find a new type of defect in a design, it's not unlikely that competing designs might include similar mistakes, so it doesn't surprise me that AMD have a related bug of their own. Investigating such defects usually spawns new useful approaches to find more bugs.

Do you remember "Heartbleed"? It caused people to go look for similar problems and resulted in finding dozens of other bugs, some even worse.


Check the source, and you'll see it's specific to the x86 kernel.
Sweet so my home pc wont get the dreaded patch then is that what your saying , because the gist i have now is that

A. It affects only virtual servers indirectly if affected and only really data centers.

But

B. Everyone is getting a patch that might slow down crysis again causing chaos.

If both are true im still concerned, if just A then cheers mate im done here :)
Posted on Reply
Add your own comment
Nov 21st, 2024 04:46 EST change timezone

Latest GPU Drivers

New Forum Posts

Popular Reviews

Controversial News Posts