[CRIU] [PATCH] Wire up AArch64 TLS dump and restore

[Cyrill Gorcunov]

On Sun, Mar 02, 2014 at 05:02:34PM +0000, Aleksandr Kartashov wrote:
> > Currently I'm working on validating the port with the ZDTM suite.
> > Unfortunately, I've stuck with the first test static/busyloop00
> > that crashes on exit :(
> 
> It seems I've figured out what goes wrong: AArch64 needs VDSO proxy implementation:
> the restored process crashes trying to execute the VDSO code while the VDSO
> is unmapped by the restorer.
> 
> Unfortunately, the VDSO proxy mechanism for x86 can't be adopted for AArch64:
> the AArch64 VDSO contains the signal handler trampoline (http://lxr.free-electrons.com/source/arch/arm64/kernel/signal.c#L237)
> and the kernel saves the address of the trampoline when a process is created.
> This means that:
> 1) the VDSO binary must not be moved on AArch64, otherwise no signals may be delivered
>    to the restored process.
> 2) it's generally impossible to restore a process on AArch64 since the VDSO mapping
>    in the "bootstrap" process may intersect a mapping of the restoree.
> 
> There're two ways to tackle the problem:
> 1) Implement a "non-moving" VDSO proxy for AArch64 --- the greatest drawback of the approach
>    is that restoring may accidentally fail because of the VDSO position in the "bootstrap" process
>    address space.
> 2) Patch the kernel so that it may detect a VDSO remap and update the signal handler trampoline
>    address accordingly. This approach may make is possible to share the x86 VDSO proxy implementation
>    with AArch64.
> 
> Cyrill, what approach is the most feasible?

Well, I fear I'm not that usefull in this aspect since I've no clue about arm architecture,
but lets try to deal with this issue. Could you please clarify the:

1) The vDSO area in arm created by the kernel during process startup, right?
2) The vDSO area is placed at pedefined address or it's random address?
3) Workaround this problem without kernel patching is preferred for sure but
   if it _may_ accidentaly fail I fear we have no option but to patch the kernel.