I've got a curious question about how the Windows NT6 startup process works that doesn't seem to be explicitly stated in the docs I've read thus far. The most comprehensive one I've come across is here, and it's basically what I'm referring to.
I had used to think that "the big switch" from real to protected or long mode in the CPU was what prevented access to things like RAM disks created by bootloaders like GRUB4DOS or modules like MEMDISK and similarly invalidted BIOS INT handlers. However after reading that article, knowing that I've chainloaded bootmgr from RAM disks and from SAN via gPXE all via INT 13 hooks, and seeing that bootmgr itself contains code to switch the CPU out of real mode, I'm realizing that WINLOAD picks up an environment that's already in protected mode. From there, it uses BIOS INT 13 to drag things like the SYSTEM hive and HAL and the kernel up from the disk, and then it loads boot start drivers.
And then it enables paging (is this where drivers are required for further disk access?) and passes control to the kernel (and does the kernel require "protection" from a driver to not overwrite a RAM disk here?).
Once the kernel takes control, there's a small litany of processes that occur:
How Windows NT 6's kernel initializes
The Windows NT 6 kernel performs the usual Windows NT kernel initialization steps, that are largely unchanged from Windows NT version 3.1:
- Request the HAL to initialize the interrupt controller.
- Initialize the Memory Manager, the Object Manager, the Security Reference Monitor, and the Process Manager.
- Request the HAL to enable interrupts.
- Start all non-boot CPUs.
- Reinitialize the Object Manager.
- Initialize the "Executive".
- Initialize the "Microkernel".
- Reinitialize the Security Reference Monitor.
- Reinitialize the Memory Manager
- Initialize the Cache Manager.
- Initialize the Local Procedure Call system.
- Initialize the I/O Manager. Initialization of the I/O manager initializes all of the pre-loaded, "boot" class, device drivers.
- Initialize the Process Manager.
The operating system kernel then scans the registry, the in-memory copy passed to it by WINLOAD, for the configured device drivers. It loads and all of the device drivers that are in the "system" class.
The kernel checks the digital signatures of all of the image files from which it loads device drivers, using routines exported from ci.dll, the kernel-mode DLL that provides a set of "code integrity" library functions. (Much of the content of ci.dll is exactly the same cryptographic code that is statically linked into winload.exe, including the 8 hardwired Root Certification Authorities.)
The kernel finally invokes the first user process, the so-called Session Manager Subsystem (SMSS).
I'm assuming that at some point in here, if not before it, INT 13 access and non-driver-protected RAM disks become invalid. Was my earlier hypothesis correct, or is it when the HAL starts its own interrupt handling?
I'm super curious about this because I'm frankly fascinated by the way boot start drivers work and would like to start making a mess of some virtual machines with the Native API by pulling apart WinVBlock and Firadisk, but before I do, I'd like to get to know our good friend 0x7B a little better
Many thanks, and of course,
to the New Year -RulerOf
