From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933346AbbHLAib (ORCPT ); Tue, 11 Aug 2015 20:38:31 -0400 Received: from mail-oi0-f46.google.com ([209.85.218.46]:36646 "EHLO mail-oi0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932608AbbHLAi2 (ORCPT ); Tue, 11 Aug 2015 20:38:28 -0400 MIME-Version: 1.0 In-Reply-To: <55CA90B4.2010205@list.ru> References: <55CA90B4.2010205@list.ru> From: Andy Lutomirski Date: Tue, 11 Aug 2015 17:38:07 -0700 Message-ID: Subject: Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu To: Stas Sergeev , X86 ML Cc: Linux kernel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev wrote: > Hi guys, I wonder how easily the include/uapi/* is being > changed these days. > The patch: > http://lkml.kernel.org/r/405594361340a2ec32f8e2b115c142df0e180d8e.1426193719.git.luto@kernel.org > breaks dosemu (and perhaps everyone else who used > to restore the segregs by hands). And the fix involves > both autoconf magic and run-time magic, so it is not even > trivial. > I realize this patch may be good to have in general, but > breaking userspace without a single warning is a bit > discouraging. Seems like the old "we don't break userspace" > rule have gone. I didn't anticipate any breakage. I could have been wrong. Do you know what the actual breakage is? I'm curious how this ever worked for DOSEMU, given that, before this patch, it appeared to be impossible to return to any nonstandard SS from a 64-bit signal handler. FWIW, DOSEMU seems to work for me on recent kernels. We might still be able to require a new sigcontext flag to be set and to forcibly return to __USER_DS if the flag is set regardless of the ss value in sigcontext when sigreturn is called, if that is indeed the problem with DOSEMU. But I'm not actually sure that that's the problem. In fact, DOSEMU contains this: /* set up a frame to get back to DPMI via iret. The kernel does not save %ss, and the SYSCALL instruction in sigreturn() destroys it. IRET pops off everything in 64-bit mode even if the privilege does not change which is nice, but clobbers the high 48 bits of rsp if the DPMI client uses a 16-bit stack which is not so nice (see EMUfailure.txt). Setting %rsp to 0x100000000 so that bits 16-31 are zero works around this problem, as DPMI code can't see bits 32-63 anyway. */ So, if DOSEMU were to realize that both sigreturnissues it's complaining about are fixed in recent kernels, it could sigreturn directly back to any state. (It can't *directly* IRET back to a 16-bit state with properly controlled RSP, but it can do it via sigreturn.) I don't actually see any code in DOSEMU that generates a sigcontext from scratch (as opposed to copying one and modifying it), so I'm not entirely sure what the problem is. --Andy -- Andy Lutomirski AMA Capital Management, LLC