[CRIU] custom initialization during restore

[Cyrill Gorcunov]

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 we can pre-load some custom .so but carrying it inside
restorer blob not gonna be easy: should criu itself do a lookup
over the symbols to find which one to call?

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?

	Cyrill