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

[R0H1T]

I 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?
https://gruss.cc/files/kaiser.pdf

 

[eidairaman1]

I 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?
https://gruss.cc/files/kaiser.pdf

1 key to this here
https://www.techpowerup.com/forums/...law-kernel-patches.240187/page-3#post-3777532

By the way, heres another piece

https://www.techpowerup.com/forums/...l-vt-flaw-kernel-patches.240187/#post-3777471

From @btarunr

https://lkml.org/lkml/2017/12/27/2

 

[AnnCore]

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.

 

[64K]

Maybe that's why Krzanich dumped so much of his Intel Stock about a month ago and now is only holding the bare minimum necessary to be able to keep his CEO position.

https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx

 

[Vya Domus]

Maybe that's why Krzanich dumped so much of his Intel Stock about a month ago and now is only holding the bare minimum necessary to be able to keep his CEO position.

https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx

That's pretty interesting but knowing Intel and their shady doings in the past it wouldn't surprise me if there is something else to this.

 

[ne6togadno]

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.

https://en.wikipedia.org/wiki/X86-64

 

[AnnCore]

https://en.wikipedia.org/wiki/X86-64

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

 

[RCoon]

Warning points issued to those incapable of listening to a public request. Last polite public warning.

 

[R-T-B]

I 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?

 

[TheoneandonlyMrK]

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

 

[R-T-B]

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

 

[jahramika]

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

 

[SirB]

In case you missed it...
Intel's CEO just sold all of his stock* in november. I wonder why? (except minimum required)*
AMD here i come.
https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx

 

[jahramika]

OMG 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

 

[Citizenx]

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

 

[EarthDog]

Everyone knows that repeater was sent out by Intel

Same guy that said AMD wasn't fixing the older games that were borked?

 

[Patriot]

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

 

[qubit]

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

 

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

 

[TheoneandonlyMrK]

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.

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.

 

[Patriot]

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.

The part where their ISA does not even support the operation that has the backdoor in it.

Suse also greenlit the patch from AMD...

https://www.reddit.com/r/hardware/comments/7nr7dy/_/ds46kfe

 

[notb]

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

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.

 

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

 

[64K]

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

 

[efikkan]

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

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

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

https://git.kernel.org/pub/scm/linu...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.

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