[CRIU] custom initialization during restore

[Pavel Emelyanov]

On 08/12/2015 11:16 AM, Cyrill Gorcunov wrote:
> On Wed, Aug 12, 2015 at 10:32:56AM +0300, Pavel Emelyanov wrote:
>> On 08/11/2015 09:12 PM, CRIU criu wrote:
>>> Alright. Let's say we do "LD_PRELOAD=/lib/libcriume.so ./process_to_be_checkpointed arg1 arg2" with
>>> libcriume.so containing function pre_restore_plugin().
>>
>> Well, maybe the criu_hooks[] array would be a better approach, but overall -- yes.
>>
>>> You are suggesting that criu code will parse ELF libcriume.so to get address of the symbol
>>> "pre_restore_plugin" and look at calculate the load address looking at /proc/<pid>/maps? 
>>
>> Probably vice-versa, first criu will find libcriume.so in maps, then will look at the
>> binary over there and get the required symbol. And on restore the detection of libcruime
>> will come from images.
>>
>> And, just to be 100% correct -- right now CRIU doesn't do it, patching is required.
>>
>>> Let me know if my understanding is correct. Thanks!
>>
>> Overall -- yes.
> 
> This, actually brings a number of problems: the CRIU's pie code
> (if I understand correctly we need to call some pre-sigreturn helper
>  functions, which are "external" in terms of CRIU symbols) is very
>  special one -- the main requirement is that all symbols must be
>  resolved, so in general we carry all the data needed for restorer
>  inside the memory blob which we're generating dynamically.

Sure, but symbols resolution can be done before calling pie code. I
would even add -- we can do it dump-time and save hooks' addresses
into images :D

> Sure we can pre-load some custom .so but carrying it inside
> restorer blob not gonna be easy: 

It's just one of task's mappings.

> should criu itself do a lookup
> over the symbols to find which one to call?

Yes.

> I suspect the better would be to implement PIE plugins, which
> would export a number of PIE hooks, thus one provide a plugin,
> criu load it into restorer blob and calls appropriate helpers
> when needed. Say we may have CR_PLUGIN_HOOK__PIE_RST_PRE_SIGRETURN
> or something. The difference from native/real preloaded .so file is that
> we're applying strict rules on plugins structure and we assume
> that such plugin does _not_ carry any unresolved symbols. Hm?

The plugins we're talking about should better be per-application.
Thus linking them into a process sounds more promising.

-- Pavel