OSDev.org

Hello,
to circumvent the problems I had with GRUB2 loading my AMD64 kernel, I decided to write a small loader binary in 32 bits that resides in the lower half, does the long mode readying stuff, loads the kernel ELF64 binary that is attached as a multiboot1 module and jump to its entry point.

Although the last point on the list might sound simplest, its actually the one I have most of the problems with. To jump to the 64 bit higher half entry point address (somewhere near 0xFFFFFF000000000), I planned to far jump to a 64 bit realm in the loader itself, that performs the jump to the actual entry point. My problem is to embed this 64 bit realm into my elf32 kernel. I tried the following approach, but it did not work out (machine resetting):

It's not a really clean approach and I really don't know how to debug the code above, so is there any way of jumping to this high entry point address besides of making the binary elf64 itself (GRUB Legacy, unpatched, and I want it to stay this way) and linking the 64 bit realm to it or adding another module that contains just these few bytes of 64 bit code?

I don't know which assembler you are using (NASM?), but I don't think you need to hardcode the jump byte by byte. In my kernel, I use a small 64 bit trampoline which is identity mapped in the lower half and to which I can jump from protected mode using a 32 bit far jump. As soon as I am in a 64 bit code segment, I load rax with a higher half address.

I actually tried to do so, but as I'm linking my loader as elf32, the object files cannot be elf64 which would be required for embedding the trampoline. I try to stick with elf32 as it should be most compatible among multiboot bootloaders, especially GRUB Legacy. In the ideal case my boot.s would not something like this, but doing this I run into the mentioned linking issues:



BTW: I'm using NASM (Intel Syntax, I could never really accommodate myself to GAS).

Edit: Typo

I think I get your point. I guess in that case you really need to replace the 64 bit trampoline code from my example by some hand-written byte code as in your original post. Most importantly, you need to hard-code the higher half entry address of your 64 bit kernel, since you cannot use 64 bit relocations in a 32 bit elf file.

Another possibility would be to include the trampoline in your 64 bit kernel module and to use an identity (or some other temporary lower half) mapping in the early boot phase. Then you can jump from your 32 bit loader to the lower half mapped trampoline in your 64 bit kernel. From there you jump to the higher half and clear the identity mapping.

In any case, you must be in a 64 bit code segment before you can use 64 bit addresses, so either way you will need some trampoline below 4GB.

Developing the idea of the hard coded address a bit further, the byte code could dynamically be generated, written to memory and jumped to. That enables me to use the entry point address as it is defined in the ELF64 header and still not requiring it to provide a trampoline by itself. I think I will give this a try.

Edit: Actually this C code seems to create the right opcodes for jumping to 0x1234567890ABCDEF, I hope it will work out...
Edit 2: It does work after having spend several hours debugging my paging code, so this solution seems to be a serious alternative when loading 64 bit kernels.

Nice idea, I think that should work as well. The byte coded mov / jmp looks perfectly fine to me.