loading code before th OS starts?

In TrueCrypt 5 I have seen that the bootloader loads the TrueCrypt driver to memory just before windows starts. First it seams a modified version of grub is starting, then the control is hand over to ntldr.

This was kinda wondering me. How does this work? Before I thought any kernel will keep control about anything he can get from the hardware. But if *anyone* can load whatever he wants to before the kernel is starting...

(I do NOT mean virtual hardware such as VMware or Virtualbox!) Wouldn`t it be possible to boot up first a full linux distro (such as Ubuntu) and then boot Windows directly?

Truecrypt is open source, read the code and find out.

Quote:

Originally Posted by sept

This was kinda wondering me. How does this work? Before I thought any kernel will keep control about anything he can get from the hardware. But if *anyone* can load whatever he wants to before the kernel is starting...

Truecrypt might be lying to Windows by manipulating the BIOS memory reports, causing Windows to believe that the region of memory where Truecrypt is located is not available for use. It's pretty simple actually.

Quote:

Originally Posted by sept

This was kinda wondering me. How does this work? Before I thought any kernel will keep control about anything he can get from the hardware. But if *anyone* can load whatever he wants to before the kernel is starting...

(I do NOT mean virtual hardware such as VMware or Virtualbox!) Wouldn`t it be possible to boot up first a full linux distro (such as Ubuntu) and then boot Windows directly?

Sure, you can load anything you like into memory, but if you want two different OS's to run at the same time, they need to be "managed" by something. Just loading ubuntu first, and then loading Windows won't solve the problem that BOTH ubuntu and Windows will think they own CR3 (Page-table Base address register in x86) for example. Modifying the E820 (BIOS memory setup table) will perhaps allow you to hide one OS from another, but there is still only one CR3 register, and whatever that is set to will need to match the currently running OS.

A virtual machine monitor (aka VMM or Hypervisor) (like in VMWare, Xen, Virtualbox etc) will intercept any attempt to modify CR3, and "track" these modifications.

The other problem you have is of course how to deal with "what memory belongs to which OS". A major part of Xen's Hypervisor is code to handle memory pages between competing OS's.

The next problem is "sharing" of hardware. You will presumably want both OS's to read from the hard-disk, but the hardware for the hard-disk has no inherent ability to tell which OS is accessing it. An IDE disk controller has 7 registers, and to do a single read or write, it is necessary to write to 5-6 of those registers, and then a sequence of 256 16-bit read/write operations to the "data register". If both OS's try to do this at the same time, all hell will break loose. So you need some sort of "sharing scheme". In a VM situation, the hypervisor will be responsible for hiding the real hardware, and performs the actual hardware access for the OS's that run on top of it [1].

[1] I only know how Xen does this, and it actually lets a particular OS own a particular PCI device, and any other OS needing to access that particular hardware will have to "talk through the owner", using a "device model" that runs on the OS owning the hardware, and using hypervisor inter-OS communication to communicate the data between the requestor and the HW owner.

--
Mats