OSDev.org

Hello OSDev,

I am developing a piece of software with major parts working in pre-boot in x86 real mode. It substitutes the MBR, does a lot of stuff including user interaction, install an int13h handler (yep, it is full disk encryption) and passes control on to the original MBR, boot loader and eventually OS kernel. My pre-boot functionality is pretty rich and is going to get richer, including network and USB support. We are already nearing the available real mode memory limit so protected mode would also be nice.

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.

So what can you advise as the best course of action here? Is there an open source project that can fit these requirement? Or maybe rolling out my own solution will be the best thing to do? Any comments are very welcome.

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.

There is already something that can do all this, and removes need to jump back to real mode and original MBR.

It's called (U)EFI.

The first challenge will be how to cooperate with "any OS".
All low memory region which your pre-boot code uses (including disk encryption) may be abuse/or overwritten by an undetermined OS.

Next, if the undetermined OS is:
1. real mode OS - what you do is extend the BIOS
2. protected mode/long mode - your INT13 hook is ignored.
That means your application is limited for real mode OS, in that case people tends to (1) load drivers after the OS boot instead of pre-boot, something like universal VBE driver over DOS; or (2) implement a V86 monitor to host the OS.

Griwes wrote:

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.

There is already something that can do all this, and removes need to jump back to real mode and original MBR.

It's called (U)EFI.

I am aware of that, but I need to support legacy bios machines.

bluemoon wrote:The first challenge will be how to cooperate with "any OS".
All low memory region which your pre-boot code uses (including disk encryption) may be abuse/or overwritten by an undetermined OS.

Next, if the undetermined OS is:
1. real mode OS - what you do is extend the BIOS
2. protected mode/long mode - your INT13 hook is ignored.
That means your application is limited for real mode OS, in that case people tends to (1) load drivers after the OS boot instead of pre-boot, something like universal VBE driver over DOS; or (2) implement a V86 monitor to host the OS.

OS that will boot from the encrypted disk is winnt and yes, there is also a driver for it. Int 13 hook is required so that the original OS can boot from the encrypted drive until it can load its own disk driver. Rich pre boot is required to implement other authentication schemes besides a simple password auth and possibly other features like data recovery.

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.

InsoReiges wrote:

Griwes wrote:

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.

There is already something that can do all this, and removes need to jump back to real mode and original MBR.

It's called (U)EFI.

I am aware of that, but I need to support legacy bios machines.

You don't *need*. And, you shouldn't want. BIOS is old. It's time for it to retire already. It's fine for 512 byte contests, but not as serious platform anymore, now that new machines already support (U)EFI.

Griwes wrote:

InsoReiges wrote:

Griwes wrote:There is already something that can do all this, and removes need to jump back to real mode and original MBR.

It's called (U)EFI.

I am aware of that, but I need to support legacy bios machines.

You don't *need*. And, you shouldn't want. BIOS is old. It's time for it to retire already. It's fine for 512 byte contests, but not as serious platform anymore, now that new machines already support (U)EFI.

It's not up to you to tell someone else what their requirements are.

If you can't answer the question, please don't reply. This is not a GNU newsgroup.

I think you are looking for CoreBoot. Little patch would be necessary for int 13h support, but the rest is quite straightforward.

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.

JamesM wrote:

Griwes wrote:You don't *need*. And, you shouldn't want. BIOS is old. It's time for it to retire already. It's fine for 512 byte contests, but not as serious platform anymore, now that new machines already support (U)EFI.

It's not up to you to tell someone else what their requirements are.

If you can't answer the question, please don't reply. This is not a GNU newsgroup.

Thank you.
Although i do agree personally that UEFI is a way to go my requirements are what they are - support deployed legacy systems.

turdus wrote:I think you are looking for CoreBoot. Little patch would be necessary for int 13h support, but the rest is quite straightforward.

Thank you! The first actual answer

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

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

Yep, so any other options?

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?