• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.

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

efikkan said:
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.


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.
Click to expand...
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 :)
 
notb said:
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.
Click to expand...
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.
 
efikkan said:
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.


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.
Click to expand...

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.
Click to expand...

https://www.reddit.com/r/Amd/comments/7nqwoe/_/ds4qihg
 
Just wait for the AT article gents... that will provide a bit more than a data scrape of news across three articles/threads. ;)
 
Intel's seems to be in the midst of a bad karma storm.......and their solution is:
1515000899375.png

....Amd can soooo capitalize on this......after they figure out how to not take a hit by it....
 
efikkan said:
I think your article needs to be updated.
Click to expand...

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
 
dicktracy said:
So no performance drop from Windows Insiders. Linux taking the worst of things again.
Click to expand...

...In one game. That is not at all IO bound.
 
notb said:
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.
Click to expand...
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.

EarthDog said:
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. ;)
Click to expand...
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...
 
efikkan said:
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.
Click to expand...

Sooo...

behrouz said:
Someone answered :

https://www.reddit.com/r/Amd/comments/7nqwoe/_/ds4qihg
Click to expand...

R-T-B said:
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
Click to expand...

I guess it's you @efikkan who jumped the gun here...
 
That twitter confirms it then. Yup, that's the one.
 
xorbe said:
That twitter confirms it then. Yup, that's the one.
Click to expand...

Seems the exploit has officially been made open to the public.
 
R-T-B said:
Seems the exploit has officially been made open to the public.
Click to expand...

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.
 
xorbe said:
The public post detailing is six months old.
Click to expand...

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.
 
R-T-B said:
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.
Click to expand...
You're assuming there weren't criminals already exploiting this?
 
R0H1T said:
You're assuming there weren't criminals already exploiting this?
Click to expand...

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...
 
So the good news is that it's only unlimited read access, and not write access? :toast:
 
R-T-B said:
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...
Click to expand...
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.
 
R0H1T said:
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.
Click to expand...

That's a very fair question, to be honest. I'd like to know as well.

xorbe said:
So the good news is that it's only unlimited read access, and not write access? :toast:
Click to expand...

Read access is actually far worse than you think. You can read passwords, keys, everything out of kernel memory.
 
Hah, I know, I was making a joke.
 
Last edited:
You must log in or register to reply here.
Back
Top