More Intel leaks.. this one is not good though

[Fetzie]

4 hours ago, AluminiumTech said:

nope. All OSes supporting Intel x86-64 CPUs are affected.

 

Only things not affected are any AMD CPUs, ARM CPUs, Power CPUs, or any non Intel CPUs.

Linux is getting an update for its ARM distributions: https://lwn.net/Articles/740393/

[AlTech]

1 minute ago, Fetzie said:

Linux is getting an update for its ARM distributions: https://lwn.net/Articles/740393/

Yeah but it's not necessary for them to. They're doing it now for ARM to avoid any possible scenario like that with ARM. Not because ARM is specifically affected (because only Intel's implementation of x86-64 is affected).

[Fetzie]

@DoctorWho1975 here is a link to the whitepaper on the changes to the Linux Kernel to prevent this issue: https://gruss.cc/files/kaiser.pdf

[hishnash]

2 hours ago, mr moose said:

At the end of the day if this is as bad as it seems, then you can bet your arse they didn't do it on purpose and had they known earlier they would have been looking to fix it before anyone found out. So in all likelihood the very last generation or two would not have the bug.

 

Given how complex these processors are becoming (which is why it is so hard for new players to enter the game), it is not beyond reason that it was a genuine oversight. Hopefully they find a decent fix soon.   

The only fix it to fall back to OS level checks on every single access to memory, that means every time any prosses needs to read/write to memory your CPU needs to switch tasks back to the kernel to run the check then switch back again... there is no way to patch this on a chip level. 

also, it is unlikely that any intel chips coming out in the next year (or maybe 2) will have fixes either since this is quite a low-level fault and that needs a lead time to fix.

[A_Mediocre_Kangaroo_Farmer]

Boy am I glad I just dropped all my cash into an 8700k rig..

[Tannah]

Interesting, Apparently 10 days ago a Linux proposed a commit targeted at all X86 processors to fix this issue. AMD has since requested to be excluded from the bug patch. But it has not been accepted yet. They erred on the side of caution, but I'm it looks like its going to be a bit before AMD is excluded from the patch in Linux.

 

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/998707-initial-benchmarks-of-the-performance-impact-resulting-from-linux-s-x86-security-changes

[jagdtigger]

Ugh, this is really nasty. Its a good thing that i decided to take the plunge and build my home server with ryzen...

[porina]

4 hours ago, yian88 said:

https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2

 

R.I.P Intel  2018.1.3

dayum boi the performance hit is real with current patch, until properly fixed (if ever) this will erode intel's rep and market away quickly

https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-Initial-Gaming-Tests

Gaming tests (under Linux) don't show any change, so gamers rejoice!

 

 

4 hours ago, NumLock21 said:

Only way to save is to throw every Intel computer away and buy AMD.

Yay, more cheap used Intel kit for me  Ryzen just isn't competitive for my compute uses.

 

I will await the Windows patch for my own testing. If the performance drop is more than 5%, I will probably be forced to run non-patched OS on the farm, and only have one fully patched system for internet stuffs. On the plus side, no more WindowsUpdate crap to deal with either, which I've already had to take the path of blocking at network level. Performance >> vague potential security risk.

[Jinchu]

5 hours ago, AluminiumTech said:

Only things not affected are any AMD CPUs, ARM CPUs, Power CPUs, or any non Intel CPUs.

Still the changes in the Linux kernel effect all x86 processors. So even if AMD processors are going to take the performance hit regardless if they are vulnerable in the first place or not.

[Jinchu]

43 minutes ago, porina said:

https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-Initial-Gaming-Tests

Gaming tests (under Linux) don't show any change, so gamers rejoice!

 

 

Yay, more cheap used Intel kit for me  Ryzen just isn't competitive for my compute uses.

 

I will await the Windows patch for my own testing. If the performance drop is more than 5%, I will probably be forced to run non-patched OS on the farm, and only have one fully patched system for internet stuffs. On the plus side, no more WindowsUpdate crap to deal with either, which I've already had to take the path of blocking at network level. Performance >> vague potential security risk.

The code change in the Linux kernel does not make any difference between Intel and AMD processors

[jagdtigger]

2 minutes ago, Jinchu said:

The code change in the Linux kernel does not make any difference between Intel and AMD processors

Not yet... They already applied for it(someone posted the article already).

[ionbasa]

3 minutes ago, Jinchu said:

The code change in the Linux kernel does not make any difference between Intel and AMD processors

AMD is trying to petition that the fix not affect AMD CPUs. May or may not happen. ARM64 is also getting KAISER implemented regardless of vulnerability. Seems everyone is  playing on the safe side for the time being.

[Stefan Payne]

10 hours ago, SC2Mitch said:

Any word on what families will be affected, Skylake, etc?

With the way they are behaving and making this Fix OPT OUT with some serious argument, probably everything since Core.

 

What seems to be the consensus is that everything since Westmere has this bug - but only because that was the oldest thing they could find.

So right now you can not say that Core 2 Duo and Pentium M also does or does not have this issue.

[mr moose]

2 hours ago, ravenshrike said:

That still leaves the amount of time after they taped out Kaby Lake(since a Covfefe/Cannon are effectively shrinks of the same architecture with the mesh memory modification) for them to have found out about it. 

 

but they didn't. 

1 hour ago, hishnash said:

The only fix it to fall back to OS level checks on every single access to memory, that means every time any prosses needs to read/write to memory your CPU needs to switch tasks back to the kernel to run the check then switch back again... there is no way to patch this on a chip level. 

also, it is unlikely that any intel chips coming out in the next year (or maybe 2) will have fixes either since this is quite a low-level fault and that needs a lead time to fix.

For now the only known fix is that. 

[Princess Luna]

57 minutes ago, porina said:

.

Yeah I am personally not worried one bit, to begin with Microsoft has an absurd higher budget and team to work on fixes that won't hit performance and secondly there is awfully a lot of over reaction by every one in here when we still have no real numbers to compare any thing other than very vague and loosen claims.

 

This feels like that Hyper-Threading issue we had with Skylake and Kaby Lake processors recently, every one made a hella lot of fuzzle about it said every one should disable Hyper-Threading at once to avoid security exploits and all... what happened afterwards? nothing life move on with all working accordingly.

 

I won't be worried until more reliable articles with actual data, or even better myself when I come across the first Windows patch test it for myself what are the performance true hits in Coffee Lake and depending if I feel my processor is getting too alike with a Ryzen processor I'll just run the unpatched windows revision, not really all that concern about something that has been there for 10 years and has caused little to no issues till today.

[David Vt]

https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-EPYC-Linux-4.15-Test

[hishnash]

1 minute ago, Princess Cadence said:

 

I won't worried until more reliable articles with actual data, or even better myself when I come across the first Windows patch test it for myself what are the performance true hits in Coffee Lake and depending if I feel my processor is getting too alike with a Ryzen processor I'll just run the unpatched windows revision, not really all that concern about something that has been there for 10 years and has caused little to no issues till today.

 

https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2

anything that hits the kernel will have a big impact, tasks that load all memory into user space then work on it or read large chunks (aka rendering etc) will not have such an impact.

remember the kernel does not only manage the file system it also manages networking so expects to see the same impact on that.

With respect to the impact of the bug, know it is known (as soon the details of how to use it will be widely known) it will be used a lot since getting access to kernel memory means you can do all sorts of fun things like inspecting all (even encrypted) network traffic without any user noticing   and you virus just needs to run in user space so no admin passport prompts etc.

>  not really all that concern about something that has been there for 10 years and has caused little to no issues till today.

that is since it was no known.

[Princess Luna]

Again as I have literally just addressed, Linux ain't Windows.

 

Good practices as I have I hardly think I have what worry myself, gotta get infected somehow first, and I personally haven't had a single malware issue in forever, not making little deal of it but I still see all this story as far too farfetched and exaggerated.

[ionbasa]

1 minute ago, Princess Cadence said:

Again as I have literally just addressed, Linux ain't Windows.

 

Good practices as I have I hardly think I have what worry myself, gotta get infected somehow first, and I personally haven't had a single malware issue in forever, not making little deal of it but I still see all this story as far too farfetched and exaggerated.

You do realize that both Intel and AMD have devs that are paid to strictly work on Linux kernel dev and patches? They also have the same outreach for both Microsoft and Apple. The catch all fix for MS should happen patch tuesday. 

Anything I/O heavy will take a hit in performance.

[porina]

19 minutes ago, ionbasa said:

AMD is trying to petition that the fix not affect AMD CPUs. May or may not happen. 

Without being a kernel programmer, I don't know the complexity in having a code split between affected and non-affected CPUs. As much as it sucks for AMD should this be forced, it might be the case the cost of maintaining two codepaths for this has been deemed not worth the effort compared to having a universal solution going forwards. If anyone has a large invested stake in AMD CPUs, they could fork it and regain their performance.

13 minutes ago, Princess Cadence said:

This feels like that Hyper-Threading issue we had with Skylake and Kaby Lake processors recently, every one made a hella lot of fuzzle about it said every one should disable Hyper-Threading at once to avoid security exploits and all... what happened afterwards? nothing life move on with all working accordingly.

From memory, that was more a stability issue than a security one. Fortunately the conditions for it were rare enough I doubt anyone outside those doing exactly the same thing as those discovering it were affected. Similarly, there was a Ryzen bug also discovered when doing certain compile actions, that got fixed after a certain manufacturing date. I have two Ryzens, both of which were bought at launch and thus would also be affected. Am I bothered? No. Rumour has it AMD will replace on demand affected CPUs, but I don't see it as worth the time.

 

The difference here is that it is a security bug. Exploits may be developed to take advantage of it now it is widely known. If enough systems get patched, maybe that will devalue the exploit enough they do not become commonplace. It may also be a risk that exploits are combined, for example, the recent ME bugs may remain unpatched in a significant proportion of systems due to requiring flashing, and allow access below OS level to work around OS level patching. A big if, but not impossible for a sufficiently motivated attacker (e.g. state sponsored). Then again, you'd have to be a sufficiently interesting target for it, in which case this is probably not your biggest problem.

[ionbasa]

12 minutes ago, porina said:

Without being a kernel programmer, I don't know the complexity in having a code split between affected and non-affected CPUs. As much as it sucks for AMD should this be forced, it might be the case the cost of maintaining two codepaths for this has been deemed not worth the effort compared to having a universal solution going forwards. If anyone has a large invested stake in AMD CPUs, they could fork it and regain their performance.

...

Actually, it's already possible to avoid PTI on AMD CPUs. It can be forced turned off with a kernel flag at bootup. An AMD dev is waiting for merge of kernel code to not force PTI on AMD CPUs. It's a simple logical operator that checks if the CPU is Intel or AMD. Kinda Ironic that someone from Intel (Dave Hansen) has to approve the merge request 

 

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

[Smoofie]

So, any Americans feel like suing Intel if the loss  in performance is great enough :P? Even though Intel most likely didn't hide this fact, it is still at fault for what's likely some performance drops in cloud services and if I read it right, also for things like Blizzard WoW servers.

[LAwLz]

5 minutes ago, porina said:

Without being a kernel programmer, I don't know the complexity in having a code split between affected and non-affected CPUs. As much as it sucks for AMD should this be forced, it might be the case the cost of maintaining two codepaths for this has been deemed not worth the effort compared to having a universal solution going forwards. If anyone has a large invested stake in AMD CPUs, they could fork it and regain their performance.

It's not difficult. They just need to check the CPU ID and then set some flags depending on the ID. They already do it with several things such as how to handle SMT in Ryzen, and I believe the modules in Bulldozer.

[jagdtigger]

https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-EPYC-Linux-4.15-Test

Quote

 

Right now with the big mysterious security vulnerability causing the rush of the x86 Page Table Isolation work that landed in the Linux kernel days ago, it's believed to be a problem only affecting Intel CPUs. But at least for now the mainline kernel is still treating AMD CPUs as "insecure" and is too taking a performance hit.

 

Quote

An immediate workaround at least until the AMD patch lands where PTI isn't applied to AMD CPUs is by booting the kernel with the nopti kernel command-line parameter. This can also be applied to Intel systems too on a patched kernel if wanting to regain the performance and are not too concerned about this vulnerability.

 

[Vode]

If Intel lobbies for AMD CPUs getting the same „fix“ I‘m gonna shove my X99 mobo up Krzanichs butt. ?