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



## btarunr (Jan 3, 2018)

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. 





*View at TechPowerUp Main Site*


----------



## LogitechFan (Jan 3, 2018)

Test it at 4K (c) AMD

Karma is biatch


----------



## RejZoR (Jan 3, 2018)

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


----------



## Deleted member 172152 (Jan 3, 2018)

RejZoR said:


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


I'll let Americans sue both Intel and Kernel makers.


----------



## Flaky (Jan 3, 2018)

@btarunr
What is memory leak


----------



## Jism (Jan 3, 2018)

Owned. Some people are in panic here. Immediatly releasing a patch that simply kills off the competition.


----------



## qubit (Jan 3, 2018)

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

This really pisses me off. It looks like Intel have used their power and influence to corrupt the open source scene to put AMD at the same disadvantage as them and thus stifle competition. They always seem to get away with these tactics too. Remember when AMD was first with a 64-bit x86 CPU way back around 2005, but Microsoft mysteriously held back the release of 64-bit Windows XP until Intel was ready with their own 64-bit CPUs over a year later? This totally nullified AMD's big advantage, thus stifling competition. So out of order.


----------



## ArbitraryAffection (Jan 3, 2018)

Intel is a scummy corporation, force it on AMD too because of their mistake. Despite the fact that I likely will not use any workload affected (or at least I hope so) as a Ryzen owner I sincerely hope AMD doesn't get affected out of principle.


----------



## notb (Jan 3, 2018)

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.


RejZoR said:


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


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.


eidairaman1 said:


> Waiting for trolls to deflect and try minimizing the ARCHITECTURE FLAW in intel cpus


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


----------



## eidairaman1 (Jan 3, 2018)

*Well it is a serious flaw that Intel has* @notb. What's the matter? You don't like the fact your precious intel has been exposed for the lies all these years?  They tried hiding this serious security/performance flaw for 10+ years. They are so corrupt to try and force a patch for ms to auto download on w10 systems that they should be sued.

Well here's proof read'em and weep.


----------



## RejZoR (Jan 3, 2018)

Any penalty sucks, even if just 5%. You bought the CPU based on reviews that said otherwise. And now it'll get gimped.

EDIT:
Btw, wasn't it released that this flaw doesn't affect 6th series and below? Or was that for some other flaw? But I think it was like this, because I know I was releaved when I heard my 5820K wasn't affected back then...


----------



## Jism (Jan 3, 2018)

I am glad that i am sticking with W7, and when that expires, head over to Linux. Mature enough by now and alot you can do with Wine. All the goods without the privacy tampering, forced (driver) updates and what more. It sucks for Intel and proberly other vendors such as VIA as well that these processors get the same penalty due to a flaw in Intel CPU's. So they create a patch that they coud'nt come up with any better harming now other companies and CPU's.

Intel needs to work on the IME / security / rough testing of their CPU's before actually releasing. But they are actually taking the risc that CPU's might leave the factory with critical bugs. This reminds me being on a shared (hosting) server, with SSH you could simply inspect the unix TMP map and grab data from various users on the same server, where normally you woud'nt had any acces to. Accessing one VM from another VM instance is pretty much bad.


----------



## Imsochobo (Jan 3, 2018)

notb said:


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



In some cases even more!
https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2

In others, none but it will be quite severe


----------



## nem.. (Jan 3, 2018)

copi-pasta
https://www.reddit com/r/hardware/comments/7nngqd/intel_bug_incoming/
There is evidence of a massive Intel CPU hardware bug (currently under embargo) that directly affects big cloud providers like Amazon and Google. The fix will introduce notable performance penalties on Intel machines (30-35%).

People have noticed a recent development in the Linux kernel: a rather massive, important redesign (page table isolation) is being introduced very fast for kernel standards... and being backported! The "official" reason is to incorporate a mitigation called KASLR... which most security experts consider almost useless. There's also some unusual, suspicious stuff going on: the documentation is missing, some of the comments are redacted (



__ https://twitter.com/i/web/status/947147105684123649) and people with Intel, Amazon and Google emails are CC'd.

*According to one of the people working on it, PTI is only needed for Intel CPUs, AMD is not affected by whatever it protects against (https://lkml.org/lkml/2017/12/27/2). PTI affects a core low-level feature (virtual memory) and has severe performance penalties: 29% for an i7-6700 and 34% for an i7-3770S, according to Brad Spengler from grsecurity*. PTI is simply not active for AMD CPUs. The kernel flag is named X86_BUG_CPU_INSECURE and its description is "CPU is insecure and needs kernel page table isolation".

Microsoft has been silently working on a similar feature since November: 



__ https://twitter.com/i/web/status/930412525111296000
People are speculating on a possible massive Intel CPU hardware bug that directly opens up serious vulnerabilities on big cloud providers which offer shared hosting (several VMs on a single host), for example by letting a VM read from or write to another one.

*EDIT1*: the examples of the i7 series, are just examples. This affects all Intel platforms as far as I can tell.


----------



## eidairaman1 (Jan 3, 2018)

Jism said:


> I am glad that i am sticking with W7, and when that expires, head over to Linux. Mature enough by now and alot you can do with Wine. All the goods without the privacy tampering, forced (driver) updates and what more. It sucks for Intel and proberly other vendors such as VIA as well that these processors get the same penalty due to a flaw in Intel CPU's. So they create a patch that they coud'nt come up with any better harming now other companies and CPU's.
> 
> Intel needs to work on the IME / security / rough testing of their CPU's before actually releasing. But they are actually taking the risc that CPU's might leave the factory with critical bugs. This reminds me being on a shared (hosting) server, with SSH you could simply inspect the unix TMP map and grab data from various users on the same server, where normally you woud'nt had any acces to. Accessing one VM from another VM instance is pretty much bad.



If ms forces this on all users AMD needs to write their own that removes the patch from AMD systems completely


----------



## Jism (Jan 3, 2018)

I guess it's that critical that there is no time to exactly figure out what is going on and exactly write a intel patch only. Someone decided to fully disable some feature and push it out causing AMD cpu's to be penalised as well for it.


----------



## eidairaman1 (Jan 3, 2018)

nem.. said:


> some webs are talking about 35% i mean some extreme cases perhaps



Check your private messages by using the envelope icon



Jism said:


> I guess it's that critical that there is no time to exactly figure out what is going on and exactly write a intel patch only. Someone decided to fully disable some feature and push it out causing AMD cpu's to be penalised as well for it.



They did it to keep an anti competitive practice going, theyve been underhanded since super 7 days


----------



## fullinfusion (Jan 3, 2018)

eidairaman1 said:


> Waiting for trolls to deflect and try minimizing the ARCHITECTURE FLAW in intel cpus


I'm trying to rationalize something here... Why do these news feeds seem like 2-3 days old and just now showing up here? Am I going into the future or am I just nuts?? Or is the driver snoozing while supposed to be driving!


----------



## eidairaman1 (Jan 3, 2018)

fullinfusion said:


> I'm trying to rationalize something here... Why do these news feeds seem like 2-3 days old and just now showing up here? Am I going into the future or am I just nuts?? Or is the driver snoozing while supposed to be driving!



You are at home bro lol Im off. This is extremely current news


----------



## hellrazor (Jan 3, 2018)

Linux has a -nopti kernel boot option for us Linux+AMD users.


----------



## laszlo (Jan 3, 2018)

amd can sue developers who made the patches without taking in consideration the immunity of their cpu's to this vulnerability and win in court anytime...

no matter how big intel influence, is suicidal to treat all x86 cpu's as flawed....

P.S.
amd only need to ask their lawyers to send out compensation request letters which have 8-10 digit numbers and for sure nobody will have the balls ($) to do what intel "recommend"


----------



## fullinfusion (Jan 3, 2018)

eidairaman1 said:


> You are at home bro lol Im off. This is extremely current news


That I read about 2 days ago via not HERE.. I think I posted a month ago or so I don't get my news here anymore.. have a good night man


----------



## theGryphon (Jan 3, 2018)

For advanced Linux users, there is no concern, you can even compile your own kernel excluding your system from this patch. But most are not that advanced, so this is some serious BS if left like this. I'm hoping that this is a one-for-all emergency response that can be rectified once AMD processors are (hopefully) cleared after some investigation...


----------



## qubit (Jan 3, 2018)

eidairaman1 said:


> Waiting for trolls to deflect and try minimizing the ARCHITECTURE FLAW in intel cpus


'tis nothing, don't make such a big deal out of it! This patch simply puts everyone on a level playing field to make things fair.

#intelapologiststrikesagain


----------



## TheoneandonlyMrK (Jan 3, 2018)

theGryphon said:


> For advanced Linux users, there is no concern, you can even compile your own kernel excluding your system from this patch. But most are not that advanced, so this is some serious BS if left like this. I'm hoping that this is a one-for-all emergency response that can be rectified once AMD processors are (hopefully) cleared after some investigation...


Is this just affecting the performance of vm's using the linux kernal??


----------



## eidairaman1 (Jan 3, 2018)

theoneandonlymrk said:


> Is this just affecting the performance of vm's using the linux kernal??



No it's more than that

https://www.techpowerup.com/forums/...r-cpu-bug-affecting-datacenters.240174/page-2


----------



## jigar2speed (Jan 3, 2018)

qubit said:


> 'tis nothing, don't make such a big deal out of it! This patch simply puts everyone on a level playing field to make things fair.
> 
> #intelapologiststrikesagain



LOL, nice one.


----------



## notb (Jan 3, 2018)

RejZoR said:


> Any penalty sucks, even if just 5%. You bought the CPU based on reviews that said otherwise. And now it'll get gimped.


Here's the thing. Datacenters don't buy CPUs based on reviews. 
In fact most PC owners don't look at reviews, nor would they understand them. Even many gamers don't.

Yes, this is an important issue, but many of you are overestimating it's importance for the whole market.
I mean: isn't the main argument of Intel critics that they only provide 5% with each generation? That it's _nothing, marginal, irrelevant_? That Kaby Lake is just a revamped Haswell or something?
So now we have a CPU design flaw that, on average, moves us a generation back. Why is it suddenly such a deal for the same people? 

I like the +5% yearly, so I should be pissed off when it's taken away from me. And I might be, but I'm waiting for the patch. We'll see what it does to my PC. Possibly (hopefully) not much.



eidairaman1 said:


> Well it is a serious flaw that Intel has @notb. What's the matter don't like the fact your precious intel has the issue and they are so corrupt to try and force a patch for ms to auto download on w10 systems?


Of course it's a serious flaw, But there is a difference between 5% and 30% - all I'm saying. If it's 5%, most people won't even notice.

BTW:
Bullseye on auto-update. I have nothing against it. Actually, since I moved to W10 on all my PCs, I stopped worrying about the updates, I stopped reading their descriptions and so on. It saves a lot of time. You're thinking less about technical issues and more about actual problems. It's like moving from C++ to C# (although C++ evolved anyway).

Think about how incoherent people are. Almost no one cares about how a new OS version differs from the previous one. Yet, so many people freak out about updates.
I know it slightly harms your ego, because you're "an enthusiast", you want to have control over your PC and so on. But productivity-wise, it really saves a lot of time. I'm trusting a 3rd party cleaning company with my suits, so why would I not trust Microsoft or Intel with my PC? 


theoneandonlymrk said:


> Is this just affecting the performance of vm's using the linux kernal??


No, it will affect all PCs. But the issue itself is more severe on servers. (security-wise).
But here's some consolation, in case you worry too much. Performance of your desktop is compromised by server-specific needs anyway. It's been like that since the architectures were unified.


----------



## TheoneandonlyMrK (Jan 3, 2018)

notb said:


> Here's the thing. Datacenters don't buy CPUs based on reviews.
> In fact most PC owners don't look at reviews, nor would they understand them. Even many gamers don't.
> 
> Yes, this is an important issue, but many of you are overestimating it's importance for the whole market.
> ...


Im not worried i can refuse the patch but don't play down the fact intels CPU design this last few generations has been a shit storm of failure on the security front or the fact that it's underhanded bullshit to apply this fix unilaterally.


----------



## RejZoR (Jan 3, 2018)

Admins of data centers also know the performance metrics. Having a performance penalty of up to 30% on Intel CPU kinda screws things up pretty badly. Especially if you just spent few millions on brand new clusters where you were hoping for that extra gain and you basically end up on performance levels of your old clusters. That kinda sucks doesn't it?


----------



## Jism (Jan 3, 2018)

Exactly. You have to understand that within DC's there are clusters of Intel based CPU's running 24/7. A penalty of 5% up to 30% can run very large into numbers depending on type of workload. So yeah, intel is having a situation here.


----------



## eidairaman1 (Jan 3, 2018)

I smell class action for misrepresenting and allowing a flawed product line dating to 2007 till now to be pushed upon end users.


----------



## notb (Jan 3, 2018)

RejZoR said:


> Admins of data centers also know the performance metrics.


But not from reviews. 
Performance is not the most important issue in datacenters. So yes, 5% is a bummer, but it's also not the end of the world. People will still buy Xeons. It's just that Intel may be forced to lower prices a bit to a more adequate level.


> Having a performance penalty of up to 30% on Intel CPU kinda screws things up pretty badly. Especially if you just spent few millions on brand new clusters where you were hoping for that extra gain and you basically end up on performance levels of your old clusters. That kinda sucks doesn't it?


No one said it doesn't suck. And BTW: from what I've seen it's at least up to 50%. So if you want to use an extreme case, do it properly.


----------



## RejZoR (Jan 3, 2018)

No, 25-30% is then a good average if 50% is an absolute extreme case...


----------



## eidairaman1 (Jan 3, 2018)

RejZoR said:


> No, 25-30% is then a good average if 50% is an absolute extreme case...



Either way it is unacceptable


----------



## Deleted member 172152 (Jan 3, 2018)

notb said:


> But not from reviews.
> Performance is not the most important issue in datacenters. So yes, 5% is a bummer, but it's also not the end of the world. People will still buy Xeons. It's just that Intel may be forced to lower prices a bit to a more adequate level.
> 
> No one said it doesn't suck. And BTW: from what I've seen it's at least up to 50%. So if you want to use an extreme case, do it properly.


Except datacenters get a 30% performance decrease! MAJOR companies suddenly will have 30% slower cloud servers!!!!! That's going to piss them off for sure!!!!


----------



## notb (Jan 3, 2018)

eidairaman1 said:


> I smell class action for misrepresenting and allowing a flawed product line dating to 2007 till now to be pushed upon end users.


Class action seems groundless. It's a product fault, not misrepresenting, and Intel is going to fix it as much as it can.
But on the other hand, fixing this will generate some costs in large datacenters and this is something with a lawsuit potential - but only for companies that still use flawed CPUs, not all that had since 2007.


RejZoR said:


> No, 25-30% is then a good average if 50% is an absolute extreme case...


That's some wicked math going on. How did you estimate this? :-D


----------



## Deleted member 172152 (Jan 3, 2018)

notb said:


> Class action seems groundless. It's a product fault, not misrepresenting, and Intel is going to fix it as much as it can.
> But on the other hand, fixing this will generate some costs in large datacenters and this is something with a lawsuit potential - but only for companies that still use flawed CPUs, not all that had since 2007.
> 
> That's some wicked math going on. How did you estimate this? :-D


ALL the CPU's from Intel the last ten years have the flaw!!!! Some of the most powerful supercomputers can be slowed down by 30%!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


----------



## RejZoR (Jan 3, 2018)

notb said:


> Class action seems groundless. It's a product fault, not misrepresenting, and Intel is going to fix it as much as it can.
> But on the other hand, fixing this will generate some costs in large datacenters and this is something with a lawsuit potential - but only for companies that still use flawed CPUs, not all that had since 2007.
> 
> That's some wicked math going on. How did you estimate this? :-D



The most basic math? If 5% is lowest estimate and 50% the highest, where is the rough middle?


----------



## eidairaman1 (Jan 3, 2018)

notb said:


> Class action seems groundless. It's a product fault, not misrepresenting, and Intel is going to fix it as much as it can.
> But on the other hand, fixing this will generate some costs in large datacenters and this is something with a lawsuit potential - but only for companies that still use flawed CPUs, not all that had since 2007.
> 
> That's some wicked math going on. How did you estimate this? :-D



There is no fixing it without refabing the chips, otherwise it's a patch that drops performance 5-30% and they are trying to force it on all users when the flaw isn't in AMD parts. Stop trying to minimize and deflect the issue.

The Jig is up, just give up dude.


----------



## HTC (Jan 3, 2018)

hellrazor said:


> Linux has a -nopti kernel boot option for us Linux+AMD users.



How does one go about using it?

Though i'm now more familiar with Linux, this sort of thing is still out of my reach.



theGryphon said:


> For advanced Linux users, there is no concern, you can even compile your own kernel excluding your system from this patch. But most are not that advanced, so this is some serious BS if left like this. *I'm hoping that this is a one-for-all emergency response that can be rectified once AMD processors are (hopefully) cleared after some investigation...*



They better well be. When that happens, i'd demand a nice compensation, if i were in AMD's shoes!


----------



## qubit (Jan 3, 2018)

I'm beginning to wonder if this serious enough to warrant a product recall and replacement with a later stepping that has this flaw fixed? Waddya think, @eidairaman1 ?

It will cost them millions of that's the case, lol.


----------



## R0H1T (Jan 3, 2018)

notb said:


> *Class action seems groundless*. It's a product fault, not misrepresenting, and Intel is going to fix it as much as it can.
> But on the other hand, fixing this will generate some costs in large datacenters and this is something with a lawsuit potential - but only for companies that still use flawed CPUs, not all that had since 2007.
> 
> That's some wicked math going on. How did you estimate this? :-D


Depends on how long they've known about this, or were informed about it. Like I said in the other thread, this flaw was possibly revelead back in 2016, so if somehow it went unpatched & Intel/MS/Linus just sat on it till they found the attack vector affecting systems in the wild & then issued this emergency patch, then they're all in trouble. More so the cloud vendors than Intel itself atm, of course someone like Google/FB/Amazon could just sue Intel if there's any litigation coming their way due to this, or even a performance impact due to that 5~30% (or more) drop in performance.

I'm more interested in how old(er) OS' can be affected by it, if so then Intel's really effed


----------



## notb (Jan 3, 2018)

Hugh Mungus said:


> ALL the CPU's from Intel the last ten years have the flaw!!!! Some of the most powerful supercomputers can be slowed down by 30%!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


The number of "!" is growing quickly!

Since this is a security issue, most supercomputers will be perfectly safe. Admins will simply ignore this patch. Linux kernels in supercomputers are highly customized anyway.
This is an issue for datacenters.

What I meant is that you'd have to use a faulty CPU at the moment, not just have owned it in the past. So it's not about all CPUs made since 2007. You won't be able to sue Intel for a CPU that you've thrown away, because you haven't lost anything.



RejZoR said:


> The most basic math? If 5% is lowest estimate and 50% the highest, where is the rough middle?


Please don't tempt me...


----------



## dorsetknob (Jan 3, 2018)

notb said:


> Class action seems groundless. It's a product fault,


sorry mate for someone thats a 2nd rate  tr**l you seem to ignore  1st rate reason for a class action ie faulty product (with known but undisclosed  till now fault)


----------



## eidairaman1 (Jan 3, 2018)

qubit said:


> I'm beginning to wonder if this serious enough to warrant a product recall and replacement with a later stepping that has this flaw fixed? Waddya think, @eidairaman1 ?
> 
> It will cost them millions of that's the case, lol.


Intel has been trying to hide these flaws for 10+years now.

I think they should be required to replace all of those parts corps bought recently and pull all affected parts from markets till the flaws are eliminated, on top of that give discounts to users of oldest parts towards system upgrades to parts without  flaws and close up all backdoors. Release said patch for intel only temporarily and not force it on everyone.

I think this is a part of the reason why Intel switched CEOs recently



dorsetknob said:


> sorry mate for someone thats a 2nd rate  tr**l you seem to ignore  1st rate reason for a class action ie faulty product (with known but undisclosed  till now fault)



Yup


----------



## RejZoR (Jan 3, 2018)

Can't wait to see Intel releasing new generation and bragging about % performance differences to these flawed gen patched parts...


----------



## eidairaman1 (Jan 3, 2018)

RejZoR said:


> Can't wait to see Intel releasing new generation and bragging about % performance differences to these flawed gen patched parts...



Yup with another socket change smh...


----------



## nem.. (Jan 3, 2018)




----------



## wiak (Jan 3, 2018)

Here is the AMD Patch
https://lkml.org/lkml/2017/12/27/2


----------



## eidairaman1 (Jan 3, 2018)

wiak said:


> Here is the AMD Patch
> https://lkml.org/lkml/2017/12/27/2



That's a message that was posted by @btarunr in the first post of this thread.


----------



## Assimilator (Jan 3, 2018)

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.



eidairaman1 said:


> Intel has been trying to hide these flaws for 10+years now.



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.


----------



## Vya Domus (Jan 3, 2018)

Assimilator said:


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



Pure speculation.


----------



## eidairaman1 (Jan 3, 2018)

Assimilator said:


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



If you would read several links throughout tpu relating to this issue you will see such. By the way I never said anyone was a fanboy, you did. You can't stand the fact Intel was caught in a lie and now the truth of their lies and corruption is coming out now.
So you need to get your fingers off the keyboard and let the adults discuss here instead of you trying to attack members with your baseless and stupid comments.

The reason you don't like what I write is because you can't see the light of truth.
BY THE WAY I'M SORRY MY COMMENTS IRRITATE YOU SO MUCH @Assimilator!
...NOT! DON'T LIKE ME PUT ME ON IGNORE!

By the way welcome to the ignore list


----------



## Assimilator (Jan 3, 2018)

Vya Domus said:


> Pure speculation.



As are the conspiracy theories in this thread. My speculation, however, is founded on knowledge of computer hardware and security best practices, as opposed to "INTEL IS TEH EVIL".

Your move.



eidairaman1 said:


> If you would read several links throughout tpu relating to this issue you will see such, so you need to get your fingers off the keyboard and let the adults discuss here instead of you trying to attack members with your baseless and stupid comments.
> 
> BY THE WAY I'M SORRY MY COMMENTS IRRITATE YOU SO MUCH @Assimilator!
> ...NOT! DON'T LIKE ME PUT ME ON IGNORE!
> ...



Remind me, which one of us is making the hysterical claim that "Intel has been trying to hide these flaws for 10+years now", and therefore has the responsibility to provide proof to substantiate said claim?

Oh right, it's you.


----------



## Parn (Jan 3, 2018)

nix kernels are open source. I wonder why AMD don't just compile and release their own replacement kernel if their requests have been ignored by those kernel developers.

Do Windows kernels have the same patch? If so, I will make sure my home 2012 R2 server running hyper-v do not apply for the update.


----------



## eidairaman1 (Jan 3, 2018)

Assimilator said:


> As are the conspiracy theories in this thread. My speculation, however, is founded on knowledge of computer hardware and security best practices, as opposed to "INTEL IS TEH EVIL".
> 
> Your move.
> 
> ...



The proof is in the pudding buttercup, do the search in tpu and it shall be revealed to you. By the way don't like me put me on ignore snowflake


----------



## Assimilator (Jan 3, 2018)

Parn said:


> nix kernels are open source. I wonder why AMD don't just compile and release their own replacement kernel if their requests have been ignored by those kernel developers.



That would be a major PITA since they would have to maintain a kernel build for every version of every distro. And most people who don't want to mess around with compiling their own kernel, also probably don't want to mess around getting kernel binaries from non-official distro sources. Much easier to just boot your kernel with the -nopti flag if you are running AMD/really don't want PTI enabled.

On the flipside, the majority of people and companies that actually care enough about PTI's performance impact to want it disabled, are probably already building their kernels from source - so they'll just turn it off at compile time.


----------



## eidairaman1 (Jan 3, 2018)

Parn said:


> nix kernels are open source. I wonder why AMD don't just compile and release their own replacement kernel if their requests have been ignored by those kernel developers.
> 
> Do Windows kernels have the same patch? If so, I will make sure my home 2012 R2 server running hyper-v do not apply for the update.



This will roll to Windows at some point. I would honestly put a safeguard up


----------



## Peter1986C (Jan 3, 2018)

Parn said:


> nix kernels are open source. I wonder why AMD don't just compile and release their own replacement kernel if their requests have been ignored by those kernel developers.


Linux distributors possibly rather leave the patch enabled for all on X86(-64) until it is cleared up whether it's necessary (better safe than sorry). And Linux distributors get the kernel from the Linux Foundation, not from AMD/Intel.


eidairaman1 said:


> The proof is in the pudding buttercup, do the search in tpu and it shall be revealed to you. By the way don't like me put me on ignore snowflake


Dude, take a breath.


----------



## eidairaman1 (Jan 3, 2018)

Peter1986C said:


> Dude, take a breath.



Tell that to Assimilator


----------



## ShurikN (Jan 3, 2018)

Don't have a doubt in my mind Intel pulled some underhanded move directly from "Intel's sleazy playbook of anti-consumerism". It's in their blood after all.


----------



## jigar2speed (Jan 3, 2018)

Assimilator said:


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



You need to keep quiet sometimes. (we know you hate AMD) The new patch is already out that excludes AMD CPUs.


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


__
		https://www.reddit.com/r/hardware/comments/7nqy3h/_/ds42kks


----------



## RCoon (Jan 3, 2018)

I'm handing out reply bans if you guys don't calm the hell down. You're adults. Act like it. Use the ignore functionality if a member makes you botty-bothered. I came back from the new year with over a hundred report alerts because people are dead set on acting like they have the mental capacity of a parsnip.

Things people forget about this forum:
1. This is the internet. Thick skin is required.
in contrast;
2. You are free to post whatever you want. You are not free of the consequences of those posts. I'm very much free to implement said consequences.


----------



## EarthDog (Jan 3, 2018)

This... is bad for cloud and datcenters. However any decently planned cloud provider has mkre than ample headroom to absorb a 30% hit if it gets that high (not that it is ok...at all. Just saying it can be mitigated). I dont have my head completely wrapped around the issue, admitedly. 

That will be the only thing i post on the subject at tpu. The maturity level in this forum, and what ive seen in this thread, hit an all time low. Every day it gets more difficult to have adult conversations with people at this forum... its like the kids table at the holidays. And the kids bave loudest voices drowning out a reasonable conversation. Pathetic. It all started with whoever posted that dumb shit about trolling and intel sympathizers...


----------



## Parn (Jan 3, 2018)

Assimilator said:


> That would be a major PITA since they would have to maintain a kernel build for every version of every distro. And most people who don't want to mess around with compiling their own kernel, also probably don't want to mess around getting kernel binaries from non-official distro sources. Much easier to just boot your kernel with the -nopti flag if you are running AMD/really don't want PTI enabled.
> 
> On the flipside, the majority of people and companies that actually care enough about PTI's performance impact to want it disabled, are probably already building their kernels from source - so they'll just turn it off at compile time.



Ah, so there is a boot flag to turn it off. Thank god. Now I don't have to worry about excluding the kernel update or compiling one myself on my Fedora desktop and CentOS home server.


----------



## R0H1T (Jan 3, 2018)

More info ~ https://lwn.net/Articles/738975/


> Since the beginning, Linux has mapped the kernel's memory into the address space of every running process. There are solid performance reasons for doing this, and the processor's memory-management unit can ordinarily be trusted to prevent user space from accessing that memory. More recently, though, some more subtle security issues related to this mapping have come to light, leading to the rapid development of a new patch set that ends this longstanding practice for the x86 architecture.
> 
> *Some address-space history*
> On 32-bit systems, the address-space layout for a running process dedicated the bottom 3GB (0x00000000 to 0xbfffffff) for user-space use and the top 1GB (0xc0000000 to 0xffffffff) for the kernel. Each process saw its own memory in the bottom 3GB, while the kernel-space mapping was the same for all. On an x86_64 system, the user-space virtual address space goes from zero to 0x7fffffffffff (the bottom 47 bits), while kernel-space mappings are scattered in the range above 0xffff880000000000. While user space can, in some sense, see the address space reserved for the kernel, it has no actual access to that memory.
> ...


The most important part ~ This paper from Daniel Gruss et al. [PDF] *cites a number of hardware-based attacks on KASLR. They use techniques like exploiting timing differences in fault handling, observing the behavior of prefetch instructions, or forcing faults using the Intel TSX (transactional memory) instructions. There are rumors circulating that other such channels exist but have not yet been disclosed. In all of these cases, the processor responds differently to a memory access attempt depending on whether the target address is mapped in the page tables, regardless of whether the running process can actually access that location. These differences can be used to find where the kernel has been placed — without making the kernel aware that an attack is underway.*

So if the rumors are true then there's possibly exploits in the wild as well**


----------



## Jism (Jan 3, 2018)

Ok that's it. I'm downgrading all my servers back to Bulldozer CPU's.


----------



## Vya Domus (Jan 3, 2018)

Assimilator said:


> My speculation, however, is founded on knowledge of computer hardware



Highly debatable.


----------



## Flaky (Jan 3, 2018)

What about VIA? Nobody said they are vulnerable, but still suffer the impact from workaround-fix.
The patch should look more like "if (intel) then apply fix", rather than "if (not amd) then apply fix".


----------



## EarthDog (Jan 3, 2018)

Just report the posts instead of replying amd exacerbating the problem...

See what i mean? A self fulfilling prophecy of barbs allowed to continue after ' a hundred reports'.


----------



## TheoneandonlyMrK (Jan 3, 2018)

Flaky said:


> What about VIA? Nobody said they are vulnerable, but still suffer the impact from workaround-fix.
> The patch should look more like "if (intel) then apply fix", rather than "if (not amd) then apply fix".


A question worth asking what of qualcom too and the arm derivatives are they to be penalised for intels shoddy workmanship.


----------



## Jism (Jan 3, 2018)

Flaky said:


> What about VIA? Nobody said they are vulnerable, but still suffer the impact from workaround-fix.
> The patch should look more like "if (intel) then apply fix", rather than "if (not amd) then apply fix".



I dont think there are DC's working with VIA CPU's in general. VIA offers low performance / lower power CPU's with X86 yes but more suited for embedded systems. The patch goes mike tyson on every X86/X64 CPU basicly and harms performance depending on workload.


----------



## Assimilator (Jan 3, 2018)

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



jigar2speed said:


> You need to keep quiet sometimes. (we know you hate AMD) The new patch is already out that excludes AMD CPUs.
> 
> 
> __
> ...



1. I don't hate AMD or their CPUs. I do hate it when companies endorse their marketing teams' lies in order to sell products that they know are inferior (see: Bulldozer).
2. I prefer to source my infosec news from places other than anonymous and unverifiable Reddit comments, thanks.



Flaky said:


> What about VIA? Nobody said they are vulnerable, but still suffer the impact from workaround-fix.
> The patch should look more like "if (intel) then apply fix", rather than "if (not amd) then apply fix".



I doubt the VIA x86 marketshare is large enough for it to matter whether they're affected or not. In particular, i don't imagine you'll find many of their CPUs in datacenters...


----------



## Vya Domus (Jan 3, 2018)

I find it fascinating how this thread exploded even more than the Intel one from which this whole thing started.


----------



## R0H1T (Jan 3, 2018)

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 (Jan 3, 2018)

R0H1T said:


> 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 (Jan 3, 2018)

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 (Jan 3, 2018)

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 (Jan 3, 2018)

64K said:


> 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 (Jan 3, 2018)

AnnCore said:


> 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 (Jan 3, 2018)

ne6togadno said:


> 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 (Jan 3, 2018)

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


----------



## R-T-B (Jan 3, 2018)

notb said:


> 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 (Jan 3, 2018)

R-T-B said:


> 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 (Jan 3, 2018)

theoneandonlymrk said:


> 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 (Jan 3, 2018)

RejZoR said:


> 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 (Jan 3, 2018)

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 (Jan 3, 2018)

Assimilator said:


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



Everyone knows that repeater was sent out by Intel


----------



## Citizenx (Jan 3, 2018)

notb said:


> 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 (Jan 3, 2018)

jahramika said:


> Everyone knows that repeater was sent out by Intel


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


----------



## Patriot (Jan 3, 2018)

AnnCore said:


> 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 (Jan 3, 2018)

eidairaman1 said:


> 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 (Jan 3, 2018)

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 (Jan 3, 2018)

Gasaraki said:


> 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 (Jan 3, 2018)

Gasaraki said:


> 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 (Jan 3, 2018)

qubit said:


> 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 (Jan 3, 2018)

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 (Jan 3, 2018)

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.



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 (Jan 3, 2018)

btarunr said:


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



btarunr said:


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


I think your article needs to be updated.



Assimilator said:


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



theoneandonlymrk said:


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


----------



## TheoneandonlyMrK (Jan 3, 2018)

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


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 (Jan 3, 2018)

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 2000*s, 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 (Jan 3, 2018)

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.



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 (Jan 3, 2018)

Apparently someone could recreate the bug...


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


----------



## EarthDog (Jan 3, 2018)

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


----------



## ensabrenoir (Jan 3, 2018)

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 (Jan 3, 2018)

efikkan said:


> 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 (Jan 3, 2018)

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 (Jan 3, 2018)

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


----------



## R-T-B (Jan 3, 2018)

dicktracy said:


> 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 (Jan 3, 2018)

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.


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.


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 (Jan 3, 2018)

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.



Sooo...



behrouz said:


> Someone answered :
> 
> 
> __
> https://www.reddit.com/r/Amd/comments/7nqwoe/_/ds4qihg





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



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


----------



## R0H1T (Jan 3, 2018)

Not my area of expertise, but here you go ~ 



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


----------



## R-T-B (Jan 3, 2018)

theGryphon said:


> Sooo...
> 
> 
> 
> ...



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



R0H1T said:


> 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 (Jan 3, 2018)

R-T-B said:


> 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 (Jan 3, 2018)

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


----------



## R-T-B (Jan 3, 2018)

xorbe said:


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



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


----------



## xorbe (Jan 3, 2018)

R-T-B said:


> 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 (Jan 3, 2018)

xorbe said:


> 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 (Jan 3, 2018)

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.


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


----------



## R-T-B (Jan 3, 2018)

R0H1T said:


> 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 (Jan 3, 2018)

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


----------



## R0H1T (Jan 3, 2018)

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


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 (Jan 3, 2018)

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



xorbe said:


> 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 (Jan 3, 2018)

Hah, I know, I was making a joke.


----------



## notb (Jan 3, 2018)

qubit said:


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


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.


----------



## Sasqui (Jan 3, 2018)

I seriously doubt that the hit to AMD was intended, but who knows?  The law of unintended consequences?

My question is this:  Who here is affected by this kernel patch?  For example, I've got Win 7 running on an i7-4790k, does it hit me?  And how could you go about measuring the performance hit?


----------



## EarthDog (Jan 3, 2018)

Only time will tell... there are the 5-50% rumors out there.. I have heard of an academic workaround less than 1% and 30% for synthetic syscall loops too... who knows until its actually out there and tested.


----------



## hellrazor (Jan 3, 2018)

HTC said:


> How does one go about using it?
> 
> Though i'm now more familiar with Linux, this sort of thing is still out of my reach.


You can edit the kernel boot arguments by pressing 'e' when grub loads. I'm not sure if it'll be permanent that way, but if it isn't you can also edit /boot/grub/grub.cfg and put it in the arguments in each menuentry (in the line that looks something like linux /boot/vmlinuz-4.14.0-2-amd64 root=UUID=14c5fd8d-f9b1-4cf0-977c-da9a33337d15 ro quiet).

Also, it's pti=off now (for some reason).


----------



## Sasqui (Jan 3, 2018)

EarthDog said:


> Only time will tell... there are the 5-50% rumors out there.. I have heard of an academic workaround less than 1% and 30% for synthetic syscall loops too... who knows until its actually out there and tested.



*



			Intel Refutes Chip ‘Bug,’ ‘Inaccurate Media Reports’
		
Click to expand...

*
Pushback by Intel:  https://www.barrons.com/articles/in...15010736?mod=yahoobarrons&ru=yahoo&yptr=yahoo


----------



## EarthDog (Jan 3, 2018)

That link to barrons... I cannot see the article through the advertisement and not able to close it... lol wtf...lol


----------



## xorbe (Jan 3, 2018)

Just go straight to the source:
https://newsroom.intel.com/news/intel-responds-to-security-research-findings/
Talk about full firefight mode, and trying to drag everyone else down with you.


----------



## Sasqui (Jan 3, 2018)

EarthDog said:


> That link to barrons... I cannot see the article through the advertisement and not able to close it... lol wtf...lol



Yea, sorry - goto @xorbe 's link


----------



## Steevo (Jan 3, 2018)

It's only a problem till someone reads something they shouldn't, like your password, cc info, user id, bitcoin wallet, social security info, and other stuff just by leasing multiple servers from any number of large companies using Intel CPUs. 

This effects Intel and many ARM CPUs and only those.


----------



## TheoneandonlyMrK (Jan 3, 2018)

notb said:


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


As fine an example of Your type of post as could be made in an odd thread for it , i thank you for the chuckles ,is that All fact or your opinion? No dont reply im not interested at all in this off topic stuff and cannot be bothered writing an essay.


----------



## natr0n (Jan 4, 2018)

https://www.amd.com/en/corporate/speculative-execution


----------



## R0H1T (Jan 4, 2018)

natr0n said:


> https://www.amd.com/en/corporate/speculative-execution


So there's at least 3 (known) exploits, I wonder if Equifax & the recent Nicehash hack was also due to thus 

Multiple lawsuits incoming


----------



## EarthDog (Jan 4, 2018)

I thought they know what that issue was already?


----------



## R0H1T (Jan 4, 2018)

EarthDog said:


> I thought they know what that issue was already?


Was it?

Like I speculated earlier, this was known well before the KAISER (now kpti) patch & might possibly have been exploited in the wild. The BK Intel share selloff seems even more dubious now!


----------



## evernessince (Jan 4, 2018)

Assimilator said:


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



Dude, go troll somewhere else.  There's a reason you left out the link to the Linux devs testing results, it's because they tested old AF AMD A8 APUs.  They did not test Ryzen.  Hell even the older AMD A8 APU was only vulnerable to one while all Intel processors are vulnerable to all 3.


----------



## xorbe (Jan 4, 2018)

I think you've misread what Assimilator wrote.  He presented 2 possibilities, and was basically on point for what was known at the time.


----------



## Assimilator (Jan 4, 2018)

Okay, so the issue is actually that there are 2 separate issues: Meltdown, which is relatively trivial to exploit and only affects Intel CPUs due to a hardware flaw; and Spectre, which affects all CPUs, although being far more difficult to exploit. Presumably they got conflated somewhere along the line while the KAISER patches were being merged into the Linux kernel, leading to the Meltdown fix being applied to all x86 CPUs, but an additional kernel patch has now been accepted that disables PTI for AMD.

Intel's response to this is... well, bad. Terrible. S**tty. A lot of marketing handwaving and deflection, of the exact type I hate most, that uses a lot of words to say nothing, and certainly doesn't take responsibility. Given the seriousness of the issue, the fact that it can only be averted by a performance-crippling software patch or a (potentially performance-crippling) hardware redesign, they're looking down the barrel - but that doesn't excuse the fact that they aren't being mature about this.

What is most interesting to me is that according to the research, the Meltdown vulnerability has existed undetected for _quite literally decades_. I wonder how many three-letter government agencies have been exploiting it for all that time? And putting my conspiracy theorist hat on - I wonder if this is a backdoor that was purposefully built into Intel CPUs at the request of government agencies, similar to how various encryption algorithms were weakened/backdoored at the request of those same agencies?

Damn, this is biiig, and Intel's gonna bleed a lot before it's all over.


----------



## jadedcyborg (Jan 9, 2018)

This article is complete bullshit. An AMD rep submitted a patch excluding AMD from the Meltdown workaround and it was accepted immediately by Linus himself. Just look at the damn code. The exclusion is present in master.

https://github.com/torvalds/linux/blame/master/arch/x86/kernel/cpu/common.c#L926


----------

