GRUB and modules

[srg_13]

Is it possible to write a flat binary or something that contains a variable, load it as a module with GRUB, and then use it in the kernel? I would like to let the user load different keyboard layouts for use in the kernel. How would this be done? I have looked in the FAQ, and GRUB's documentation, but gained little knoledge. As I understand, you add the line

Code: Select all

module [filename]

to the menu.lst file, and then it will load that. What kind of file must this be? Eg. Flat binary, elf, text file... And then how can I make the kernel use variables and subroutines stored in this file? Do I have to jmp to it or something?

Thanks,

-Stephen

[JoeKayzA]

To my knowledge, multiboot modules can be _any_ format, GRUB doesn't even investigate in this. It just loads them into memory and that's it. Only the kernel needs to comply to a certain standard (the multiboot header, and optionally the a.out kludge).

You can retrieve information about modules (name, commandline arguments, load address) through the multiboot information structure passed to your kernel.

About how to access these files: It's up to you again. If you just want to read some values, well then get a pointer to the module's load address and access it like a simple data structure - no need to jump there unless the module contains code.

cheers Joe

[Pype.Clicker]

in other words, you may very well have several ELF files as modules and an ELF kernel, but you shouldn't rely on GRUB to link them at load-time like a proper OS would do. anything to be done with the data present in "module" files (e.g. displaying the splash image on screen, launching a "init.exe" program or linking a kernel module with the kernel) is the sole responsibility of the kernel itself.

[KieranFoot]

I have been tryingto get this to work for my kernel (MGOS3), however i cannot get it to work...

My problem is that the module data struct contains invalid values.

When i look at the data pointed to by Module.Start the data is incorrect, so either the data pointer is a relative pointer or the module struct is incorrect or the data is loaded somwhere other than the module.start address...

If you manage to get this working, please would you PM me with the code.

---
Thanks for reading
Kieran Foot

[Assembler]

If your module is flat binary which needs NO relocation (PIC or PIE) & it doesn't call any function from kernel directly (it may use ring 0 INTs to access kernel), then grub can load it for you & you can jump normally to it.
but if used strings without using a register for addressing as ebx, you may cause a fault.
remember you have to use Position Independent Code, which can be achieved easily in Assembly.
AFAIK gcc & ld has -pie or -pic which doesn't work
Assembler,

[Pype.Clicker]

I have been tryingto get this to work for my kernel (MGOS3), however i cannot get it to work...

My problem is that the module data struct contains invalid values.

I have some code for reading modules in init.c. To my best knowledge, the .start and .end fields are valid (unless you have weird issues with paging). Note however that the GRUB information may sometimes be in "odd" places and that i had to "move" it manually to a safer place as my kernel swept the "low memory area" before it uses multiboot structures in multiboot.asm.

maybe you may want to check that your kernel isn't overwriting those informations. Try setting a bochs breakpoint at 0x01000000 and crawl memory to see if everything reported by GRUB is as expected _before_ your kernel start meddling with it ... maybe you may want to check your version of GRUB too ...

[Candy]

AFAIK gcc & ld has -pie or -pic which doesn't work
Assembler,

Got anything more substantial than a hollow sentence to back that claim up?

[Pype.Clicker]

AFAIK gcc & ld has -pie or -pic which doesn't work

Got anything more substantial than a hollow sentence to back that claim up?

I guess what he means is that it's not enough to say -fPIC and jump to the binary where it has been loaded to see things working (as it would be the case on a StrongArm, for instance

[Solar]

GCC PIE does work. I should know, as I've set up a hardened-gentoo server just this weekend (utilizing a PIE-SSP toolchain to enable PaX / Address Space Layout Randomization).

[Assembler]

-fPIC really don't work on all architectures, it works for SPARC & m68k processors, and is used mostly for dynamic linking and can't be used to generate grub modules where we can jump to it.

check this link:
http://www.ip97.com/gcc/Code-Gen-Options.html

which says:

fPIC
If supported for the target machine, emit position-independent code, suitable for dynamic linking and avoiding any limit on the size of the global offset table. This option makes a difference on the m68k and the SPARC.

Position-independent code requires special support, and therefore works only on certain machines.

Assembler,

[Solar]

"If supported for the target machine."

Which means, if you want it for your GRUB modules, you have to add support for it. Which does not mean "broken" or "does not work".

A good starting point could be this Gentoo doc.

[Assembler]

"If supported for the target machine."

Which means, if you want it for your GRUB modules, you have to add support for it. Which does not mean "broken" or "does not work".

A good starting point could be this Gentoo doc.

I don't mean "broken" by "doesn't work", but i mean it can't be an escape from writing a loader for modules, the only thing that can achieve this is assembly by using relative addressing.
So why try to add support for something that is not supported by this achitecture. which will end by writing a module loader.
Just add an elf or aout loader in your kernel.

Assembler,