[CRIU] Re: [PATCH 03/13] make: Sanitize pie.lds.S
Stanislav Kinsbursky
skinsbursky at parallels.com
Wed Apr 18 05:49:51 EDT 2012
18.04.2012 13:06, 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.
>
Why "read-only" attribute is dropped? Is it a part of current implementation or
is was designed this way?
AFAIK, we do not change the binary on the fly. Or we do?
> 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
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://openvz.org/mailman/listinfo/criu
--
Best regards,
Stanislav Kinsbursky
More information about the CRIU
mailing list