Windows 8 Instruction Cache

[Master674]

<something used to be here... its gone now>

[sitnspinlock]

perhaps it was left handicapped on purpose in that during a consumer preview they didn't expect consumers to be doing hefty debugging and/or running self modifying code. Are you applying the hook by writing instructions within the address space of the target process? WriteProcessMemory would indeed cause a flush anyway because it ends up calling MmCopyVirtualMemory which in turn calls KeStackAttachProcess (which would cause a flush because of mov to cr3, explained earlier).

whereas if you were modifying the instructions within the context of the process itself perhaps using only VirtualProtect (assuming the page was originally read/execute) to make it writeable you would need to do a manual flush because the TLB would still contain information from the previous translation.

[Cypher]

perhaps it was left handicapped on purpose in that during a consumer preview they didn't expect consumers to be doing hefty debugging and/or running self modifying code.

There's lots of legitimate applications which perform API hooking of some sort. I doubt they'd intentionally handicap their OS.

Some of the 'consumer' oriented software includes: Chrome (hooks APIs for increased security in the sandbox), Fraps (DX video recording), Afterburner (same as Fraps), AdMuncher (hooks winsock etc for ad blocking).

Also, doing 'hefty debugging' is exactly what I'd be expecting people (not mom and pop, but software developers) to do on the beta of a new OS.

Nevertheless, the RTM seems to be exhibiting the same problem.

Here is ntoskrnl.exe from Windows 8 RTM so you can check for yourself:
https://dl.dropbox.com/u/74751/rever...g/ntoskrnl.exe

[Cypher]

Necro-bumping this thread to provide some followup information. This was an intentional change in the kernel. The function is now a no-op on architectures with a coherent icache (i.e. x86 and x64, but not arm).