What is causing my computer to BSOD at random times?

Hello vivs_lunchtime,

To set your mind at rest regarding xsaveremovefeature, when I looked at the (assembly) code of KiInitializeXSave/KiInitializeXSaveConfiguration (name depends on Windows version) to see what influences the initialization of SharedUserData.XState.EnabledSupervisorFeatures, I saw that the routine calls KiParseLoadOptions and that one of the strings used was XSAVEREMOVEFEATURE

0:000> u KiParseLoadOptions+0x49 l 1

ntoskrnl!KiParseLoadOptions+0x49:

0000000140b1cab9 488d1520810100 lea rdx,[ntoskrnl! ?? ::OKHAJAOM::string' (00000001`40b34be0)]

0:000> da 1`40b34be0

00000001`40b34be0 "XSAVEREMOVEFEATURE"

Regarding KiUserCetAllowed: that is set in KiSetControlEnforcement. A static analysis suggests that the top of the stack looks like this:

KiSetControlEnforcement

KiInitializeKernel

KiSystemStartup

Gary

PS: setting KiUserCetAllowed must have happened earlier than nt!KiInitializeKernel. I stopped too late.

In other words, all people that previously got murdered by the nameless (and incompetent) shellcode can now use the hardcore override and leave Core Isolation's Memory Integrity's protection, and have the shellcode running without murder part. But don't complain when your (ndis) routines get overwritten afterwards by something and you get critical kernel corruption. (I still wonder about that ndis-overwrite part, btw. It happened only to Alex as far as I know, not to all the others with shellcode.)

I finally found an own laptop with a new enough CPU, because I wouldn't want to do somewhat dangerous experiments on a friends computer.

I can positively ack empirically the following:

"xsaveremovefeature 0x800" hardcore removes the cr4 bit in full, KiUserCetAllowed will be zero. This happens before ntoskrnl "really" starts, at boot time. (I was boot-debugging.) It is truly a handy hardcore override. The cr4.CET bit will be gone, all shadow stack protection will be gone, no matter what the user has set in control panel. And I think it works just with admin rights, e.g., it does not require disabling secure boot or similar things. (Obviously I can't verify that, because kernel debugging requires secure boot off.)

As I did not know the revert command for the esoteric "xsaveremovefeature 0x800" (hey, I still wonder where Gary got that from), I used bcdedit export/import option, as you can see in my proof of concept:

kb 

 # RetAddr               : Args to Child                                                           : Call Site 

00 fffff801`3cd2b6ca     : fffff801`36b78c00 fffff801`383955e0 00000000`00000004 00000000`00000004 : nt!DbgBreakPointWithStatus
01 fffff801`3cc74057     : fffff801`36b78c00 fffff801`36b78c00 00000000`00000001 fffff801`3cf4c6c0 : nt!InitBootProcessor+0x536 
02 fffff801`3cc71279     : fffff801`3fb70000 00000000`00000000 00000000`00000003 fffff801`38395ba0 : nt!KiInitializeKernel+0x417
03 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemStartup+0x269 

!process -1 0 

PROCESS fffff8013cf48f40 

    SessionId: none  Cid: 0000    Peb: 00000000  ParentCid: 0000 

    DirBase: 001ae000  ObjectTable: 00000000  HandleCount:   0. 

    Image:  
(we are at boot and the OS isn't initialized yet)

db nt!KiUserCetAllowed L1 

fffff801`3cf1c061  01 

r cr4 

cr4=0000000000b50ef8 

db nt!KiUserCetAllowed L1 

fffff801`3cf1c061  01 

===  

bcdedit /export "c:\temp\bcdstorebackup" + 
bcdedit /set xsaveremovefeature 0x800 + 
reboot

===  

db nt!KiUserCetAllowed L1 

fffff805`0b11c061  00    

r cr4 

cr4=0000000000350ef8 

Binary:  00000000 00000000 00000000 00000000 00000000 00110101 00001110 11111000 

Bit 23 (Intel CET bit) is off. 

===  

bcdedit /import "c:\temp\bcdstorebackup" + reboot

===  

Reboot runs into a little bit scary bcd error (??), followed by immediate auto-reboot, 
and then a normal boot (with success and restored configuration).*

* This did not happen on a later second attempt. 

r cr4 

cr4=0000000000b50ef8 

Binary:  00000000 00000000 00000000 00000000 00000000 10110101 00001110 11111000 

Bit 23 (Intel CET bit) is set again.

Hello vivs_lunchtime,

I think that everyone can use the xsaveremovefeature 0x800 option; when used, XSTATE_CET_U in SharedUserData.XState.EnabledSupervisorFeatures will not be set and the CET flag in CR4 will not be set. Any feature that depends on CET will not be enabled.

In Alex's original configuration, XSTATE_CET_U and CR4.CET were set. A "side-effect" of setting CR4.CET (i.e. not being able to clear CR0.WP) caused (presumably) PatchGuard to crash the system.

According to the Intel manual, CET provides two capabilities: Shadow Stack and Indirect Branch Tracking.

For brevity, in the following text I have omitted all of my usual "I think/believe" qualifications.

Starting from Windows build 19041, user-mode shadow stack "functionality" is enabled for all threads. I put "functionality" in quotes because what actually happens is dependent on a number of factors, including:

1. Whether the DLL has the IMAGE_DLLCHARACTERISTICS_EX_CET_COMPAT mark (all Microsoft Windows DLLs should have this flag set).
2. Whether SetProcessMitigationPolicy(ProcessUserShadowStackPolicy, ...) has been called (to change default behaviour).

If DLLs marked with IMAGE_DLLCHARACTERISTICS_EX_CET_COMPAT behave correctly, there should be no easily observable impact of the user-mode shadow stacks. There may be some visible indications of shadow stack activity in the Microsoft-Windows-Security-Mitigations event log.

KiUserCetAllowed does not "govern" kernel-mode shadow stacks - it just reflects the setting of CR4.CET. If KiUserCetAllowed is not set then CET is not available and kernel-mode shadow stacks can't be used; as you mentioned, there are also other prerequisites for kernel-mode shadow stacks.

I earlier wrote:

if KiUserCetAllowed then set bit CET in CR4

KiUserCetAllowed is set if SharedUserData.XState.EnabledSupervisorFeatures has bit 11 (0x800) (XSTATE_CET_U) set

KiInitializeXSave initializes SharedUserData.XState.EnabledSupervisorFeatures (combines CPUID information with BCD information)

The order of the text matches how I came to the information:

Search the code in ntoskrnl looking for writes to CR4; check if CET is possibly being set and, if so, what influences the decision (e.g. value of KiUserCetAllowed).

Search the code in ntoskrnl looking for modifications of KiUserCetAllowed and what determines the value set (e.g. value of SharedUserData.XState.EnabledSupervisorFeatures).

Just one further search was needed to see that the CPUID instruction and BCD determined the value of SharedUserData.XState.EnabledSupervisorFeatures.

I think that "bcdedit /deletevalue xsaveremovefeature" should "undo" the bcdedit test but, like you, I have not dared to try it.

Gary