Re: [Sbcl-devel] Memory randomization problems coming

[Dave R. <ld...@dr...>]

On Tue, 2005-08-02 at 11:54 -0400, Raymond Toy wrote:
> >>>>> "Dave" == Dave Roberts <ld...@dr...> writes:
> 
>     Dave> Is there any way to actually get the loader to do this for us? I'm
>     Dave> thinking about a dump algorithm that links the core file with an SBCL
>     Dave> runtime and creates an ELF. That way, not only is the memory region
>     Dave> reserved in the ELF, the data is actually present there, too. Since SBCL
>     Dave> carries its tag bits in the lower bits of an address, they should be
>     Dave> transparent to the loader, no? I'm not an ELF expert by any means, so
>     Dave> this may be a stupid idea.
> 
> If I understand what you're saying here, Fred Gilham has done
> something like this for CMUCL.  The result is a big executable that
> contains the core file.  There might be some other issues.  I do know
> that Fred stopped work on it (for lack of time) and because it
> required some hairy linker scripts to implement this.

Actually, I'm suggesting more than just bundling the core in with the
executable. I'm suggesting going one step farther and having the link
loader perform all the address adjustments for us such that the core
file segment is actually relocatable. As I understand it (and again, I'm
no ELF expert by any means), the loader can adjust offsets in the file
to allow it to be repositioned. I believe this is done for standard
relocatable libraries, right? Executables are traditionally not
relocatable but even this is changing with memory randomization
techniques being used for security. Red Hat is now compiling various
standard daemons as "Position Independent Executables" (PIEs) so they
can randomize the addresses of all the code segments, too.

Anyway, rather than writing our own relocating loader, I was just
wondering if we could harness the existing machinery, and also kill the
"can't I make a single executable?" FAQ as well. ;-)

-- 
Dave Roberts <ld...@dr...>