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

[Aleksandr Kartashov]

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

--
Sincerely yours,
Alexander Kartashov

________________________________________
From: criu-bounces at openvz.org [criu-bounces at openvz.org] on behalf of Alexander Kartashov [alekskartashov at parallels.com]
Sent: Thursday, February 27, 2014 7:37 PM
To: Christopher Covington
Cc: criu at openvz.org
Subject: Re: [CRIU] [PATCH] Wire up AArch64 TLS dump and restore

On 02/27/2014 07:22 PM, Christopher Covington wrote:
> It looks like support for NT_ARM_TLS is missing for A32. I'll add that onto my
> someday/maybe list. Also, u32 seemed to work for one test case but is
> insufficient for other A64 cases. I should have a revised patch in a few days
> that uses unsigned long like the kernel in C code and u64 in protobuf. Any
> progress on the test suite pass rate? I've been using other programs to test
> for the moment but I hope to start running the test suite in the future.
>
> Christopher
Dear Cristopher,

I've already bumped into the problem that the TlS register is 64bit long.
I've currently solved it by introducing the dedicated type tls_t for
every architecture.

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 :(

--
Sincerely yours,
Alexander Kartashov

Intern
Core team

www.parallels.com

Skype: aleksandr.kartashov
Email: alekskartashov at parallels.com

_______________________________________________
CRIU mailing list
CRIU at openvz.org
https://lists.openvz.org/mailman/listinfo/criu