[CRIU] Re: [PATCH 03/13] make: Sanitize pie.lds.S

[Cyrill Gorcunov]

On Wed, Apr 18, 2012 at 12:40:19PM +0400, Pavel Emelyanov wrote:
> On 04/18/2012 12:16 PM, Cyrill Gorcunov wrote:
> > On Wed, Apr 18, 2012 at 12:11:31PM +0400, Pavel Emelyanov wrote:
> >> On 04/18/2012 01:55 AM, Cyrill Gorcunov wrote:
> >>> No need to generate several sections in blobs,
> >>> one is enough. We need a simple and strictly
> >>> predefined structure.
> >>
> >> Why?
> >>
> > 
> > Because it reflects what exactly is going on. We do
> > pass everything in one binary blob,
> 
> Cyrill, this is bad explanation from my pov. When we call execve what
> happens is -- we load a big blob into memory, but still we use the
> sections in it. So is the parasite/restorer -- we do load some binary
> into some place in ram and keeping sections is OK.

What we load it blob which has no sections at all, that's what
"binary" target about. And we don't call execve on our blobs
at all, we simply inject it into program as executable memory
area ;)

Letme explain with more details. Once object elf file compiled,
it has predefined structure which we simply can't handle without
own Elf loader (if you remember I've had Elf loader implemented
but then I simply drop this idea because it makes project more
complex, slower and error prone).

Thus we generate binary blob which contains all sections as one
flat stream of bytes with relocations applied (ie started from
virtual address 0).

When we load this blob, we load it whole at once, and load it
into executable memory area, so any "read-only" attributes
simply dropped. Everything is read/write/execute.

And I think the ld script should reflect this. Pavel, note
we can leave the sectioning in ld as

{
	.text 0x0 : {
		*(.text)
		...
	}

	.data : {
		...
	}

	.bss : {
		...
	}
}

But this (from my POV) doesn't reflect what exactly is happening
with this blob after it's generated.

In turn

{
	.text 0x0 : {
		*(.text)
		*(.data)
		...
	}
}

Does show what we're intended to do with generated result.

	Cyrill