Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754109AbbHNAYs (ORCPT ); Thu, 13 Aug 2015 20:24:48 -0400 Received: from mail-ob0-f181.google.com ([209.85.214.181]:36027 "EHLO mail-ob0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752135AbbHNAYr convert rfc822-to-8bit (ORCPT ); Thu, 13 Aug 2015 20:24:47 -0400 MIME-Version: 1.0 In-Reply-To: References: <55CA90B4.2010205@list.ru> <55CCD921.4040301@list.ru> <20150813200823.GS2059@uranus> <55CD0F29.4070604@gmail.com> <55CD13F3.1070904@list.ru> <55CD1968.7070002@list.ru> <55CD1F79.2010508@list.ru> <55CD2F9A.9040300@list.ru> From: Andy Lutomirski Date: Thu, 13 Aug 2015 17:24:26 -0700 Message-ID: Subject: Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu To: Linus Torvalds Cc: Stas Sergeev , 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 Content-Length: 3252 Lines: 68 On Thu, Aug 13, 2015 at 5:08 PM, Linus Torvalds wrote: > On Thu, Aug 13, 2015 at 5:00 PM, Stas Sergeev wrote: >> 14.08.2015 02:00, Andy Lutomirski пишет: >>> >>> DOSEMU, when you set that flag, WRFSBASE gets enabled, and glibc's >>> threading library starts using WRFSBASE instead of arch_prctl. >> >> Hmm, how about the following: >> >> prctl(ARCH_SET_SIGNAL_FS, my_tls) >> If my_tls==NULL - use current fsbase (including one of WRFSBASE). >> If my_tls==(void)-1 - don't restore. >> >> Can this work? > > I'm really inclined to wonder whether we need the change and such a flag at all. > > Basically, no _normal_ application will ever play with segments at all > on x86-64. So our current behavior of not touching any segments at all > for signal handling would seem to be the right thing to do - because > it handles all the sane cases optimally. > > And applications that *do* play with segments very much know they do > so, and we already put the onus on *them* to save/restore segments. > That's how dosemu clearly works today. I agree for all but CS and SS, which are special. CS is fine already. The way that DOSEMU works around SS it is hideous: it just gives up on sigreturn working and fixes the segments with IRET. (Also, if DOSEMU ever wants to get ESP[31:16] right, it *can't*: only the kernel can usefully do espfix64, and DOSEMU can't get the kernel to return from 64-bit code to 16-bit code, because we zap SS. DOSEMU fudges it by forcibly zeroing ESP[31:16]), but that's not a full solution and I wouldn't be surprised if something breaks as a result. So yes, it mostly works. It also sucks, and it makes it extremely unpleasant for any other program to do this. I'd argue that keeping things like the sigreturn_64 test working is quite valuable, because it's a royal PITA to exercise this code cleanly without proper control of SS. Unfortunately, making it hard for sigreturn_64 to exercise this stuff doesn't mean that the bad guys can't do it, because they'll use malformed ELF files, or ptrace, or stupid modify_ldt races (except I hopefully fixed those), or x32, or compat, or some other hack I haven't thought of yet, and they'll hit the same bugs. I've lost count of the number of bugs of various severities that the sigreturn tests have shaken out *and* caught in patches that were emailed in. We could say "forget sigreturn_64, use sigreturn_32 instead", but that can't exercise !IA32_EMULATION kernels, and that code is a bit different. (BadIRET, for example, is nominally unreachable from 64-bit code without modify_ldt and the sigreturn fix, except that I think know of one really nasty way to do it. I have no intention of implementing that, so keeping selftests working nicely makes me *much* more confident.) Obviously, if we reintroduce SS restoration, we need to do it much more carefully. My RFC patches are an attempt to do that, but it needs a lot of care to make sure all the bases are covered. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/