OSDev.org

Hi,

turdus wrote:

Owen wrote:Erm... CoreBoot is a firmware replacement. This is not going to solve your problem...

Yes, of course it's a firmware replacement, what'd you expect an "advanced pre-boot platform" to be?

The problems with firmware replacement is that there's far too many motherboards, and most people aren't willing to accept the risk/s - even if the motherboard is supported properly (and the new firmware doesn't just brick the system) you'd probably end up with no way to revert the changes or install a normal OS later.

It is possible to implement some sort of pre-boot platform on top of existing/standard firmware; including implementing a UEFI layer on top of "legacy BIOS", or a BIOS layer on top of UEFI, or anything else on top of anything else. In this case (which in my opinion is the only practical case), the advanced pre-boot platform is in software (not in firmware).

InsoReiges wrote:What i am having in mind due to all of this is adopting some kind of advanced pre-boot platform, a mini OS or something similar which can boot, provide network and usb support, protected mode, run a single application in privileged mode, install int13h handler, switch back to real mode and run original MBR. Before i am going to start to roll my own using some libraries or digging into linux kernel i would like to get some advice from people who are familiar with OS and boot loader development.

If it's designed for general use (e.g. you're expecting many OS's to support it), then it just increases the number of different pre-boot execution environments that OS's would need to handle and makes things worse. If it's designed for one specific OS, then it's probably better to do it later in the boot process - e.g. boot loaders that support BIOS or UEFI or whatever and put the system into a standard state, followed by the OS's remaining boot code that relies on that "standard state". Of course this wouldn't be "pre-boot" anymore.

InsoReiges wrote:

bluemoon wrote:

InsoReiges wrote:OS that will boot from the encrypted disk is winnt and yes, there is also a driver for it.

I'm not familiar with WinNT startup procedure but if WinNT decide to read additional file after enter protected mode and before loading your driver, you're screwed.

No, not really. NT bootloader uses int13h to read the kernel image from the disk. After that the kernel initializes its storage system and loads my disk driver which publishes a block device and begins servicing requests transparently decrypting them. Any file system drivers are of course loaded after that since the whole kernel subsystem only sees this disk after i publish it as a disk driver.

This isn't an "advanced pre-boot platform", but a third-party extension of Microsoft's existing boot code to add transparent support for encryption that Windows (and all the viruses that have infected it) can use.


Cheers,

Brendan