Re: loadee relocation (Re: loader modules jumping back to kernel)

[Robert Millan]

On Wed, Jul 30, 2008 at 09:15:10PM +0200, Robert Millan wrote:
> 
> Let's try to revive this discussion.  Here's a patch I made a while ago that
> implements support for loading at any address.  It works by having a "special"
> version of malloc() that is told to allocate a chunk of memory that does
> _not_ overlap with a specific region.  It does so by iteratively reserving
> memory (and keeping track of what was reserved, of course).
> 
> Then we use this function to allocate the asm relocator code in heap, asking
> it to garantee that it won't overlap with our final destination.  Finally,
> our loadee can be put anywhere (e.g. in heap), and we just jump to the
> relocator which will jump to the loadee.
> 
> But I really find the approach really ugly.  What do you think?  If we agree
> that this is the way to go, I can do some cleanup & update it to current svn
> for a merge.

Here's a new patch, with the following approach.  We put this in a single
heap area:

  <forward_relocator> <payload> <backward_relocator>

we pick the relocator we want depending on wether we want to copy to a lower
or higher address.  This garantees that the relocator itself isn't
overwritten.  Then we set cpu context appropiately, and jump.

I like this much better.  Also, it doesn't depend on the static OS load
area.

Some doubts:

  - What to do about physical_entry_addr now?  My patch currently discards
    it, which I suppose is not what we want.

  - Should we do the same for the elf64 loader?  And how?  I don't know of
    any example ELF64 images I could test with.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

relocate_payload.diff
Description: Text Data