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: Wed, 18 Mar 2015 11:32:25 -0700 From: Andy Lutomirski <luto@...capital.net> To: Oleg Nesterov <oleg@...hat.com> Cc: Cyrill Gorcunov <gorcunov@...il.com>, Andrey Wagin <avagin@...il.com>, Andy Lutomirski <luto@...nel.org>, Ingo Molnar <mingo@...nel.org>, Andi Kleen <andi@...stfloor.org>, "H. Peter Anvin" <hpa@...or.com>, Al Viro <viro@...iv.linux.org.uk>, X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Borislav Petkov <bp@...en8.de>, Pavel Emelyanov <xemul@...nvz.org> Subject: Re: [PATCH v3 1/2] x86_64,signal: Fix SS handling for signals delivered to 64-bit programs On Wed, Mar 18, 2015 at 11:25 AM, Oleg Nesterov <oleg@...hat.com> wrote: > On 03/18, Cyrill Gorcunov wrote: >> >> On Wed, Mar 18, 2015 at 11:06:00AM -0700, Andy Lutomirski wrote: >> > > --- a/arch/x86/crtools.c >> > > +++ b/arch/x86/crtools.c >> > > @@ -475,6 +475,7 @@ int restore_gpregs(struct rt_sigframe *f, UserX86RegsEntry *r) >> > > CPREG2(rip, ip); >> > > CPREG2(eflags, flags); >> > > CPREG1(cs); >> > > + CPREG1(ss); >> > > CPREG1(gs); >> > > CPREG1(fs); >> > >> > Huh? Is CRIU actually trying to build an entire sigcontext from >> > scratch here? I don't see how this can reliably work across kernel >> > versions or CPU versions. >> >> Yes we are. And why it can't work reliably? As to CPU -- we're >> testing that cpu features saved in image should match ones >> provided by the kernel runtime, ie on the machine where we're >> restoring. > > But, say, __USER_CS can be changed in kernel, and nobody should notice this. This actually happens on a regular basis. Has anyone tried checkpointing on Xen and restoring on native? Xen does interesting things to cs and possibly to ss as well on x86. You get somewhat of a free pass on ds and es because the kernel's context switch code is very tolerant of failures there. --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