[CRIU] Dealing with VDSO remap

Christopher Covington cov at codeaurora.org
Fri Mar 6 06:58:37 PST 2015


Hi Laurent,

On 03/06/2015 09:15 AM, Laurent Dufour wrote:
> Hi,
> 
> I'm porting CRIU to the PopwerPC architecture, and among other issues,
> I'm facing a major one with the VDSO remapping at restart time.
> 
> On PowerPC, as on ARM64, the kernel keeps track of the VDSO base address
> because it is using it to jump back to a sigreturn trampoline at the end
> of a signal processing (see handle_rt_signal64 in
> arch/powerpc/kernel/signal_64.c, and for ARM64, setup_return in
> arch/arm64/kernel/signal.c).
> 
> When remapping the VDSO at restart time, the kernel keep the reference
> to the previous VDSO mapping, the one inheriting from the criu, so
> handling signal after the restart leads to unpredictable results, most
> of the time a SIGSEGV is raised.
> 
> I didn't find a smart way to update the kernel reference to the vdso
> mapping once the VDSO is remapped, so no way to work around that today.
> 
> Furthermore, since this is the same picture on ARM 64, I'm wondering how
> it could work on this architecture. Am I missing a major thing here ?
> 
> If not, is there a plan in the CRIU project to to deal with that, other
> than by hacking the kernel to update its reference at restart time ?

It's been a while since I worked on this, and I feel like I never had a really
solid understanding of all the parts, but hopefully this can help.

I think the ideal solution would be for a remap system call to move the VDSO.
This may have been implemented for x86, but I think it's a new feature and
missing on most other architectures. There's a lot of duplication in the VDSO
code between architectures. If there was less duplication, the x86 additions
might easily apply to other architectures as well, but I've never gotten
around to consolidating the VDSO code and I haven't noticed anyone else having
gotten around to it either.

The workaround is to put trampolines/branches at the location that the
restored process expects to the location that the VDSO is currently located at
restore time. See vdso_redirect_calls in arch/aarch64/vdso-pie.c.

Chris

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


More information about the CRIU mailing list