From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754028AbbHMWLx (ORCPT ); Thu, 13 Aug 2015 18:11:53 -0400 Received: from mail-ob0-f169.google.com ([209.85.214.169]:35880 "EHLO mail-ob0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752082AbbHMWLw convert rfc822-to-8bit (ORCPT ); Thu, 13 Aug 2015 18:11:52 -0400 MIME-Version: 1.0 In-Reply-To: <55CD13F3.1070904@list.ru> References: <55CA90B4.2010205@list.ru> <55CCD921.4040301@list.ru> <20150813200823.GS2059@uranus> <55CD0F29.4070604@gmail.com> <55CD13F3.1070904@list.ru> From: Andy Lutomirski Date: Thu, 13 Aug 2015 15:11:31 -0700 Message-ID: Subject: Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu To: Stas Sergeev Cc: Linus Torvalds , Raymond Jennings , Cyrill Gorcunov , Pavel Emelyanov , Linux kernel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 13, 2015 at 3:02 PM, Stas Sergeev wrote: > 14.08.2015 00:46, Linus Torvalds пишет: >> >> On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings >> wrote: >>> >>> I am curious about what's supposed to happen normally on signal delivery. >>> >>> Is SS a register that's supposed to be preserved like EIP/RIP and CS when >>> a >>> signal is delivered? >> >> What exactly does "supposed" mean? >> >> On x86-64, we traditionally haven't touched SS, because it doesn't >> really matter in 64-bit long mode. And apparently dosemu depended on >> that behavior. >> >> So clearly, we're not "supposed" to save/restore it. Because reality >> matters a hell of a lot more than any theoretical arguments. > > Unless you introduce some clever flag to explicitly request its restoring. > There is another problem as well which is that gcc assumes > FS base to point to TLS at function prolog. Since FS is not > restored too, the only suggestion I get is to write a sighandlers > in asm... I wonder if someone really should write a sighandler in > asm to restore FS base manually with a syscall. > So I think the reality is asking for a new flag. :) I still don't see how this hypothetical flag would work. The relevant task state consists of FS and the hidden FS base register. If you build with -fstack-protector, GCC really wants the FS base register to point to the right place. So you can't change it in the middle of a C function (because the prologue and epilogue will fail to match). Now suppose you set some magic flag and jump (via sigreturn, trampoline, whatever) into DOS code. The DOS code loads 0x7 into FS and then gets #GP. You land in a signal handler. As far as the kernel's concerned, the FS base register is whatever the base of LDT entry 0 is. What else is the kernel supposed to shove in there? I think that making this work fully in the kernel would require a full-blown FS equivalent of sigaltstack, and that seems like overkill. Now, if it turns out that Oracle or whoever wants to write a JVM that uses WRFSBASE but still handles signals using standard C signal handlers, they're going to have the same problem. They, too, could fix it in libc, or someone could come up with an in-kernel mechanism that gets enabled at the same time as WRFSBASE and is careful not to break existing code. I really think that we want to have a single, coherent change whenever WRFSBASE and WRGSBASE get enabled that covers all the bases. None of the patch sets so far have done that. But this cuts both ways: I don't think we should change FS and GS behavior in signal handlers until we are confident that we know what's happening with the FSGSBASE instructions. --Andy