Restoring images with page-*.img anonymized

Submitted by Dmitry Safonov on Sept. 27, 2019, 1:44 p.m.

Details

Message ID 34b98f6a-93f2-29be-b766-cde546914bfa@gmail.com
State New
Series "Restoring images with page-*.img anonymized"
Headers show

Commit Message

Dmitry Safonov Sept. 27, 2019, 1:44 p.m.
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---

         * it must never ever be greater in size.

Patch hide | download patch | download mbox

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

Comments

Harshavardhan Unnibhavi Sept. 27, 2019, 6:58 p.m.
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@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.
>
Pavel Emelianov Sept. 30, 2019, 9:17 a.m.
On 27.09.2019 21:58, Harshavardhan Unnibhavi wrote:
> 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?

I think yes. Let's try and see how it goes.

-- Pavel
Harshavardhan Unnibhavi Sept. 30, 2019, 4:08 p.m.
Cool, I will implement this!

Harsha

On Mon, Sep 30, 2019 at 2:47 PM Pavel Emelianov <xemul@virtuozzo.com> wrote:

> On 27.09.2019 21:58, Harshavardhan Unnibhavi wrote:
> > 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?
>
> I think yes. Let's try and see how it goes.
>
> -- Pavel
>
Dmitry Safonov Sept. 30, 2019, 4:26 p.m.
Hi guys,

On 9/30/19 5:08 PM, Harshavardhan Unnibhavi wrote:
[moved reply from top-post]
> On Mon, Sep 30, 2019 at 2:47 PM Pavel Emelianov <xemul@virtuozzo.com
> <mailto:xemul@virtuozzo.com>> wrote:
> 
>     On 27.09.2019 21:58, Harshavardhan Unnibhavi wrote:
>     > 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?
> 
>     I think yes. Let's try and see how it goes.
>
> Cool, I will implement this!

Note that the diff I've sent just makes vdso to pass.

I'm not carefully following anonymize patches, but it depends on your
goal: basically, if you expect that someone could send you for debugging
anonymized images when restore failed because of proxify_vdso(), than
you might want to actually save vdso page in pages*.img.

Maybe you would like to move vdso page from pages*.img to vdso*.img or
something like that.

I don't mind either way, it's JFI.

Thanks,
          Dmitry
Pavel Emelianov Sept. 30, 2019, 5:05 p.m.
On 30.09.2019 19:26, Dmitry Safonov wrote:
> Hi guys,
> 
> On 9/30/19 5:08 PM, Harshavardhan Unnibhavi wrote:
> [moved reply from top-post]
>> On Mon, Sep 30, 2019 at 2:47 PM Pavel Emelianov <xemul@virtuozzo.com
>> <mailto:xemul@virtuozzo.com>> wrote:
>>
>>      On 27.09.2019 21:58, Harshavardhan Unnibhavi wrote:
>>      > 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?
>>
>>      I think yes. Let's try and see how it goes.
>>
>> Cool, I will implement this!
> 
> Note that the diff I've sent just makes vdso to pass.
> 
> I'm not carefully following anonymize patches, but it depends on your
> goal: basically, if you expect that someone could send you for debugging
> anonymized images when restore failed because of proxify_vdso(), than
> you might want to actually save vdso page in pages*.img.
> 
> Maybe you would like to move vdso page from pages*.img to vdso*.img or
> something like that.

For the 1st step we want to drop vdso and try to restore w/o it :)

> I don't mind either way, it's JFI.
> 
> Thanks,
>            Dmitry
>
Dmitry Safonov Sept. 30, 2019, 5:08 p.m.
On 9/30/19 6:05 PM, Pavel Emelianov wrote:> On 30.09.2019 19:26, Dmitry
Safonov wrote:
>> Hi guys,
[..]
>> Note that the diff I've sent just makes vdso to pass.
>>
>> I'm not carefully following anonymize patches, but it depends on your
>> goal: basically, if you expect that someone could send you for debugging
>> anonymized images when restore failed because of proxify_vdso(), than
>> you might want to actually save vdso page in pages*.img.
>>
>> Maybe you would like to move vdso page from pages*.img to vdso*.img or
>> something like that.
> 
> For the 1st step we want to drop vdso and try to restore w/o it :)

Alright :)

Just wanted to point in case you had a chance to miss it.

Thanks,
          Dmitry