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

Pavel Emelyanov xemul at parallels.com
Mon May 20 08:11:43 EDT 2013


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.
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.

> Look, letme explain. The [vdso] mark in procfs is inconsistent,
> I can't trust it. Thus I need to parse vma content and figure
> out if it's vdso area or not.
> 
> Still I don't want to walk over all VMAs the task has, since it's
> time consuming.
> 
> Thus I assume, since vdso area is executable, it must have at least
> 'rx' prot. So I can skip calling for vdso parser for all vmas which
> do not fit this requirement, this speeds up procedure significantly
> that I don't even need to call for parasite helpers.
> .
> 




More information about the CRIU mailing list