Windows 10: KB4100347 Intel microcode updates for Windows 10 v1803 - September 13

Page 42 of 43 FirstFirst ... 3240414243 LastLast
  1.    1 Week Ago #410

    andyouf said: View Post
    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).
      My ComputersSystem Spec

  2.    1 Week Ago #411

    winactive said: View Post
    '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).
    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:
    SocketDesignation : U3E1
    UpgradeMethod : Socket LGA1150
    CPUID : 000306C3

    BIOS/UEFI microcode revision : 0x24
    Current microcode revision : 0x24
    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.
    Last edited by andyouf; 1 Week Ago at 04:53.
      My ComputerSystem Spec

  3.    1 Week Ago #412

    andyouf said: View Post
    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
      My ComputersSystem Spec

  4.    1 Week Ago #413

    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.
      My ComputerSystem Spec

  5.    1 Week Ago #414

    andyouf said: View Post
    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....
      My ComputersSystem Spec

  6.    1 Week Ago #415

    I don't want silent blocks rather know what is going on so if RemoteSigned and Restricted or going to do silent going to just set everything to Undefined. Agreed on needing a CLI with the GUI. Nicer to use. Main stumbling block with Linux is that it is still CLI only or that the GUI is really plain? Yes so many versions.
    Last edited by andyouf; 1 Week Ago at 07:49.
      My ComputerSystem Spec

  7.    1 Week Ago #416

    winactive said: View Post

    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
    In PowerShell 4 and later, there is no actual need to run Import-Module. Once the new module is stored in a folder included 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
    Last edited by ddelo; 1 Week Ago at 16:52.
      My ComputerSystem Spec

  8.    1 Week Ago #417

    ddelo said: View Post
    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.
      My ComputerSystem Spec

  9.    1 Week Ago #418

    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.
      My ComputersSystem Spec

  10.    1 Week Ago #419

    winactive said: View Post
    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.

    Click image for larger version. 

Name:	spectre8e.png 
Views:	3 
Size:	92.5 KB 
ID:	207736
      My ComputersSystem Spec


 
Page 42 of 43 FirstFirst ... 3240414243 LastLast

Related Threads
Source: https://support.microsoft.com/en-us/help/4091666/kb4091666-intel-microcode-updates See also: KB 4093836 Summary of Intel microcode updates KB4100347 Intel microcode updates for Windows 10 v1803 - Windows 10 Forums KB4090007 Intel...
Source: https://support.microsoft.com/en-us/help/4091664/kb4091664-intel-microcode-updates See also: KB4346087 Intel microcode updates for Windows 10 v1607 - August 21 - Windows 10 Forums See also: KB 4093836 Summary of Intel microcode...
Source: https://support.microsoft.com/en-us/help/4091663/kb4091663-intel-microcode-updates See also: KB4346085 Intel microcode updates for Windows 10 v1709 - August 21 - Windows 10 Forums See also: KB 4093836 Summary of Intel microcode...
Source: https://support.microsoft.com/en-us/help/4090007/intel-microcode-updates See also: KB 4093836 Summary of Intel microcode updates KB4100347 Intel microcode updates for Windows 10 v1803 - Windows 10 Forums KB4091663 Intel microcode...
Solved Intel microcode updates for 1803? in Drivers and Hardware
Is this available for download?
Our Sites
Site Links
About Us
Windows 10 Forums is an independent web site and has not been authorized, sponsored, or otherwise approved by Microsoft Corporation. "Windows 10" and related materials are trademarks of Microsoft Corp.

© Designer Media Ltd
All times are GMT -5. The time now is 17:56.
Find Us