[CRIU] [PATCH 0/5] vDSO: implement handling of zones any ordering

[Christopher Covington]

On 07/21/2014 08:57 AM, Cyrill Gorcunov wrote:
> On Mon, Jul 21, 2014 at 08:52:51AM -0400, Christopher Covington wrote:
>> Hi Cyrill,
>>
>> On 07/18/2014 10:44 AM, Cyrill Gorcunov wrote:
>>> In current linux-next vvar zone shifted back to be before vdso
>>> zone which made criu unhappy. So lets handle any order.
>>>
>>> Cyrill Gorcunov (5):
>>>   vdso: x86 -- Make sure that vdso symtable is carrying bindled vmas
>>>   vdso: x86 -- Test VMAs order in vdso_proxify
>>>   vdso: Drop unneeded @vdso_rt_vma_size variable
>>>   vdso: Move parking into a separate routine
>>>   vdso: Implement vDSO proxification of any vvar/vdso order
>>>
>>>  arch/x86/include/asm/vdso.h |   6 +-
>>>  arch/x86/vdso-pie.c         | 143 +++++++++++++++++++++++++++++++++-----------
>>>  arch/x86/vdso.c             |   9 ++-
>>>  cr-restore.c                |   7 +--
>>>  include/vdso.h              |   5 +-
>>>  pie/restorer.c              |  40 +++----------
>>>  6 files changed, 134 insertions(+), 76 deletions(-)
>>
>> Thanks for posting these. This allows the AArch64 port to work with upcoming
>> kernel changes given the norandmaps kernel parameter.
> 
> Hi Christopher! So with this series applied AArch64 proceeds well, right
> (just to make sure I understand you correctly)

Until the VDSO code was removed from AArch64, it was possible to dump and
restore processes if the "norandmaps" kernel parameter was passed at boot or
`echo 0 > /proc/sys/kernel/randomize_va_space` was run. Because I want my
workloads not to change from run to run, I already have Address Space Layout
Randomization (ASLR) off whenever I'm actually using CRIU. With ASLR active,
however, restored processes segfault.

Currently some version of VDSO support has to be added back to the AArch64
port in order to even test things, so I'm doing that.

The AArch64 kernel has patches in -next that switch the ordering of [vdso] and
[vvar], just like on x86. With your patches, this new issue is handled.

I have not yet found a pair of AArch64 kernel and CRIU where dump and restore
work with ASLR turned on. I've just started trying to figure out exactly what
is going wrong with VDSO movement/proxification when ASLR is on. If any of you
already know, that would be useful information.

Also, how do you debug this sort of thing? I'm currently using instruction
trace output from my simulator, but I think I could also hook up GDB to the
simulator to get assembly-level interactive debugging. Running ftrace on the
gettimeofday calls didn't give me very useful information. kprobes might be
able to provide more detail.

Thanks,
Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.