Phoronix allready has done a a lot of benchmarks regarding this topic. https://www.phoronix.com/scan.php?page=article&item=linux-kpti-kvm&num=1

I would be carefully with the "won't be a problem for AMD" statement. In the first iteration of the patch all are affected. In the second iteration some changes will exclude some AMD cpus.
However the original security issue describes also attacks for AMD and ARM devices including nearly all Android phones. (iPhone/iPad?). Therefore i personally would deny your statment.

Overall the performance influcence is imho not worth to discuss about. For games usually in the arrea of messurement toloerances/faiulures.

What I'm wondering about is, that there is a security hole in nearly every CPU of the last decade that requires imedidate updates on all critical system (include nucelar power plants, trains, banking servers, stock exchanges, hospitals etc..) and instead of discussing how to efficiently patch critical infrastucture and how to get out patching hell people in forums discuss about minor performance impacts on realistic workloads instead of the risks not patching the systems.
This incident has the potential to turn down any cloud/containerized/virtualisation based business.

Instead of moarning we should be very thankfull towards the people spending the year-end-days to provide the patch.

BR
Mad

for desktops you can run pti=off with your boot options I doubt that i would be any less secure than running windows :P

For my servers tho.. I foresee meetings of the "pin the bill" variety in my near future :(

It's kind of amusing that they "just happen" to be able to use a 6 month old patch (KAISER) to fix the issue, when did google claim they discovered the problem again? ;)

Well, I have seen many estimates on various websites. It is highly dependent on how much interaction your programs have with the kernel. For things like databases, a slowdown of 25-30% is what I am reading. For games, 1-2% slowdown. The reason is that databases live on memory management, disk i/o, and internet connectivity which pass the data off to the kernel to process. Games on the other hand interact with mainly device drivers such as graphics card and input gamepad/mouse/keyboard. (Games essentially run in userspace, not kernelspace.)

As for AMD... It seems that there are two or more different attacks... For the "Meltdown" attack, it appears as if AMD is not vulnerable to this method. However, AMD *may* be vulnerable to "Spectre."

From Meltdown and Spectre website:

QuoteWhich systems are affected by Meltdown?

Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.

Which systems are affected by Spectre?

Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors.

Quoting: Guppyfor desktops you can run pti=off with your boot options I doubt that i would be any less secure than running windows :P

For my servers tho.. I foresee meetings of the "pin the bill" variety in my near future :(

It's kind of amusing that they "just happen" to be able to use a 6 month old patch (KAISER) to fix the issue, when did google claim they discovered the problem again? ;)

nopti
should work also

6 month old KAISER work, wasn't this done because of intel management engine security issues? the one that intel still havent patched yet afaik?

also i saw somewhere that this issue was reported in june or july this year already, but it was embargoed by intel to not cause any media fuss about it i guess.

anyway seems AMD, Intel and most of the ARM is affected with the smaller problem called "Spectre", which is super hard to patch out, but its also super hard to use it for hacks, because you need to guess the cpu first and flush some commands into it to get some info out of it and on top of that you need to get your code into the machine first. But the "Meltdown" is only Intel issue and this can be patched with the Page table isolation. That issue is also more insecure afaik, so the patches are rolling in for that.. Some ARM supposedly has this issue also, its the Branch predictor design those CPUs use.

Anyway it seems media made bigger fuss about it than the issue actually is. More testing needs to be done though, specially those older CPUs that doesnt have Process-Context Identifiers, aka CPUs before haswell iirc.

Quoting: g000hBig news today on CPU exploits. Intel CPUs, and to a lesser degree other CPU chips, have a major design flaw which can be exploited and it goes back through 10+ years of Intel processors. The flaw has practically zero effect on AMD CPUs.

It's yet to be seen if is has zero effect in AMD CPUs. Although they are immune to Meltdown they are not completely immune to some variants of Spectre.
Recently to my surprise Suse commit some patches to the kernel firmware to "disable branch prediction on Ryzen CPUs" (on their own words)
https://lists.opensuse.org/opensuse-updates/2018-01/msg00000.html

Some AMD PR guys are saying that the description is not correct.
There are a lot of speculation on reddit and other similar sites of what this patch actually does some say it just exposes the branch prediction to the kernel, some says that in only disables branch prediction for the kernel and others say it actually disables indirect branch prediction.
Someone on AMD needs to clarify this other than giving the standard marketing cheap chat.

On the other hand I've applied those Suse updates and I haven't seen any noticeable slowdown but I haven't done that much tests anyway.

4.14.11-1-ARCH kernel had my Ryzen smacked with cpu_insecure, now i got the update 4.14.12-1-ARCH which doesn't do that anymore. Spectre is still there i guess, but the variant AMD has (according to info found about it) seems it needs direct hardware access to be able to pull it of and then you have to guess how many cores your cpu has and what cpu you have to predict some numbers to get something meaningful out of this. Sounds more like a not a big issue anyway.

As for performance, might be placebo cause tests didn't reveal anything but i felt my desktop was a bit slower compared to usual speeds when my cpu was marked with cpu_insecure. Then again, no hard evidence, might be the Disk I/O thingy that took small hit with that.

After installing the Fedora 26 kernel that has patches for some of this stuff (4.14.11-200.fc26.x86_64), my system will not boot. Errors with nouveau in the output and lightdm fails to start. have to boot using an older kernel for Nvidia module to load. Verified the nvidia module was built for 4.14.11-200.fc26.x86_64 but it fails to load properly.

Quoting: Xpander4.14.11-1-ARCH kernel had my Ryzen smacked with cpu_insecure, now i got the update 4.14.12-1-ARCH which doesn't do that anymore. Spectre is still there i guess, but the variant AMD has (according to info found about it) seems it needs direct hardware access to be able to pull it of and then you have to guess how many cores your cpu has and what cpu you have to predict some numbers to get something meaningful out of this. Sounds more like a not a big issue anyway.

As for performance, might be placebo cause tests didn't reveal anything but i felt my desktop was a bit slower compared to usual speeds when my cpu was marked with cpu_insecure. Then again, no hard evidence, might be the Disk I/O thingy that took small hit with that.

to my understanding the spectre patches for AMD the only thing they do is throttle the syscalls to milliseconds instead of nanoseconds which make timed attacks take hours instead of minutes. Like someone said in another forum is like placing a big excavator to obstruct the entrance of a construction site while you go and build a real door. You are still left vulnerable because there are known javascript exploits and it's not uncommon to leave a webpage for hours on your web browser.

Quoting: XpanderAs for performance, might be placebo cause tests didn't reveal anything but i felt my desktop was a bit slower compared to usual speeds when my cpu was marked with cpu_insecure. Then again, no hard evidence, might be the Disk I/O thingy that took small hit with that.

Are you using an SSD? If so that would explain it. SSD writes took a nose dive.

Quoting: sr_ls_boy

Quoting: XpanderAs for performance, might be placebo cause tests didn't reveal anything but i felt my desktop was a bit slower compared to usual speeds when my cpu was marked with cpu_insecure. Then again, no hard evidence, might be the Disk I/O thingy that took small hit with that.

Are you using an SSD? If so that would explain it. SSD writes took a nose dive.

SSD yes, i now have the kernel that excludes the said fix from my ryzen cpu and everything feels back to normal.