Wednesday, January 3rd 2018

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

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
Add your own comment

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

#101
R0H1T
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 wasn't the mid noughties, AMD was competitive till phenom II so right till 2010-11. Anyway the major reason (but not the only one) why AMD lost the x86 war was their own management's decision to not go 45-32nm quickly when they had the lead over Intel. Intel's bribes may have cost them a billion or two, in lost revenues per annum, but they lost a lot more due to Ruiz & Co.
Posted on Reply
#102
Xuper
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.


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.
Someone answered :
No, this comment is referring to a different bug (and is why it is not redacted in the latest source). This workaround refers to preventing any executable code in the highest page and is done by reducing the constants below by the page size. KPTI is a separate workaround that is necessary to prevent leaking kernel memory during speculative execution on Intel's uarch, and is done by unmapping the kernel while executing userland.
Amd/comments/7nqwoe/_/ds4qihg
Posted on Reply
#104
EarthDog
Just wait for the AT article gents... that will provide a bit more than a data scrape of news across three articles/threads. ;)
Posted on Reply
#105
ensabrenoir
Intel's seems to be in the midst of a bad karma storm.......and their solution is:

....Amd can soooo capitalize on this......after they figure out how to not take a hit by it....
Posted on Reply
#106
R-T-B
efikkanI think your article needs to be updated.
No, it's not the same at all. I'm very familiar with the AMD high-register bug as it's linked to the linux "performance marginality"

It

a.) does not leak kernel memory, simply reboots the target system (this is the "bad things that'll happen")
b.) is fixed in epyc and TR solutions
Posted on Reply
#107
Captain_Tom
AMD will fix the patch, and just in time for 12nm Zen to launch further skull-crushing Intel's latest rebrand of Broadwell.

And to think, 64-Core flavors are on the way...
Posted on Reply
#108
dicktracy
So no performance drop from Windows Insiders. Linux taking the worst of things again.
Posted on Reply
#109
R-T-B
dicktracySo no performance drop from Windows Insiders. Linux taking the worst of things again.
...In one game. That is not at all IO bound.
Posted on Reply
#110
qubit
Overclocked quantum bit
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.
I did read about the beginnings and history of these two companies a long time ago. Did AMD get into x86, because IBM wanted a second source of x86 CPUs when they built their first PC maybe?

AMD has definitely made some bad business decisions and when you don't have as much resources in terms of money, fabs etc, the consequences of a bad decision is going to be more severe. I think it's a combination of this and Intel's dirty tricks against them which has lead to the current dominance of Intel over them. In fact, I seem to remember from that history that AMD were the underdog to Intel most of the time, right back to the early 70s.

And before anyone challenges me on this, no, I don't have reams of evidence of these dirty tricks by Intel, lol. It's just my opinion over reading many articles about these two over the years.
EarthDogThere 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. ;)
What, AMD aren't whiter than white? I'm shocked! :eek: Some people seem to think they are though and start to make excuses for them about their underperforming products, which tends to cause arguments in the forum. I dunno why people do this for companies who are just out to make a profit any way they can and have no loyalty to them whatsoever. And of course, AMD haven't paid for these people to shill for them...
Posted on Reply
#111
theGryphon
efikkanI 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.
Sooo...
behrouzSomeone answered :

Amd/comments/7nqwoe/_/ds4qihg
R-T-BNo, it's not the same at all. I'm very familiar with the AMD high-register bug as it's linked to the linux "performance marginality"

It

a.) does not leak kernel memory, simply reboots the target system (this is the "bad things that'll happen")
b.) is fixed in epyc and TR solutions
I guess it's you @efikkan who jumped the gun here...
Posted on Reply
#113
R-T-B
theGryphonSooo...





I guess it's you @efikkan who jumped the gun here...
To be fair, it's easy to do given the kernel dev commit notes aren't very forthcoming...
R0H1TNot my area of expertise, but here you go ~
What target machine was this done on?

EDIT: Ah, Intel. NVM.
Posted on Reply
#115
xorbe
That twitter confirms it then. Yup, that's the one.
Posted on Reply
#116
R-T-B
xorbeThat twitter confirms it then. Yup, that's the one.
Seems the exploit has officially been made open to the public.
Posted on Reply
#117
xorbe
R-T-BSeems the exploit has officially been made open to the public.
The public post detailing it is six months old, if that is indeed the one. It all seems to line up. KPTI should kill that exploit.
Posted on Reply
#118
R-T-B
xorbeThe public post detailing is six months old.
The difference is this is effectively a toolkit to utilize the exploit. There's a difference between saying "there's a problem" and utilizing it. It's about the difference between describing a gun and handing someone a loaded revolver.
Posted on Reply
#119
R0H1T
R-T-BThe difference is this is effectively a toolkit to utilize the exploit. There's a difference between saying "there's a problem" and utilizing it. It's about the difference between describing a gun and handing someone a loaded revolver.
You're assuming there weren't criminals already exploiting this?
Posted on Reply
#120
R-T-B
R0H1TYou're assuming there weren't criminals already exploiting this?
There'll be a lot more with a public toolkit. There's a class of criminal who does his own exploits. This group is rather small. Then there's the "script-kiddies" and that' a large group indeed.

You're basically saying, that because the blueprints to a handgun are available, I should've been worried that people in their homes will start 3d-printing them. Yes, that eventually happened, but it required a bit more than blueprints, and yes it did signifigantly increase the number of unregistered people with access to firearms...
Posted on Reply
#121
xorbe
So the good news is that it's only unlimited read access, and not write access? :toast:
Posted on Reply
#122
R0H1T
R-T-BThere'll be a lot more with a public toolkit. There's a class of criminal who does his own exploits. This group is rather small. Then there's the "script-kiddies" and that' a large group indeed.

You're basically saying, that because the blueprints to a handgun are available, I should've been worried that people in their homes will start 3d-printing them. Yes, that eventually happened, but it required a bit more than blueprints, and yes it did signifigantly increase the number of unregistered people with access to firearms...
That's why I asked how bad is it? I also would love to know the scope of the exploit & if there's any OS immune to this kind of attack, be it for Intel or possibly even AMD :confused:
Also there's possibly more than one exploit (uncovered) out there.
Posted on Reply
#123
R-T-B
R0H1TThat's why I asked how bad is it? I also would love to know the scope of the exploit & if there's any OS immune to this kind of attack, be it for Intel or possibly even AMD :confused:
Also there's possibly more than one exploit (uncovered) out there.
That's a very fair question, to be honest. I'd like to know as well.
xorbeSo the good news is that it's only unlimited read access, and not write access? :toast:
Read access is actually far worse than you think. You can read passwords, keys, everything out of kernel memory.
Posted on Reply
#124
xorbe
Hah, I know, I was making a joke.
Posted on Reply
#125
notb
qubitI did read about the beginnings and history of these two companies a long time ago. Did AMD get into x86, because IBM wanted a second source of x86 CPUs when they built their first PC maybe?
Well yes. This was a deal - Intel partly outsourced production to AMD. But it wasn't the first licensing deal they had. And in 70s AMD was just cloning Intel's stuff.
This is just a reminder that the status quo we have today, with 2 companies with their own products, is a fairly new one.
So the short answer for
"Can you imagine how much better and cheaper these products would be if both companies had been equal competitors all this time?"
is: there would most likely be no AMD today. :-)
AMD has definitely made some bad business decisions and when you don't have as much resources in terms of money, fabs etc,
Some?!
Losing fabs and money was one of their decisions. They wanted to be like Apple - just designing stuff, innovating.
But earlier they had the manufacturing, they had the tech, they had a client base. They had everything.

15 years ago I just loved AMD. Everyone did. We were not fanboys in modern meaning (as in: blind Intel haters), but we believed in this company.
When they bought ATI, people were like "WOW - they'll make a closed PC ecosystem! Or a console!". This was an amazing idea! But nothing like that happened.

10 years later people still highlight the advantage AMD has - making both high-end CPUs and GPUs - but these are just parts. You make a CPU and a GPU and you can sell them for $100 each. But if you add a cheap mobo and a plastic case, you can charge $400 for the whole set.
People also like to say that AMD makes chips for most consoles. But if they decided to make their own console in 2007, they would most likely take the second place behind Sony PS (while still making GPUs for them as well :-)).
AMDs total revenue (so GPU+CPU) for 2016 was 4.3 bln USD. Cute.
PlayStation revenue was 14.7 bln USD.
XBOX revenue is not official, but should be around 5-6 bln USD.

So effectively, in the end, the best move they did (buying ATI) became their worse one.
I think it's a combination of this and Intel's dirty tricks against them which has lead to the current dominance of Intel over them. In fact, I seem to remember from that history that AMD were the underdog to Intel most of the time, right back to the early 70s.
AMD was not the underdog to Intel. Intel basically owned them and supported their development. But they let them lose and suddenly it was too late. AMD learned a lot, quickly became the second-largest CPU manufacturer and now regulators won't agree on a takeover (just the GPU part is another story :-)).
Think about it next time you'll have the idea that government is on Intel's side and is slowing AMD down. :-P
Posted on Reply
Add your own comment
Nov 21st, 2024 05:09 EST change timezone

New Forum Posts

Popular Reviews

Controversial News Posts