[CRIU] [PATCH 5/5] parse_smaps: Don't mark vdso if prot mismatch

Cyrill Gorcunov gorcunov at openvz.org
Mon May 20 08:18:55 EDT 2013


On Mon, May 20, 2013 at 04:11:43PM +0400, Pavel Emelyanov wrote:
> On 05/20/2013 04:06 PM, Cyrill Gorcunov wrote:
> > On Mon, May 20, 2013 at 03:57:58PM +0400, Pavel Emelyanov wrote:
> >> On 05/16/2013 07:33 PM, Cyrill Gorcunov wrote:
> >>>
> >>> [vdso] mark is not very consistent in proc output.
> >>> Thus if vma has no VDSO_PROT set we can safetly assume
> >>> it's not vdso area.
> >>>
> >>> Signed-off-by: Cyrill Gorcunov <gorcunov at openvz.org>
> >>> ---
> >>>  proc_parse.c | 5 ++++-
> >>>  1 file changed, 4 insertions(+), 1 deletion(-)
> >>>
> >>
> >> in this case we can be in situation when no vmas are marked as
> >> vdso and we fail to proxify it on the 2nd dump/restore.
> > 
> > vdso is executable code, if application has remapped own vdso
> > as non-executable one -- it's up to this application to fail
> > in attempt to execute code without 'x' prot.
> 
> What if _we_ replaced task's vdso with proxy and ruined this mark.

We don't ruine the mark. Ever. If we drop it the whole scheme
will be broken.

> Then we try to migrate task again on a kernel with yet again changed
> vdso. We will not be able to detect vdso and will not proxify one.

It's implied that vdso mark (injected into Elf header on dump) will
always be present on restored vdso.

I fear I don't follow what you're trying to say. The idea is that we
inject mark on dump and always live with it even after restore.


More information about the CRIU mailing list