linux-kernel - Re: [CRIU] [PATCH] Add VDSO time function support for x86 32-bit kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 15 Dec 2012 00:12:17 +0400
From:	Cyrill Gorcunov <gorcunov@...nvz.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Andy Lutomirski <luto@...capital.net>, aarcange@...hat.com,
	ak@...ux.intel.com, Pavel Emelyanov <xemul@...allels.com>,
	Stefani Seibold <stefani@...bold.net>, x86@...nel.org,
	linux-kernel@...r.kernel.org, criu@...nvz.org, mingo@...hat.com,
	john.stultz@...aro.org, tglx@...utronix.de
Subject: Re: [CRIU] [PATCH] Add VDSO time function support for x86 32-bit
 kernel

On Fri, Dec 14, 2012 at 10:47:53AM -0800, H. Peter Anvin wrote:
> On 12/14/2012 10:44 AM, Andy Lutomirski wrote:
> >>
> >> mremap() should work.  At the same time, the code itself is not going to
> >> have any stability guarantees between kernel versions -- it obviously
> >> cannot.
> > 
> > We could guarantee that the symbols in the vdso resolve to particular
> > offsets within the vdso.  (Yes, this is ugly.)
> > 
> > Does criu support checkpointing with one version of a shared library
> > and restoring with another?  If there are no textrels (or whatever the
> > relocation type that actually modifies text as opposed to just the plt
> > or got) then, in principle, it should be doable.  Otherwise some
> > kernel help will be needed to checkpoint reliably on one kernel and
> > restore somewhere else.
> > 
> > (This isn't a regression -- it's already broken.)
> > 
> The real issue is that happens if the process is checkpointed while
> inside the vdso and now eip/rip or a stack frame points into the vdso.
> This is not impossible or even unlikely, especially on 32 bits it is
> downright likely.

I fear if there are stacked ip which point to vdso -- we simply won't
be able to restore properly if vdso internal format changed significantly
between kernel versions. (At moment we restore vdso exactly at same position
it was on checkpoint stage with same content, iirc).

	Cyrill
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/