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 S1756514AbbCRSpv (ORCPT <rfc822;w@1wt.eu>);
	Wed, 18 Mar 2015 14:45:51 -0400
Received: from mail-lb0-f178.google.com ([209.85.217.178]:35217 "EHLO
	mail-lb0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1754803AbbCRSps (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 18 Mar 2015 14:45:48 -0400
Date: Wed, 18 Mar 2015 21:45:45 +0300
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Oleg Nesterov <oleg@redhat.com>, 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: <20150318184545.GA17491@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>
 <CALCETrXzMMiMFodL5g5c=9Eb-UWV+1J4PeUDiKPtEn70XqmRrg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALCETrXzMMiMFodL5g5c=9Eb-UWV+1J4PeUDiKPtEn70XqmRrg@mail.gmail.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 11:20:08AM -0700, Andy Lutomirski wrote:
> >
> > Basically the initial registers values are fetched with ptrace
> > when program is been dumped, then on restore we copy them back
> > into sigcontext. That said we don't mangle fs/gs anyhow simply
> > restore the values back from dump.
> 
> Wouldn't it be a little safer to have the kernel make you a sane
> sigcontext by raising a signal and catching it rather than writing a
> new one from scratch?  Grr, maybe the kernel should version its
> sigcontext structures.

I think it would, thanks for the point! I'll tune up our code.

> Getting fs from ptrace and restoring it to sigcontext is useless --
> ptrace handles fs correctly, but that sigcontext field is just
> padding.
> 
> Is CRIU at least reliably putting zero in the ss field?  If so, we
> could add a special case to translate zero to __USER_DS on restore.
> (And then I'll update my test case, and we'll have to document it,
> etc.)

Well, it should but need to check (we are tryin to not zeroify
things until really needed in a sake of speed).