Unable to restore processes with vDSO unmapped

[wno-git]

Hello,

CRIU fails to restore applications that have unmapped the vDSO segment. One such
application is Valgrind. When the checkpoint is restored CRIU complains that the
vDSO segment is not found in the checkpoint image and will not restore.

Steps to reproduce:

$ valgrind --tool=none cat &
==26474== Nulgrind, the minimal Valgrind tool
==26474== Copyright (C) 2002-2017, and GNU GPL'd, by Nicholas Nethercote.
==26474== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==26474== Command: cat
==26474==

$ grep vvar /proc/$(pidof valgrind.bin)/smaps
7fff258df000-7fff258e2000 r--p 00000000 00:00 0                          [vvar]

$ grep vdso /proc/$(pidof valgrind.bin)/smaps
$ echo $?
1

# criu dump -j -t $(pidof valgrind.bin)

# criu restore -j
pie: 27729: Error (criu/pie/parasite-vdso.c:252): vdso: Can't find vDSO area >
pie: 27729: in image
pie: 27729: Error (criu/pie/restorer.c:1689): Restorer fail 27729
Error (criu/cr-restore.c:2252): Restoring FAILED.

By commenting out the call to vdso_proxify in criu/pie/restorer.c:1360 I'm able
to successfully restore the Valgrind process. However, the newly created process
has the vDSO mapped again which can be a problem for this kind of application
that has explicitly unmapped its vDSO.

# criu -V
Version: 3.8.1

$ valgrind --version
valgrind-3.13.0

$ uname -a
Linux devbox 4.16.0-1-amd64 #1 SMP Debian 4.16.5-1 (2018-04-29) x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID:    Debian
Description:       Debian GNU/Linux testing (buster)
Release:           testing
Codename:          buster

[avagin]

Cc: @cyrillos @0x7f454c46

[0x7f454c46]

Ugh, that's mine.
I even have previously written zdtm/static/vdso02.c test to check that.
Looks like, something is wrong with the test, I'll look, thanks.

[0x7f454c46]

A-ha, so what I did in the test - I've unmapped vdso and vvar.
Because I thought no application would be too mad to unmap itself vdso.
So, that test was done to check CONFIG_VDSO=n.
Hmm, and valgrind does unmap vdso, but doesn't touch vvar:
pmem/valgrind@9bb8119

Which is kinda unexpected. The commit doesn't specify why "the vdso will be at a random address
and can conflict with things..." and why vvar mapped on a random address suits valgrind.

Anyway, I can make it work with vvar mapped and vdso unmapped, but that needs a bit of care in case of migration: we need to make sure that vvar is the same on the target machine.
IIRC, I did put vdso layout to kdat structure, so we can just compare it (layout) from source to dest machine - and be pretty sure that vvar is the same.
I'll fix it in near days.

[0x7f454c46]

JFI: I sent an email asking valgrind folks why they unmap() vdso, but leave vvar in place. Also why don't they mremap() vdso.

I think it's not always possible to restore an application with vdso unmapped, but vvar present. The reason is that if vdso blob differs after C/R (say migration scenario or after kernel update) - we do proxify vdso entries on vdso from image file to the new vdso from the system. But we can't proxify vvar. It's a page that is being constantly updated by kernel and shared-mapped in all processes. So if the format of the page changed after C/R - restore should exit with an error.

So, we definitely can improve a bit situation where vvar (and vdso) are still the same - as we sure the offsets of variables on vvar are same - but that will require a bit of work to save some info from dump in images where vvar is present and verify that it's still same on restore. Might be worth to do.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.