Message-ID: <CALCETrWBhUOf6hg00Lh2YF+dGJJHgNhBn3z7gbNF7aY+bjO7Vw@mail.gmail.com>
Date:	Thu, 13 Aug 2015 17:24:26 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Stas Sergeev <stsp@...t.ru>, Raymond Jennings <shentino@...il.com>,
	Cyrill Gorcunov <gorcunov@...il.com>,
	Pavel Emelyanov <xemul@...allels.com>,
	Linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: [regression] x86/signal/64: Fix SS handling for signals delivered
 to 64-bit programs breaks dosemu

On Thu, Aug 13, 2015 at 5:08 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Thu, Aug 13, 2015 at 5:00 PM, Stas Sergeev <stsp@...t.ru> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists