[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