As the Linux patch for the Intel kernel issue is somewhat more mature than the Windows patch which was just pushed out, and because the patch may have more impact on hosting solutions than gaming machines, we turn to Phoronix for test results. Their testing overview looks at both Intel and AMD, as the PTI patch can be installed on AMD systems and it is not a bad idea to do so. The results are somewhat encouraging, CPUs with PCID (Process Context ID) such as Sandy Bridge and newer seem to see little effect from the patch, network performance seems unchanged and Xeon's see far less of an effect across the board than desktop machines. That is not to say there is no impact whatsoever, in synthetic benchmarks which make frequent system calls or depend on optimized access to the kernel they did see slowdowns; thankfully those workloads are not common for enthusiast software. Expect a lot more results from both Windows and Linux over the coming weeks.
"2018 has been off to a busy start with all the testing around the Linux x86 PTI (Page Table Isolation) patches for this "Intel CPU bug" that potentially dates back to the Pentium days but has yet to be fully disclosed. Here is the latest."
Here are some more Processor articles from around the web:
- Testing Windows 10 Performance Before and After the Meltdown Flaw Emergency Patch @ TechSpot
- 2nd-Gen Core i7 vs. 8th-Gen Core i7: RIP Sandy Bridge @ Techspot
- Intel Core i7 8700k @ Modders-Inc
- Ryzen Mobile Finally Arrives: AMD Ryzen 5 2500U @ Techspot
- Intel Core i9-7900X 3.3 GHz @ TechPowerUp
- The Best CPUs: This is what you should get @ Techspot
Why is it a good idea to turn
Why is it a good idea to turn on the Intel flaw patching on AMD Zen processors ?
Google and AMD claim AMD is not affected. Its even in the linux kernel patch notes.
Even AMD seem to suffer less (6% compilation performance drop on Intel 4% on AMD) AMD user dont need to supper this 4% drop in performance.
The same should be true on windows for software developers.
4K IO drop by ~30% on ALL intel processors with the safe OS updates.
This is why compilation drop by ~6% on Intel workstations.
Anyways, when all OS are patched for work around this flaw… this is a HUGE HACK to go around this Intel architectural flaw.
ALL benchmarks need to be re-run. Specially the one that are IO heavy.
“Why is it a good idea to
“Why is it a good idea to turn on the Intel flaw patching on AMD Zen processors ?”
Because it’s not an ‘intel flaw patch’.
The patch is a mitigation for a whole new class of exploits, that include Meltdown, Spectre, and likely many others that will now be discovered. AMD CPUs are not vulnerable to Meltdown, but are vulnerable to Spectre. Turn the patch off at your own peril.
The spectre attack works
The spectre attack works between two user processes, Google’s BTB poisoning attack breaks virtualization containment.
Either way, KPTI does bigger all AFAICS.
This is not true. The kernel
This is not true. The kernel patch only mitigates Meltdown, not Spectre. No AMD CPU is known to be vulnerable to Meltdown, but almost all Intel CPUs since 1995 are. See https://spectreattack.com/
So it is not far fetched to call it an ‘Intel flaw patch’.
“Their testing overview looks
“Their testing overview looks at both Intel and AMD, as the PTI patch can be installed on AMD systems and it is not a bad idea to do so.”
Why is it “not a bad idea to do so” on AMD systems? I’d rather have the performance hit not affecting AMD at all and it looks like some are still trying to make it appear that it’s a good thing to force on AMD also when AMD is not affected by the one problem that Intel is affected by.
What about antivirus scans they have a whole lot of I/O requests has anyone done any windows before and after anticirus scans and meauured the difference. What about windows system image backups that’s the whole drive/partitions backed up and how much extra does that add on to the process pre and post Windows OS patching.
I’m not as concerned about the other issues that may affect more than Intel’s CPUs as that is just more noise to distract away from Intel and its poor CPU Micro-Arch based design decision!
Edit: anticirus scans and
Edit: anticirus scans and meauured
To: antivirus scans and measured
Funny how, when a
Funny how, when a vulnerability that can lead to full system compromise has a Microsoft patch that is incompatible with endpoind defense (AVs for now) in a near global variant spread scenario…
I wonder why the patch has a malware kind signature?
Is it Microsoft’s turn for the feast now?
You know how they are, always late…
re: “why run pti=on for
re: “why run pti=on for AMD”
Because these are just the opening shots in a new class of attacks here, it’s quite likely there will be additional vulnerabilities coming along over the next couple months. There is virtually no impact on the desktop, and will be quite modest even for real-world server tasks, so it’s simply better to play it safe at this point in time.
(and no, running SELECT 1; over the loopback interface isn’t a real-world server task)
i don’t read, so fuck you in
i don't read, so fuck you in advance
You caught us, that is
You caught us, that is totally the only explanation. It couldn't be that there may be more than three vulnerabilities nor that a different infection could set an AMD processor into the untrust mode which does make it vulnerable to one of the Spectre issues.
Not to mention, if AMD is not affected by the vulnerability then why the hell would it be slowed down by the patch? But hey, you want to block that update, go right ahead.
Why not patch for Meltdown in
Why not patch for Meltdown in a different patch and not allow Intel for force its mistakes onto AMD/others concerning only Meltdown by including any of the spectre vulrenability patches along with the Meltdown patches.
And really Jemery Your Understanding of OSs and Context-Switching overhead/Speculative execution is not there with that “if AMD is not affected by the vulnerability then why the hell would it be slowed down by the patch?” statment!
If you patch the ketnel to fully seperate the OS Kernel Address space from the User/Application Addres space in the page tables/cache subsystems then the patched kernel is going to be slow for all processores regardless of the Hardware. So Even AMD’s non-Vulrenable CPUs are going to be forced to do that resource intensive FUCKWIT trampoline extra overhead nonsence.
Did you not understand what Linus was saying over at the linux kernel forum/mailing list when he chided Intel on that very subject.
AMD is not affected by Meltdown because AMD’s CPU core hardware checks every speculative branch fetch to make sure that any user-space to kernel space speculative branching does not violate the Kernel-Space to User-Space domain transition before any speclutive prefetching is done. AMD’s CPUs will not allow the speculative fetching across user-mode to Kernel-Mode in the first place as far as meltdown is concerned.
Intel has been playing fast and loose with security and the proper user-mode to kernnel-mode domain checking just to get a little more IPC/Performance over the decades and AMD’s CPU cores do the propper checking and AMD has to now suffer a performace hit because of some unreated spectre typse of patches that do not belong in with the OS meltdown focused patch/s! Go ask Linus what he thinks of that!
Until there is PoC for any AMD meltdown vurenability why force AMD’s CPUs to suffer from Intel’s Nefarious disregard for user security all these years!
Normally I would inquire as
Normally I would inquire as to how making an AMD processor do what it already does would create measurable impact but from the tone of your writing I can tell it would be futile.
The current theory is that
The current theory is that AMD checks access rights early in the pipeline, how is that the same thing as trashing the TLB?
By making it twice.
I know.
By making it twice.
I know. This one’s a hard ball.
Jeremy,
Being a long time
Jeremy,
Being a long time viewer of PCPer, I’m positively sure you guys will re-bench all of your bar charts with patched Intel CPUs against equivalent non forcebly slowed down AMD ones.
Do it fast to be first!
Please stop bringing up
Please stop bringing up spectre … this is a meltdown patch.
Spectre will if possible have to be fixed with microcode patches to wipe the BTB on context swaps and ideally new instructions to do the same after sandboxed scripting language exit. In the future BTB entries should be process ID tagged.
Could there be other ways to leak kernel memory if it remains mapped, sure. There could also be other ways to leak kernel memory with speculative execution which we don’t even know about. If we just want to get paranoid we could make a x86 simulator which runs each instruction in deterministic amount of time. Slowing down AMD for an exploit which doesn’t exist even theoretically makes as much sense.
While tech sites willfully
While tech sites willfully regurgitate Intel’s PR statements that AMD is equally affected, financial site surprisingly aren’t falling for it.
https://www.forbes.com/sites/kenkam/2018/01/04/amd-looks-poised-to-gain-at-intels-expense/
Obviously why I included that
Obviously why I included that exact statement in my news posts … oh wait, that's only in your imagination.
Not sure what the disconnect
Not sure what the disconnect is here. You should not enable the meltdown patch on AMD hardware since it is reducing performance for no reason. AMD chips already prevent speculation across a user and kernel space boundary. Mapping kernel memory into user space processes was a performance optimization to allow system calls without a full context switch. The patch removes this optimization by not mapping kernel memory into some area of user space process. Every system call will include the overhead of a context switch.
So, since 1995 an IPC clearly
So, since 1995 an IPC clearly flawed Intel advantage has been around and noone knew it was exploitable? Even with client-side javascript?
Since you guys and Intel’s CEO seem to like a good joke, here goes one:
~ Intel Airlines ~
“Dear passengers, thank you for choosing an Intel flight. This is a recording of your captain speaking. If you care to look to the left wing, you might be able to notice that engine 1 and 3 stoped working. Also, if you feel like looking through the right windows, you will notice that we are now flying over the ocean, in wich you can see a small red spot, which is a lifeboat, from where me personaly and some of my crew wish you a remaining pleasant flight.”
Hope you laugh.
But don’t forget to also dump your Intel stock! Don’t come crying that you didn’t have inside info when it came from *the man* himself!
The thing is even windows
The thing is even windows patch is out if your bios not updated (probably ll most never get) patch doesn’t activate
see
https://support.microsoft.com/en-us/help/4073119/protect-against-speculative-execution-side-channel-vulnerabilities-in
here what you’ll get
https://i.imgur.com/wHvwKBE.png
Looking at the screenshot:
–
Looking at the screenshot:
– CVE-2017-5754 (Meltdown, the Intel/ARM HW issue) has the mitigation patch in place.
– CVE-2017-5715 (Spectre, affecting pretty much all CPUs) needs work on both firmware/microcode side as well as further fixes on software side of things.
Can anyone confirm if there’s
Can anyone confirm if there’s any impact to MS SQL Server for Windows? Given the comment from the podcast that PostgreSQL has slowed down performance issues.
~~~ How to NOT forcebly slow
~~~ How to NOT forcebly slow down AMD CPUs due to heavily entrenched Intel partnership comercial interests and stock holding media actors, by changing only 2 Bytes on Linux. ~~~
Status:
——-
/* Assume for now that all x86 CPUs are insecure */
setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
if (c->x86_vendor != X86_VENDOR_AMD)
setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
Solution:
———
/* Assume for now that all x86 CPUs are insecure
setup_force_cpu_bug(X86_BUG_CPU_INSECURE); */
if (c->x86_vendor != X86_VENDOR_AMD)
setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
… in CPU/common.c
You’re welcome.
NOTE: Microsof users must shut up and eat it, though.
~~~ For SPECTRE ~~~
To
~~~ For SPECTRE ~~~
To mitigate the biggest attack surface (Inet javascript, aprox. 80% of it), just open sensitive sites isolated in another browser instance/process.
AND
Follow links to sensitive sites with “Open in another window” context popup menu (why do you think they’re there in the first place?).
… for now.
You’re welcome.
… also,
If you like
… also,
If you like researching, find the article about early exploitation of the now called SPECTRE vulnerability made by Google/Youtube, back in 2012/3.
The site was downyours.org (currently offline).
PS: Want another joke?
Oh boy…
The new bill/law(?)
Oh boy…
The new bill/law(?) of ceasing all assets to whom commited ***human rights abuse*** is surely starting to smoke all rats out now.