KB4100347 Intel microcode updates for Windows 10 v1803 - January 8 Win Update

andyouf said:

I understand you are doing it on purpose to avoid forced ucode updates and my question is essentially that but thought this was a unique situation for dimitris.

Earlier you had said "BIOS trumps MS patch. If your OEM patches your hardware, you just need the automatic OS updates" so I was confused. Anyway, will run the PowerShell script that @ddelo had laid out I had forgot about that. The link to instructions are now posted on the first page of this thread.

Have a good one.

'BIOS trumps MS patch' - as a way of fixing, if your OEM patches the uCode you don't need to wait for MS

If the OEM does NOT patch, then eventually the MS patches may contain newer uCode (in which case it overrides your BIOS uCode level). In 1809 the .dll is at the latest patch level for 1803 from the get go.

Yes, it was a specific instance for @dimitris123 and on my gaming machine, we require the BIOS level of uCode to be active, therefore we disabled the .dll

In most instances, the updated .dll is a good thing as 1803 was not at the same uCode update level as patched 1709 upon release (hence why the KB4090007 was released as KB4100347 for the newer version of W10). However, 1809 (and patched 1803 or 1709) are NOT at the INTEL uCode level (unless you have 1709 and KB4346084 or have a Skylake or newer CPU).

andyouf said:

Okay so you needed to retain BIOS level in order to be able to overclock for one thing, I see. Found what you mean by the Intel uCode not being same as OS level. Shows pre-mitigation MCU is 0x24 (what I'm at) and new production MCU is 0x25. See I had gotten updated to 0x24 by OS with KB100347. Then found the BIOS update with no notes except "Released to fix Spectre." I ran the script provided by @ddelo and results were:


This is what I was asking. OS and BIOS are both at 0x24, so is OS leaving BIOS alone in that regard? I ran the Speculation Control Script and finally got it to work without having to come to this site. I read the "Understanding" guide but still was confused. It would say if a parameter is True then I need to apply a BIOS update or get the January update? I just wanted to know what protections I had and if UEFI or OS level. List at the end looked at descriptions and will try to take in. Here is the output:

Code:

PS C:\WINDOWS\system32> Install-Module SpeculationControl
PS C:\WINDOWS\system32> Get-ExecutionPolicy -List

        Scope ExecutionPolicy
        ----- ---------------
MachinePolicy       Undefined
   UserPolicy       Undefined
      Process       Undefined
  CurrentUser    RemoteSigned
 LocalMachine    Unrestricted


PS C:\WINDOWS\system32> Set-Location C:\Windows\System32\WindowsPowerShell\v1.0\Modules
PS C:\Windows\System32\WindowsPowerShell\v1.0\Modules> Import-Module SpeculationControl
PS C:\Windows\System32\WindowsPowerShell\v1.0\Modules> Get-SpeculationControlSettings
For more information about the output below, please refer to https://support.microsoft.com/en-in/help/4074629
Speculation control settings for CVE-2017-5715 [branch target injection]

Hardware support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: True

Speculation control settings for CVE-2017-5754 [rogue data cache load]

Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: True
Windows OS support for PCID performance optimization is enabled: True [not required for security]

Speculation control settings for CVE-2018-3639 [speculative store bypass]

Hardware is vulnerable to speculative store bypass: True
Hardware support for speculative store bypass disable is present: False
Windows OS support for speculative store bypass disable is present: True
Windows OS support for speculative store bypass disable is enabled system-wide: False

Speculation control settings for CVE-2018-3620 [L1 terminal fault]

Hardware is vulnerable to L1 terminal fault: True
Windows OS support for L1 terminal fault mitigation is present: True
Windows OS support for L1 terminal fault mitigation is enabled: True


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

PS C:\WINDOWS\system32> Set-ExecutionPolicy Undefined -Scope LocalMachine

Execution Policy Change
The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose
you to the security risks described in the about_Execution_Policies help topic at
https:/go.microsoft.com/fwlink/?LinkID=135170. Do you want to change the execution policy?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "N"): a
PS C:\WINDOWS\system32> Get-ExecutionPolicy -List

        Scope ExecutionPolicy
        ----- ---------------
MachinePolicy       Undefined
   UserPolicy       Undefined
      Process       Undefined
  CurrentUser    RemoteSigned
 LocalMachine       Undefined

I apologize for the wall of text. Did I return the Execution Policy to the proper default/safe setting? I am the only user of this PC but want to make sure. Liked ddelo's command better that just does it for that PowerShell session.

I also read that INVPCID or PCID are useful for decreasing performance impact. Should I take a look or will that be way over my head/not worth it?

I read that disabling Speculative Store Bypass could be useful for CVE-2018-3639. It seems all I have left to do is change a registry value because June and uCode updates are installed. Don't know if this will further decrease performance of it is something I should just leave alone until a new MS or Intel patch comes out?

Last, is it okay to delete these modules and scripts for PowerShell now or just leave them? There was some service called NuGet installed in PackageMangager, sure that is part of PowerShell. I installed to System32 because could not get C:\ADV1008 to work even though I extracted there. Just want to delete that one module and then get out of there.

Import-Module took forever, I kept getting an error but could actually get the speculation results still. Finally did get Import-Module to work.

Yes the OS is leaving the BIOS alone as such (no newer uCode). All the Windows updates since January are Cumulative (regardless of version) and will have the OS patches for Meltdown / Spectre. Only Spectre variant 2 and variant 4 require uCode to be active.

A lot of the information you can read is outdated. Basically the MS patch level sits at sufficient for mitigation for variant 2 to be enabled. So, if you are on the list (Sandy Bridge upwards) you are mitigated by OS.

Variant 4 mitigation requires the newer uCode. OS level patching is sufficient if you use 1803 (or higher I assume) and are on the list (Skylake upwards).

INVPCID and PCID are only useful as a technique as a programmer / developer and hardware is Haswell or newer, so forget about it.

Your PowerShell script security levels are incorrect when you are not running the NuGet module. By default the security level is Undefined in the context of the CurrentUser. Ideally it would be Restricted or at least Undefined.

I have no idea why Import-Module should have taken a long time to work correctly, unless there was an error in setting the permissions, in the steps in ADV18002 I opted for A (Yes to All) instead of Y (Yes) but then I set the permissions back to Undefined rather than attempting to back up the current settings and restore them as suggested

Set-ExecutionPolicy Undefined -Scope CurrentUser

I know how easy it is to make silly typos when typing such unwieldly command line instructions

Yeah I kind of thought that the INVPICID thing was ridiculous. It does say in output

Windows OS support for PCID performance optimization is enabled: True [not required for security]

and

KVAShadowPcidEnabled : True

The second one it says is a performance optimization for kernel VA shadow, not security related also.

If variant 4 is 3639 I think I read that it is the least likely to pose a threat because the things it has to bypass are much more difficult (that sounds so dumbed down).

So if they release 0x25 (new uCode) it will be at the OS level and then that will replace all my BIOS uCode fully or supplement it? I doubt the OEM is going to release more BIOS updates.

I also opted for A instead of Y. Maybe "Remote Signed" was my issue. Says

RemoteSigned execution policy, which prevents you from running unsigned scripts that were downloaded from the Internet. It also shows how to use the Unblock-File cmdlet to unblock scripts, so that you can run them without changing the execution policy.

It did work once with ADV1802 but then I couldn't duplicate it. I remember a maddening "cmdlet" error amongst the red over and over for an inordinate amount of time. But then an MS script would be signed so it probably wasn't that at all. Tried to do C:\ProgramFiles\Windows\WindowsPowerShell\Modules but I couldn't get it to CD to Program Files. Doesn't matter. Should have just put on desktop.

Are you saying to change CurrentUser from RemoteSigned to Undefined as a default setting when I'm not messing with PS? Have everything restricted or undefined?

Yes these been some "very" unwieldy command lines I'm executing here.

andyouf said:

Yeah I kind of thought that the INVPICID thing was ridiculous. It does say in output and The second one it says is a performance optimization for kernel VA shadow, not security related also.

If variant 4 is 3639 I think I read that it is the least likely to pose a threat because the things it has to bypass are much more difficult (that sounds so dumbed down).

So if they release 0x25 (new uCode) it will be at the OS level and then that will replace all my BIOS uCode fully or supplement it? I doubt the OEM is going to release more BIOS updates.

I also opted for A instead of Y. Maybe "Remote Signed" was my issue. Says It did work once with ADV1802 but then I couldn't duplicate it. I remember a maddening "cmdlet" error amongst the red over and over for an inordinate amount of time. But then an MS script would be signed so it probably wasn't that at all. Tried to do C:\ProgramFiles\Windows\WindowsPowerShell\Modules but I couldn't get it to CD to Program Files. Doesn't matter. Should have just put on desktop.

Are you saying to change CurrentUser from RemoteSigned to Undefined as a default setting when I'm not messing with PS? Have everything restricted or undefined?

Yes these been some "very" unwieldy command lines I'm executing here.

I would say Undefined is better than RemoteSigned, because then there's the chance you will be required to act. Restricted might block silently. Not hard evidential proof for that, more a feeling seeing as there is a very good chance I wouldn't have gotten fingers dirty with PowerShell (I don't really like the Command Prompt, only venturing there when I have to) if it wasn't for Spectre. Why invent a GUI if you need the CLI? This is my main stumbling block issue with Linux to be fair; that and the rainbow of flavours....

ddelo said:

In PowerShell 4 and later, there is no actual need to run Import-Module. Once the new module is stored in a folder include in the $Env:PSModulePath, when you type a module command PowerShell imports the respective module, automatically, for the current session (either way, Import-Module, does the exact same thing, loads only for the current session)

Modules for All Users should be stored in %ProgramFiles%\WindowsPowerShell\Modules.

Modules for the Current User should be stored in %UserProfile%\Documents\WindowsPowerShell\Modules

According to Microsoft rules, the folder %windir%\System32\WindowsPowerShell\v1.0\Modules is used only for Microsoft system modules and it should not be used to install user defined modules.

More info on the subject, here

Okay thank you; all good information to know. And thanks for putting the import-module mystery to bed for me.

So this sucks.

I am trying to update a ASUS with i3-7100U to uCode 0x8E, clearly states this is contained within KB4346084, yet downloading the update (it was not offered on a clean install of 1803) saying that it is not applicable to my machine and that it is superceded by the 2018-09 KB4100347 which only contains 0x84 like the UEFI that I updated already.

This is one major f**k up by Microsoft. Some Kaby Lake and Coffee Lake CPUs are clearly not getting coordinated OEM/Vendor or Microsoft support. It kind of looks like Intel's house is in a royal mess.

winactive said:

So this sucks.

I am trying to update a ASUS with i3-7100U to uCode 0x8E, clearly states this is contained within KB4346084, yet downloading the update (it was not offered on a clean install of 1803) saying that it is not applicable to my machine and that it is superceded by the 2018-09 KB4100347 which only contains 0x84 like the UEFI that I updated already.

This is one major f**k up by Microsoft. Some Kaby Lake and Coffee Lake CPUs are clearly not getting coordinated OEM/Vendor or Microsoft support. It kind of looks like Intel's house is in a royal mess.

So it looks like this is why KB4100347 was re-issued in 2018-09, to 'rewind' some (possibly all) of the changes made by KB4346084.

But, I have been able to block KB4100347 with wushowhidediag.cab; not a perfect solution but it does at least enable 0x8E which I did manage to verify mitigated variant 4 when the registry settings from ADV18002 are applied.