From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S964814AbbCRTNk (ORCPT <rfc822;w@1wt.eu>);
	Wed, 18 Mar 2015 15:13:40 -0400
Received: from mail-la0-f44.google.com ([209.85.215.44]:32969 "EHLO
	mail-la0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S933047AbbCRTNa (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 18 Mar 2015 15:13:30 -0400
Date: Wed, 18 Mar 2015 22:13:27 +0300
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Andy Lutomirski <luto@amacapital.net>, Andrey Wagin <avagin@gmail.com>,
        Andy Lutomirski <luto@kernel.org>, Ingo Molnar <mingo@kernel.org>,
        Andi Kleen <andi@firstfloor.org>, "H. Peter Anvin" <hpa@zytor.com>,
        Al Viro <viro@zeniv.linux.org.uk>, X86 ML <x86@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Borislav Petkov <bp@alien8.de>, Pavel Emelyanov <xemul@openvz.org>
Subject: Re: [PATCH v3 1/2] x86_64,signal: Fix SS handling for signals
 delivered to 64-bit programs
Message-ID: <20150318191327.GF17491@moon>
References: <cover.1426193719.git.luto@kernel.org>
 <405594361340a2ec32f8e2b115c142df0e180d8e.1426193719.git.luto@kernel.org>
 <CANaxB-yz9BZbU1TLB-kGfR21L_ZUkni9bqL96mK5jgsXAka+KA@mail.gmail.com>
 <20150318174843.GA32238@redhat.com>
 <CALCETrVMvD+yAesUPfTPhM9bs2EkeQq3AwXNA2pdkM2w8CwPcg@mail.gmail.com>
 <20150318181718.GG2255@moon>
 <20150318182522.GA1832@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150318182522.GA1832@redhat.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Mar 18, 2015 at 07:25:22PM +0100, Oleg Nesterov 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.

True (and this applies to quotes below). Hopefully it won't be changed frequently
though ;) As to seg registers sure the safe way as Andy pointed is to fetch them
runtime on the machine we're restoring. Thanks, I will update our code!

> 
> But in this case "restore on another machine" or "restore after kernel
> upgrade" can fail.
> 
> So probably restore_gpregs() should only change the general-purpose regs,
> as its name suggests.