SPECTRE and MELTDOWN: Bug rocks Intel / ARM CPUs

[segfaulted]

Kinda glad I bought AMD this round. For those who don't know there is a new bug affecting just about every SKU from Intel made in the last .. ohh.. _DECADE_ or so. It's actually worse then F00F or FDIV. Only mitigation appears to castrate the CPU upward of 30%! (depending on processes).

Can Asus confirm AMD and more importantly for me, this or any AMD motherboard are not affected? If so, will there be RMAs?

Fun fact, Intel's CEO dumped stock back in November before they started issuing gags on people from even talking about it.

*****ASUS advisory page(may get updated): https://www.asus.com/News/V5urzYAT6myCC1o2 ******

[iamthewizard2]

OK this is ridiculous! how long has this problem been going on? other brands have already released a bios update to fix the issue. My 6950X on A R5E board has been sitting at 3.5Ghz when it should be 4.5 since September!!!! that's 2 MONTHS! grrrrrrrrrr

[Brighttail]

So I went back and turned off the Retpoline and took some reading and then turned it back on and tried again.
I'm definitely seeing some improvement, which is nice. When Spectre first came out I personally lost about 30-35% speed on my 4k Q1 random read/writes. Looks like the new Retpoline gets me back 4-7%. 4k Q32 raised by roughly a 100Mb/s which is also nice. Sequential read/write stayed the same, about 800mb/s slower than what it was originally. Overall I probably won't be able to tell the difference in real time but it is nice to see that Retpoline has some effect and I can actually see the changes through benchmarks.

I will put the steps of what I did. These are my steps as the "add reg" line shown in the microsoft article above, didn't work for me and kept coming up with a syntax error. For this to work you need to have installed Microsoft update: KB4482887

So I went directly into the registry.

1. Enter registry and save. (in case you mess up)
2. Navigated to HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
3. Right clicked and ADD NEW DWORD (32BIT)
4. Renamed it to FeatureSettingsOverride
5. Double clicked the new registry entry and entered the hexidecimal value as 0x400
6. Right clicked and ADD NEW DWORD (32BIT)
7. Renamed it to FeatureSettingsOverrideMask
8. Double clicked the new registry entry and entered the hexidecimal value as 0x400
9. Restarted.

You can go to https://support.microsoft.com/en-us/help/4074629/understanding-the-output-of-get-speculationcontrols... in order to test it through powershell. Follow all the directions including the last to reset the values back to the originals after you get your read out. In the end you should see the following:

"BTIKernelImportOptimizationEnabled : True"

This will show that Retpoline is enabled. If at any time you have issues, restore your old registry. Once again this is how I did it. Your mileage may vary.


pre Retpoline

[pokuly]

When you also want to mitigate Speculative Store Bypass (SSBDWindowsSupportEnabledSystemWide : True) you have to use these values for the reg:
Tested with my i8700 Coffee Lake
"FeatureSettingsOverrideMask"=dword:00000403
"FeatureSettingsOverride"=dword:00000408

[Brighttail]

pokuly wrote:
When you also want to mitigate Speculative Store Bypass (SSBDWindowsSupportEnabledSystemWide : True) you have to use these values for the reg:
Tested with my i8700 Coffee Lake
"FeatureSettingsOverrideMask"=dword:00000403
"FeatureSettingsOverride"=dword:00000408

Does this give you any measurable increase in M.2 / SSD speed?

[pokuly]

Brighttail wrote:
Does this give you any measurable increase in M.2 / SSD speed?

If anything it decreases performance by a minimal amount since you mitigate another vulnerability.
CrytalDiskMark is pretty much the same with my RAMdrive and still by the same amount faster against non activated recent kernel changes.
The MS script outputs:

BTIHardwarePresent : True
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : True
BTIDisabledBySystemPolicy : False
BTIDisabledByNoHardwareSupport : False
BTIKernelRetpolineEnabled : False
BTIKernelImportOptimizationEnabled : True
KVAShadowRequired : True
KVAShadowWindowsSupportPresent : True
KVAShadowWindowsSupportEnabled : True
KVAShadowPcidEnabled : True
SSBDWindowsSupportPresent : True
SSBDHardwareVulnerable : True
SSBDHardwarePresent : True
SSBDWindowsSupportEnabledSystemWide : True
L1TFHardwareVulnerable : True
L1TFWindowsSupportPresent : True
L1TFWindowsSupportEnabled : True
L1TFInvalidPteBit : 45
L1DFlushSupported : True

[Brighttail]

Honestly I don't concern myself with SPECTRE too much. If I could disable all checks/precautions/fixes for it and gain back the original speed I would but alas we can't do that. So if it isn't going to impact performance I'll leave it as it is now. Thanks!

pokuly wrote:
If anything it decreases performance by a minimal amount since you mitigate another vulnerability.
CrytalDiskMark is pretty much the same with my RAMdrive and still by the same amount faster against non activated recent kernel changes.
The MS script outputs:

BTIHardwarePresent : True
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : True
BTIDisabledBySystemPolicy : False
BTIDisabledByNoHardwareSupport : False
BTIKernelRetpolineEnabled : False
BTIKernelImportOptimizationEnabled : True
KVAShadowRequired : True
KVAShadowWindowsSupportPresent : True
KVAShadowWindowsSupportEnabled : True
KVAShadowPcidEnabled : True
SSBDWindowsSupportPresent : True
SSBDHardwareVulnerable : True
SSBDHardwarePresent : True
SSBDWindowsSupportEnabledSystemWide : True
L1TFHardwareVulnerable : True
L1TFWindowsSupportPresent : True
L1TFWindowsSupportEnabled : True
L1TFInvalidPteBit : 45
L1DFlushSupported : True

[PerpetualCycle]

CDM with RAM cache isn't a good measure of anything.

[pokuly]

geneo wrote:
CDM with RAM cache isn't a good measure of anything.

It shows the performance hits of the mitigations pretty well so far with every change while for example audio encoding software reacts very different to the patches.

[PerpetualCycle]

Microcode is loaded into the processor by the BIOS. If an installed Microsoft update has a newer version of the Microcode than what was loaded by the BIOS, then Windows loads that updated Microcode into the processor early in the boot. If someone has the level of access to your system to alter the microcode, they already have enough access to do your system harm anyway.

You often do not get these microcode updates from Microsoft automatically through Windows Update - you need to fetch the update and install it manually. As mentioned, if you uninstall the microcode update, it won't be loaded and may leave you open to someone exploiting the vulnerability it protected against.

[R5Eandme]

geneo wrote:
Microcode is loaded into the processor by the BIOS. If an installed Microsoft update has a newer version of the Microcode than what was loaded by the BIOS, then Windows loads that updated Microcode into the processor early in the boot. If someone has the level of access to your system to alter the microcode, they already have enough access to do your system harm anyway.

You often do not get these microcode updates from Microsoft automatically through Windows Update - you need to fetch the update and install it manually. As mentioned, if you uninstall the microcode update, it won't be loaded and may leave you open to someone exploiting the vulnerability it protected against.

Thanks guys,

So then according to your comments re-flashing BIOS with an old, Spectre mitigated BIOS (vers 3902 for R5E), will not be detrimental to the more recent mitigations that are available from Windows update. That's what I needed to know.