Efforts to boot Win10 22H2

[mochaaP]

Tracker for booting 19045.4xxx builds:

• Could not read CM_KEY_INDEX_ROOT
• Hang/crash on KiSystemStartup
• ???

---

Could not read CM_KEY_INDEX_ROOT

hive->EnumKeys reports EFI_INVALID_PARAMETER: fixed

diff --git a/src/reg.cpp b/src/reg.cpp
index 693fdfa..7268db4 100644
--- a/src/reg.cpp
+++ b/src/reg.cpp
@@ -150,6 +150,7 @@ static EFI_STATUS EFIAPI enum_keys(EFI_REGISTRY_HIVE* This, HKEY Key, UINT32 Ind
     CM_KEY_NODE* nk;
     CM_KEY_FAST_INDEX* lh;
     CM_KEY_NODE* nk2;
+    UINT32 _idx = Index;
     bool overflow = false;
 
     // FIXME - make sure no buffer overruns (here and elsewhere)
@@ -189,18 +190,40 @@ static EFI_STATUS EFIAPI enum_keys(EFI_REGISTRY_HIVE* This, HKEY Key, UINT32 Ind
 
     lh = (CM_KEY_FAST_INDEX*)((uint8_t*)h->data + 0x1000 + nk->SubKeyList + sizeof(int32_t));
 
-    if (lh->Signature != CM_KEY_HASH_LEAF && lh->Signature != CM_KEY_FAST_LEAF)
+    if (lh->Signature == CM_KEY_INDEX_ROOT) {
+        CM_KEY_INDEX* ri = (CM_KEY_INDEX*)lh;
+
+        for (size_t i = 0; i < ri->Count; i++) {
+            CM_KEY_FAST_INDEX* _lh = (CM_KEY_FAST_INDEX*)((uint8_t*)h->data + 0x1000 + ri->List[i] + sizeof(int32_t));
+            if (_lh->Signature == CM_KEY_INDEX_ROOT) {
+                // Do not recurse: CVE-2021-3622.
+                print_string("Reading nested index is not implemented yet\n");
+                return EFI_INVALID_PARAMETER;
+            } else if (_lh->Signature != CM_KEY_HASH_LEAF && _lh->Signature != CM_KEY_FAST_LEAF) {
+                return EFI_INVALID_PARAMETER;
+            }
+
+            if (_lh->Count > _idx) {
+                lh = _lh;
+                break;
+            }
+
+            _idx -= _lh->Count;
+        }
+    }
+
+    else if (lh->Signature != CM_KEY_HASH_LEAF && lh->Signature != CM_KEY_FAST_LEAF)
         return EFI_INVALID_PARAMETER;
 
     if ((uint32_t)size < sizeof(int32_t) + offsetof(CM_KEY_FAST_INDEX, List[0]) + (lh->Count * sizeof(CM_INDEX)))
         return EFI_INVALID_PARAMETER;
 
-    if (Index >= lh->Count)
+    if (_idx >= lh->Count)
         return EFI_INVALID_PARAMETER;
 
     // find child key node
 
-    size = -*(int32_t*)((uint8_t*)h->data + 0x1000 + lh->List[Index].Cell);
+    size = -*(int32_t*)((uint8_t*)h->data + 0x1000 + lh->List[_idx].Cell);
 
     if (size < 0)
         return EFI_NOT_FOUND;
@@ -208,7 +231,7 @@ static EFI_STATUS EFIAPI enum_keys(EFI_REGISTRY_HIVE* This, HKEY Key, UINT32 Ind
     if ((uint32_t)size < sizeof(int32_t) + offsetof(CM_KEY_NODE, Name[0]))
         return EFI_INVALID_PARAMETER;
 
-    nk2 = (CM_KEY_NODE*)((uint8_t*)h->data + 0x1000 + lh->List[Index].Cell + sizeof(int32_t));
+    nk2 = (CM_KEY_NODE*)((uint8_t*)h->data + 0x1000 + lh->List[_idx].Cell + sizeof(int32_t));
 
     if (nk2->Signature != CM_KEY_NODE_SIGNATURE)
         return EFI_INVALID_PARAMETER;

---

Hang/crash on KiSystemStartup

Hang on debug builds, crash on release builds.

TODO: attach windbg / gdb to QEMU?

[xproot]

I don't know if this helps but I found out in #109 that

• 1609 LTSB doesn't boot if the partition is still NTFS
• 1609 LTSB doesn't boot if it's been fully updated, don't know what specific update does this but I know it's a new one.
  I can't get 1809+ booting but I can get 1507 and 1609 booting just fine.

[mochaaP]

Will try to boot a WCOS image / PE once I have time to

[mochaaP]

Also @maharmstone - any insights?

[maharmstone]

Thanks for this - let me double-check your Registry patch and read the CVE, and I'll push it.

I am 90% sure that the problems with the later versions of Windows 10 are due to Spectre / Meltdown mitigations, which for some reason require memory to be laid out in a certain way, but only kick in on certain CPU / mobo combinations. I think there's a flag to disable these entirely, which we probably should be setting.

[maharmstone]

Pushed as 7402412, thanks!

[mochaaP]

I think there's a flag to disable these entirely, which we probably should be setting.

Is it in the loader block or registry? I couldn't find Spectre / Meltdown mentions (symbols & string) in ntoskrnl.exe, only memory management ones.

[maharmstone]

I think in the loader block, but it's been a long time since I looked at this. Quite possibly the name of the flag isn't documented.

[xproot]

Thanks for this - let me double-check your Registry patch and read the CVE, and I'll push it.

I am 90% sure that the problems with the later versions of Windows 10 are due to Spectre / Meltdown mitigations, which for some reason require memory to be laid out in a certain way, but only kick in on certain CPU / mobo combinations. I think there's a flag to disable these entirely, which we probably should be setting.

Would this do it?
https://www.grc.com/inspectre.htm

[mochaaP]

Some probably interesting symbols:

• KiInitializeBootStructures
• KiSpeculationFeatures
• KiDetectTsx
• KiAddSpecCtrlSsbdBit
• KiIs....Mitigation...

[mochaaP]

@xproot Could you pinpoint the exact ntoskrnl executable that fails to boot? I might be able to bindiff those two executables before and after the update to get some hints.

[kristibektashi]

Thanks for this - let me double-check your Registry patch and read the CVE, and I'll push it.

I am 90% sure that the problems with the later versions of Windows 10 are due to Spectre / Meltdown mitigations, which for some reason require memory to be laid out in a certain way, but only kick in on certain CPU / mobo combinations. I think there's a flag to disable these entirely, which we probably should be setting.

I don't know if it's a good idea to disable these mitigations (at least not by default, perhaps it could be an option?) since they are meant to protect against serious hardware vulnerabilities

[mochaaP]

This bootloader is NOT FOR PRODUCTION. Do not use this for anything serious.

[mochaaP]

@xproot https://winbindex.m417z.com/?file=ntoskrnl.exe
u could try some luck here :)
filter to w10 1607 and do a manual bisect based on file signing date.

[xproot]

Oh btw, sorry for being inactive on testing btrfs, my computer setup has completely changed. I'll try this tomorrow.

[xproot]

Oh btw, sorry for being inactive on testing btrfs, my computer setup has completely changed. I'll try this tomorrow.

It is now tomorrow. But instead of trying this I have tried installing Quibble in real hardware. HP 245 G2 with an AMD E1-2100 APU, installing Windows 10 Enterprise LTSC 2021, then installing WinBtrfs, then converting C: to btrfs, then booting with Quibble was pretty painless.

I am not sure why when I booted from Quibble it started claiming my install is 2009.

[maharmstone]

Awesome!

I am not sure why when I booted from Quibble it started claiming my install is 2009.

I wish I knew this too. As far as I could make out, on the later versions of Windows 10 it became the bootloader's responsibility to report the marketing name of the OS version to the kernel, for whatever reason. If it can't find it, it defaults to "2009".
My guess is that Microsoft use it internally to display the Git hash, something like that. I never looked into it too closely because it's only cosmetic.

[xproot]

I spoke to someone in a Discord server, they claimed Windows 10 20H2 and the following Windows 10 versions were all just 2004 with "enablement updates" that labeled them as newer. (talking about a screenshot I sent)

it's reading off of the deprecated ReleaseId rather than DisplayVersion all it takes to revert LTSC to its real form is just force uninstalling

KB5003791 which should be there (pointing to a screenshot about Windows Server 2022)

this is the real 21H2 aka 20348 but still, the deprecated ReleaseId value

is still 2009 Anyways I think this just goes to show that there's some odd behaviour occurring under Intel hosts that prevents Quibble from booting versions newer than 1507 and 1609 *without an update I haven't identified*