[CRIU] Restoring images with page-*.img anonymized

[Harshavardhan Unnibhavi]

So by using the second option(as suggested by Dmitry) the following
information is obtained(which is also obtained during a normal restore):
(A)
vdso: Runtime vdso/vvar matches dumpee, remap inplace
vdso: Remap rt-vdso 0x2a000 -> 0x7ffca6198000
vdso: Remap rt-vvar 0x27000 -> 0x7ffca6195000
vdso: Using gettimeofday() on vdso at 0x7ffca6198d40

Other information when restored normally like:
(B)
vdso: PT_LOAD p_vaddr: 0x0
vdso: DT_HASH: 0x120
vdso: DT_STRTAB: 0x298
vdso: DT_SYMTAB: 0x1a8
vdso: DT_STRSZ: 0x5e
vdso: DT_SYMENT: 0x18
  vdso: nbucket 0x3 nchain 0xa bucket 0x7ffca6198128 chain 0x7ffca6198134
vdso: image [vdso] 0x7ffca6198000-0x7ffca619a000 [vvar]
0x7ffca6195000-0x7ffca6198000
is not available.

Is the information in (A) enough to decide that the restore process was
successful?

Best,
Harsha



On Fri, Sep 27, 2019 at 7:14 PM Dmitry Safonov <0x7f454c46 at gmail.com> wrote:

> On 9/27/19 2:41 PM, Dmitry Safonov wrote:
> > On 9/27/19 8:45 AM, Cyrill Gorcunov wrote:
> >> On Thu, Sep 26, 2019 at 10:48:24PM +0000, Pavel Emelianov wrote:
> >>> On 26.09.2019 18:37, Harshavardhan Unnibhavi wrote:
> >>>> Hi,
> >>>>
> >>>> I am trying to restore images with pages*.img removed. When restore
> calls
> >>>> vdso_proxify there is a problem with the ELF headers and their
> associated
> >>>> addresses as they are not available. What should I do?
> >>>
> >>> Cyrill, Dima, would you please help us on this. Briefly -- we want to
> >>> "emulate" the restoration from images with pages*.img files removed and
> >>> we hit this:
> >>>
> >>> vdso: Parsing at 0x7ffca6198000 0x7ffca619a000
> >>> vdso: PT_LOAD p_vaddr: 0x0
> >>> vdso: DT_HASH: 0x120
> >>> vdso: DT_STRTAB: 0x298
> >>> vdso: DT_SYMTAB: 0x1a8
> >>> vdso: DT_STRSZ: 0x5e
> >>> vdso: DT_SYMENT: 0x18
> >>>   vdso: nbucket 0x3 nchain 0xa bucket 0x7ffca6198128 chain
> 0x7ffca6198134
> >>> vdso: image [vdso] 0x7ffca6198000-0x7ffca619a000 [vvar]
> 0x7ffca6195000-0x7ffca6198000
> >>> vdso: Runtime vdso/vvar matches dumpee, remap inplace
> >>> vdso: Remap rt-vdso 0x2c000 -> 0x7ffca6198000
> >>> vdso: Remap rt-vvar 0x29000 -> 0x7ffca6195000
> >>> vdso: Using gettimeofday() on vdso at 0x7ffca6198d40
> >>>
> >>> apparently, the parsed info is taken from pages images which are
> missing.
> >>> Does this parsing affects anything beyond the memory contents, or can
> we
> >>> just skip the whole parse code for our purposes?
> >>
> >> I think when you're dropping content of pages you should not modify
> vdso page
> >> but leave it as is. Don't you?
> >
> > Either this or hack it under anonimization, something like this
> > (completely untested):
>
> [..]
> And a little self-correction:
>
> --->8---
>
> diff --git a/criu/pie/parasite-vdso.c b/criu/pie/parasite-vdso.c
> index 38da766804ab..3e48013b9e63 100644
> --- a/criu/pie/parasite-vdso.c
> +++ b/criu/pie/parasite-vdso.c
> @@ -292,6 +292,12 @@ int vdso_proxify(struct vdso_maps *rt, bool
> *added_proxy,
>                 return -1;
>         }
>
> +       /* Anonymous images don't have vdso in pages*.img */
> +       if (opts.anonymize) {
> +               *added_proxy = false;
> +               return remap_rt_vdso(vma_vdso, vma_vvar, rt);
> +       }
> +
>         /*
>          * vDSO mark overwrites Elf program header of proxy vDSO thus
>          * it must never ever be greater in size.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20190928/0b4b55bf/attachment.html>