Many CPUs will become up to 17% - 23% slower as of next weekend..
Can I not apply this patch? I'm careful with what I download and execute.
Windows will provide just one of its regular updates next Tuesday, Jan 10. You have to disable (if it is possible) the automatic procedure. On Win 7 one can do that on Win 10 home I have heard not.
The name of this update is not known yet..
Its not a matters :)
One might try to start a powershell prompt and enter:
gwmi win32_processor | select *
My (older) CPU shows this which has no CPUID - this seams to be the problem:
__GENUS : 2 __CLASS : Win32_Processor __SUPERCLASS : CIM_Processor __DYNASTY : CIM_ManagedSystemElement __RELPATH : Win32_Processor.DeviceID="CPU0" __PROPERTY_COUNT : 48 __DERIVATION : {CIM_Processor, CIM_LogicalDevice, CIM_LogicalElement, CIM_ManagedSystemElement} __SERVER : MYMSI __NAMESPACE : root\cimv2 __PATH : \\MYMSI\root\cimv2:Win32_Processor.DeviceID="CPU0" AddressWidth : 64 Architecture : 9 Availability : 3 Caption : Intel64 Family 6 Model 23 Stepping 10 ConfigManagerErrorCode : ConfigManagerUserConfig : CpuStatus : 1 CreationClassName : Win32_Processor CurrentClockSpeed : 2534 CurrentVoltage : 11 DataWidth : 64 Description : Intel64 Family 6 Model 23 Stepping 10 DeviceID : CPU0 ErrorCleared : ErrorDescription : ExtClock : 267 Family : 193 InstallDate : L2CacheSize : 12288 L2CacheSpeed : L3CacheSize : 0 L3CacheSpeed : 0 LastErrorCode : Level : 6 LoadPercentage : 8 Manufacturer : GenuineIntel MaxClockSpeed : 2534 Name : Intel(R) Core(TM)2 Extreme CPU Q9300 @ 2.53GHz NumberOfCores : 4 NumberOfLogicalProcessors : 4 OtherFamilyDescription : PNPDeviceID : PowerManagementCapabilities : PowerManagementSupported : False ProcessorId : BFEBFBFF0001067A ProcessorType : 3 Revision : 5898 Role : CPU SocketDesignation : CPU 1 Status : OK StatusInfo : 3 Stepping : SystemCreationClassName : Win32_ComputerSystem SystemName : MYMSI UniqueId : UpgradeMethod : 15 Version : VoltageCaps : Scope : System.Management.ManagementScope Path : \\MYMSI\root\cimv2:Win32_Processor.DeviceID="CPU0" Options : System.Management.ObjectGetOptions ClassPath : \\MYMSI\root\cimv2:Win32_Processor Properties : {AddressWidth, Architecture, Availability, Caption...} SystemProperties : {__GENUS, __CLASS, __SUPERCLASS, __DYNASTY...} Qualifiers : {dynamic, Locale, provider, UUID} Site : Container :
I would be interested in the results of newer CPUs.
On Linux one could enter this on the console: cat /proc/cpuinfo
One might try to start a powershell prompt and enter:
My (older) CPU shows this which has no CPUID - this seams to be the problem:
I would be interested in the results of newer CPUs.
On Linux one could enter this on the console: cat /proc/cpuinfo
Forgive my ignorance on this subject, namely the Intel CPU flaw, but what is the purpose of running the powershell script and why is "CPUID" relevant?
I took that from a German discussion forum about that flaw, there one said that cpu with that have that flaw.
Anyway here one will do some performance tests and those who are interested can download a test program for their own test (free for 30 days).
1) all Intel CPUs of the last 10 years are currently affected. If PCID is supported, the speed loss is lower.
2) As of January 2011, the standard Intel feature flags are as follows: https://en.wikipedia.org/wiki/CPUID
3) You need Haswell or newer (i. e. from Core ix 4xxx): https://patchwork.kernel.org/patch/10035481/
The PCID feature (from Sandybridge) alone is not enough, quote:
"PCIDs are generally available on Sandybridge and newer CPUs. However,
the accompanying INVPCID instruction did not become available until
Haswell (the ones with "v4", or called fourth-generation Core). This
instruction allows non-current-PCID TLB entries to be flushed without
switching CR3 and global pages to be flushed without a double
MOV-to-CR4.
Without INVPCID, PCIDs are much harder to use.
So, for now, fully disable PCIDs with KAISER when INVPCID is not
available. This is fixable, but it's an optimization that can be
performed later."
4) The Linux-patch seems to make no difference, it matches all x86:
- /* 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); fpu__init_system(c);
- 2018.01.03
- Gooly Newbie Join Date: Jan 2018 Posts: 1
- www.passmark.com
I took that from a German discussion form about that flaw, there one said that cpu with that have that flaw.
Anyway here one will do some performance tests and those who are interested can download a test program for their own test (free for 30 days).
1) all Intel CPUs of the last 10 years are currently affected. If PCID is supported, the speed loss is lower.
2) As of January 2011, the standard Intel feature flags are as follows: https://en.wikipedia.org/wiki/CPUID
3) You need Haswell or newer (i. e. from Core ix 4xxx): https://patchwork.kernel.org/patch/10035481/
The PCID feature (from Sandybridge) alone is not enough, quote:
"PCIDs are generally available on Sandybridge and newer CPUs. However,
the accompanying INVPCID instruction did not become available until
Haswell (the ones with "v4", or called fourth-generation Core). This
instruction allows non-current-PCID TLB entries to be flushed without
switching CR3 and global pages to be flushed without a double
MOV-to-CR4.
Without INVPCID, PCIDs are much harder to use.
So, for now, fully disable PCIDs with KAISER when INVPCID is not
available. This is fixable, but it's an optimization that can be
performed later."
4) The Linux-patch seems to make no difference, it matches all x86:
Some new findings:
Now Google has published the details (and also AMD is affected)
The Executive Summary
One. There are two attacks, Meltdown and Spectre.
2. Meltdown only affects Intel, KPTI helps against it.
Spectre concerns everyone, it's still unclear what helps.
4. research is far from over.
5. so far Intel, especially Haswell, has been the focus.
For successful attacks you have to find out details of the hardware's functionality.
Meltdown is Intel-specific.
It is the "simple" attack, and only against that KAISER/KPTI helps. AMD is not affected by this. But every Intel CPU since Pentium Pro, with the exception of the first In-Order atoms.
Spectre also affects ARM and AMD and potentially even more (POWER was mentioned). As already suspected, it is based on https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/
KPTI does not help against this. You can access any memory of other processes or the kernel. It is a universal "Heartbleed", and even works with Javascript.
A combination of microcode updates and new compiler options is under discussion. Yes, you have to recompile everything, so a lot of software will be affected until you have new CPUs.
So far only ARM speaks plain text (although "The majority of arm processors are not impacted" is nonsense from the end user's point of view - almost all Android devices should be affected):
https://developer.arm.com/support/security-update
Edit: some links...
https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html
https://spectreattack.com/spectre.pdf
Intel:
https://newsroom.intel.com/news/intel-responds-to-security-research-findings/
Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.
Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively.
A good description seems to be here.
Probably the name of the patches:
Win7:
https://www.catalog.update.microsoft.com/Search.aspx?q=KB4056897
Win8.1:
https://www.catalog.update.microsoft.com/Search.aspx?q=KB4056898
Win10(is already distributed):
https://www.catalog.update.microsoft.com/Search.aspx?q=KB4056892
Win7 and 8 will get the patch only next Tuesday.
There are 2 gaps and one of them concerns all processors:
The link to the paper:
The second gap is much worse because it affects all modern processors and probably can only be fixed by exploit on the software side. Everyone can imagine it for cloud data. This is the safety engineering "Super-GAU" (GAU = maximum likely accident).
Good night and good luck
- 2017.07.28
- Anders Fogh
- cyber.wtf
Just imagine many high speed trading server would become 30% slower...
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Well it sounds horrible for those who want to test, who want to provide their PC for others to test and who have VPS!
"The Register" writes about:
"'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign
Other OSes will need an update, performance hits loom".
The problem is a "flaw in the Intel x86-64 hardware, and it appears a microcode update can't address it."
It seems that developers of Windows and Linux are about to provide a fix which slows down the CPU up to 17%-23% around Jan 10.!
So it might be quite interesting if some perform a personally standardized (back)test now or before and after the upcoming update and post the comparison of the performance here incl. the CPU they have.
Unfortunately there is no list of the CPUs that are problematic just x86-64.