OSDev.org

Greetings,

Although I'm not a particularly inexperienced OSdever, I'm a bit uncertain about what choice would be best in my situation. I was hoping some of you would be able to help me out. Basically, I've got an idea of a custom encrypted filesystem I'd like to implement for my newest OS project, and lots of other 'nonstandard' stuff, but don't know whether it would be smartest to start with GRUB or build a custom bootloader from the beginning.

One the one hand, building everything from scratch ensures I don't have to deal with that nasty "oh, right, Grub doesn't do that kind of thing" in the middle of my work. There's also the fact that I'm specifically building this to work on MY computer, so I don't have to worry a whole lot about any of those compatibility issues (CPU advanced features, here I come!) On the other hand, given that I've got ideas for modifications for a LOT of things, it might also be smart to just start with Grub, and maybe move to a more customized solution later if necessary. This also makes it easier not to go mad because of the insane amount of technical design I'm trying to hold in my head at a single point. Generally speaking, which approach do you think would be most cost-efficient, and would be most likely to lead to the least amount of head-banging-against-a-wall?

Thanks.
muCF

Well, you might want to take a look at my experimental "maggot" bootloader project.
It may be simple for you to customize it to suit your needs. If you enhance it, I'd be happy to have some extra code added to the project (it is stubbed and incomplete in many ways). It is trivial to add support for a new filesystem to it. It supports 2, ATM.
There is a tarball and a zipfile here (with a nice long readme file):
http://www.quokforge.org/projects/rebochs/files

The code should be pretty trivial to comprehend. I use this bootloader for my own OS project, so as my own OS progresses I will certainly be doing further work on maggot.

Hi,

muCF wrote:Basically, I've got an idea of a custom encrypted filesystem I'd like to implement for my newest OS project, and lots of other 'nonstandard' stuff, but don't know whether it would be smartest to start with GRUB or build a custom bootloader from the beginning.

When an OS first starts up, at some point control is passed from the boot loader to something else. This "something else" might be the kernel itself, but it might be some sort of "boot abstraction layer" or "kernel setup module" or a HAL or anything else. For the sake of simplicity, and because I can't think of a good name for it, I'm going to refer to the thing that the boot loader passes control to as "FOO".

When an OS first starts up, at some point control is passed from the boot loader to FOO.

Now; my recommendation is to write a (formal?) specification that describes this control transfer. The specification needs to cover things like:

• What state should the CPUs be in? Should it be in real mode or protected mode or long mode; should specific values be in specific registers; should interrupts be disabled; should... What about AP CPUs (will they be started, or waiting to start, or..)?
• What should the address space look like? Should A20 be enabled, should paging be enabled; should various files and/or data structures be at specific addresses (and if so, which addresses), etc.
• What state should the rest of hardware be in? Will interrupt controllers be in a certain state, can FOO assume PCI devices are configured, will each video card be using a video mode (and which one), etc.
• What information will the boot loader gather and how will that information be passed to FOO? The memory map, a list of possible video modes, a "boot log", any end-user configuration (script? variables list? command line string?), firmware provided tables (ACPI, MP spec, SMBIOS), some sort of boot loader and/or boot device identification, etc.
• Will the boot loader provide an API that FOO can use? If yes, what is this API used for, where is the entry point, what is the calling conventions?

You'd also want to think about portability - will your specification cover other architectures (ARM?), and other types of firmware (UEFI?).

Once you've decided exactly what you want; then take a look at any existing specification/s that describe a control transfer from boot loader to FOO. For example, look at the multi-boot specification, or a newer version of multi-boot, or the specification that Linux uses, or the specification that FreeBSD uses, or whatever else you can find.

For each existing "control transfer from boot loader to FOO specification"; determine if it's close enough to what you want and if you'd be willing to compromise if it's not. Also look at existing implementations. For example, if you're thinking about multi-boot, figure out the advantages/disadvantages of different implementations (e.g. GRUB-legacy, GRUB2, TrustedGRUB, Syslinux, etc). Also don't forget that you could chose an existing "control transfer from boot loader to FOO specification" and still write the boot loader yourself (for example, you might like the specification that Linux uses but want your own implementation that decrypts). You could also add support for your own custom "control transfer from boot loader to FOO specification" to an existing boot loader (e.g. write a patch for GRUB or something).


Cheers,

Brendan

muCF wrote:Basically, I've got an idea of a custom encrypted filesystem I'd like to implement for my newest OS project, and lots of other 'nonstandard' stuff, but don't know whether it would be smartest to start with GRUB or build a custom bootloader from the beginning.

The only "non-standard" stuff that really matters for the boot loader is the hard disk organisation so that it can read the kernel and any additional blobs (initrd, modules, whatever). For everything else, the usual arguments apply unchanged.

Now if the reason for having your own FS is encryption, I think I would go for a /boot partition approach. I'm assuming that you're only interested in encrypting your data, and the kernel binary isn't really secret. A small ext2 or FAT partition containing the kernel and any blobs the bootloader must read, and a large one for your own FS. Definitely the right approach for the least amount of head-banging-against-a-wall.

You can always write a GRUB module for your FS later if you think you need it. And that's a good approach, because...

One the one hand, building everything from scratch ensures I don't have to deal with that nasty "oh, right, Grub doesn't do that kind of thing" in the middle of my work.

...while this is true, with a custom bootloader you're guaranteed to have to deal with that nasty "oh, right, my custom bootloader doesn't do that kind of thing" in the middle of your work.

So I guess what I'm trying to say is: Writing one or two drivers for an existing bootloader is less work and probably gives a better result* than writing one or two drivers and a whole bootloader around it.

*) Not because I don't think you can write a decent bootloader, but because the bootloader tends to become a neglected minimalistic piece of code when you really want to write an OS and not just a bootloader.