jmp_to_elf_entry

[Eric W. Biederman]

steven james <pyro at linuxlabs.com> writes:

> Greetings,
> 
> Looks like I've trodden on an unused code path, and found a bug.
> In arch/i386/boot/boot.c: jmp_to_elf_entry, the idea is to copy all of the
> running code (linuxbios, or a baremetal payload) to a bounce buffer, jump
> into the copy there,  copy the bounce buffer of the target elf into place,
> and call it. Upon return, the process is reversed, so that (in
> theory) jmp_to_elf_entry returns and further processing can happen.
> 
> For some reason, the lines that subtract the adjustment from EAX, then
> jump to move execution back to the proper place was failing. I've patched
> it in the copy kept in util/baremetal/lib so that instead, it loads the
> eventual jmp target into ecx, then saves it away on the stack. 
> 
> I'm surely missing something here, but the original goes into space while
> the simple save off is working. I suppose that's just because we've never
> tried to return to LinuxBIOS from a payload before.

That sounds correct.  It was there for completeness rather than a real
need.  And I never did test it.
 
> The baremetal version also skips adjusting ESP since I'm moving the stack
> out of the way first.
> 
> Ignore the // debugging stuff, that was just to see where things were
> going wrong (I'll be getting rid of that).
> 
> Eric, since you wrote that part, I wanted to run this by you before making
> any changes in LinuxBIOS itself.

I would not be surprised to learn that the returning to LinuxBIOS
was not working.

For LinuxBIOS itself all we can do is call hard_reset like we do
for the other weird cases.  But for the baremetal tool kit there
we can definitely do something interesting.

I will have to look at what you are looking at stack wise but I certainly
think we should have a stack that is out of the way as well, and we cannot
have that in LinuxBIOS until we actually know our final memory
size.   And that information is not know until late.

There is one glitch in the LinuxBIOS code.  After thinking and
looking at things and see what works most reliably.  We should
be passing the address of the parameter block with the standard
C calling conventions (and on x86 this is on the stack).  I have
modified etherboot to do this.  I have not gotten back to the
LinuxBIOS code.

With respect to memory maps.  That is one piece of information that
we should pass both ways.  Both in the LinuxBIOS table, and in
the parameter block we pass to the loaded image.

This allows someone to find the real memory usage as well as to
find what the bootloader thinks about the current situation.
A memory map is something fundamental enough that the memory
allocation will always be changing. 

I need to take my that specifies things about ELF booting and do
another version.  But I have not gotten quite that far yet.

Eric