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
| ||
|
Date: Fri, 14 Dec 2012 13:27:04 -0800 From: Andy Lutomirski <luto@...capital.net> To: "H. Peter Anvin" <hpa@...or.com> Cc: Cyrill Gorcunov <gorcunov@...nvz.org>, 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 1:08 PM, H. Peter Anvin <hpa@...or.com> wrote: > 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. It's not just kernel versions -- different toolchains may generate different code. Heck, building from a different directory can sometimes generate different output. The ABI of each vdso function is stable, though -- a sufficiently clever tool could (maybe) use that knowledge along with unwind data in the vdso to fix everything up. This would be interesting, perhaps, but certainly not easy. I say we declare "if you want a working vdso in a weird location, mremap it". But how does userspace figure out what size to pass to mremap? If it's one vma, it's easy. I don't know all that much about the linux vm. Can we create a special vdso address_space or struct inode or something so that a single vma can contain pages with different flags? --Andy -- 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/
Powered by blists - more mailing lists