OSDev.org

I'm not very familiar with GRUB. But I'm researching the use of GRUB bootloader to launch and execute some pre OS operations ( like modifying bus enumeration/ access to PCI config space ). Can GRUB's module files be used for that? After the operations are performed , I would then launch /boot into the OS.

bbrar wrote:I'm not very familiar with GRUB. But I'm researching the use of GRUB bootloader to launch and execute some pre OS operations ( like modifying bus enumeration/ access to PCI config space ). Can GRUB's module files be used for that? After the operations are performed , I would then launch /boot into the OS.

Assuming you mean modules executing in real mode before the kernel, no. GRUB will always jump to the kernel. Modules that are loaded are passed via structs to the kernel in the multiboot struct. So the modules are just extra files that GRUB loads for your kernel to use, and can be anything from an initrd to drivers to whatever you please.

Disclaimer: I don't claim to be a GRUB expert, just someone who's used it a couple of times.

bbrar wrote:I'm not very familiar with GRUB. But I'm researching the use of GRUB bootloader to launch and execute some pre OS operations ( like modifying bus enumeration/ access to PCI config space ). Can GRUB's module files be used for that? After the operations are performed , I would then launch /boot into the OS.

In practice, does it matter? The problem as described is nothing more than having several bits of code you want to run in a specific order. What is preventing you to just put those bits in the kernel binary and call the functions in that specific order?

Well.. ideally I want the code to be OS agnostic or in other words not plug into a specific OS.. that is why I am looking at doing my custom code prior to the OS booting up.

Unless you want to make a full-fledged virtualisation rootkit, there's nothing of the sort you can sanely do. Any OS started afterwards will simply enumerate the PCI of its own again and the only way you can alter the result is by preventing the access altogether. And in general, the only thing your code can really do - without having a way of communicating with the kernel - is breaking things.