From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757170Ab2LNXzc (ORCPT ); Fri, 14 Dec 2012 18:55:32 -0500 Received: from terminus.zytor.com ([198.137.202.10]:52082 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757041Ab2LNXzb (ORCPT ); Fri, 14 Dec 2012 18:55:31 -0500 Message-ID: <50CBBC58.4080307@zytor.com> Date: Fri, 14 Dec 2012 15:55:04 -0800 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: John Stultz CC: Cyrill Gorcunov , Andy Lutomirski , aarcange@redhat.com, ak@linux.intel.com, Pavel Emelyanov , Stefani Seibold , x86@kernel.org, linux-kernel@vger.kernel.org, criu@openvz.org, mingo@redhat.com, tglx@linutronix.de Subject: Re: [CRIU] [PATCH] Add VDSO time function support for x86 32-bit kernel References: <50CAE485.5020608@parallels.com> <50CB716D.6020501@zytor.com> <50CB7459.7010107@zytor.com> <20121214201217.GE6582@moon> <50CB9553.7050808@zytor.com> <50CBA171.4080403@zytor.com> <20121214222517.GG6582@moon> <50CBA7BC.4020001@zytor.com> <20121214224307.GH6582@moon> <50CBACD2.60307@zytor.com> <50CBBACA.2070108@linaro.org> In-Reply-To: <50CBBACA.2070108@linaro.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/14/2012 03:48 PM, John Stultz wrote: > On 12/14/2012 02:48 PM, H. Peter Anvin wrote: >> On 12/14/2012 02:43 PM, Cyrill Gorcunov wrote: >>> On Fri, Dec 14, 2012 at 02:27:08PM -0800, H. Peter Anvin wrote: >>> >>> >>> This won't help in case of scenario you've been pointing in >>> previous email (where c/r happens in a middle of vdso), >>> would it? Because we still need somehow to be sure we're not >>> checkpointing in a middle of signal handler which will return >>> to some vdso place. >> It is okay if and only if those vdso places never change... which I >> think is doable if they only contain trival system call wrappers, i.e. >> something like: >> >> movl $__SYS_gettimeofday, %eax >> syscall >> ret > > Though doesn't this make it easier for exploits (somewhat undoing ASLR)? > I know Andi always wanted to avoid having syscall instructions at a > fixed location for the old vsyscall code (though I know we had it > none-the-less for awhile). But maybe I'm confusing issues here? > They aren't in fixed addresses across processes... the vdso location can still be randomized. It just has to be the same across the checkpoint/restart operation, just like all the other instructions. -hpa