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

[TheoneandonlyMrK]

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.

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

 

[R0H1T]

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.

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.

 

[Xuper]

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.

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.

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

 

[figuretti]

Apparently someone could recreate the bug...

https://twitter.com/i/web/status/948561799875502080

 

[EarthDog]

Just wait for the AT article gents... that will provide a bit more than a data scrape of news across three articles/threads.

 

[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....

 

[R-T-B]

I 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

 

[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...

 

[dicktracy]

So no performance drop from Windows Insiders. Linux taking the worst of things again.

 

[R-T-B]

So no performance drop from Windows Insiders. Linux taking the worst of things again.

...In one game. That is not at all IO bound.

 

[qubit]

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.

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.

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.

What, AMD aren't whiter than white? I'm shocked! 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...

 

[theGryphon]

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.

Sooo...

Someone answered :

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

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

I guess it's you @efikkan who jumped the gun here...

 

[R0H1T]

Not my area of expertise, but here you go ~

https://twitter.com/i/web/status/948561799875502080

 

[R-T-B]

Sooo...





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...

Not my area of expertise, but here you go ~

https://twitter.com/i/web/status/948561799875502080

What target machine was this done on?

EDIT: Ah, Intel. NVM.

 

[R0H1T]

To be fair, it's easy to do given the kernel dev commit notes aren't very forthcoming...



What taget machine was this done on?

More details here ~

https://twitter.com/i/web/status/948561799875502080

So how bad is it?

 

[xorbe]

That twitter confirms it then. Yup, that's the one.

 

[R-T-B]

That twitter confirms it then. Yup, that's the one.

Seems the exploit has officially been made open to the public.

 

[xorbe]

Seems 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.

 

[R-T-B]

The 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.

 

[R0H1T]

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.

You're assuming there weren't criminals already exploiting this?

 

[R-T-B]

You'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...

 

[xorbe]

So the good news is that it's only unlimited read access, and not write access?

 

[R0H1T]

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...

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
Also there's possibly more than one exploit (uncovered) out there.

 

[R-T-B]

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
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.

So the good news is that it's only unlimited read access, and not write access?

Read access is actually far worse than you think. You can read passwords, keys, everything out of kernel memory.

 

[xorbe]

Hah, I know, I was making a joke.