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:	Fri, 14 Dec 2012 13:08:35 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Cyrill Gorcunov <gorcunov@...nvz.org>
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 12/14/2012 12:12 PM, Cyrill Gorcunov wrote:
>>>
>> 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).
> 

I don't think there is a way around that.  It is completely unreasonable
to say that the vdso cannot change between kernel versions, for obvious
reasons.  It's worse than "significantly"... changing even one
instruction makes it plausible your eip/rip will point into the middle
of an instruction.

	-hpa


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