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

[Cyrill Gorcunov]

On Mon, Jul 21, 2014 at 09:33:57AM -0400, Christopher Covington wrote:
> > 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.

Ah, cool, good to know, thanks!

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

Happy to help, but sorry know nothing about that (that said I know what
ASLR is and its general concepts but never looked into the details).

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

There is a testcase vdso01 which remembers the positions of functions before
checkpoint and on restore tests if positions remain the same and does every
call testing the results (pretty trivial but fine for now).