[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrUJS9kgNgggbnYJrLr93ARtocZBAGDVuudWahM7JhQuwQ@mail.gmail.com>
Date: Thu, 13 Aug 2015 15:29:43 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Stas Sergeev <stsp@...t.ru>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
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 3:25 PM, Stas Sergeev <stsp@...t.ru> wrote:
> 14.08.2015 01:11, Andy Lutomirski пишет:
>
>> 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?
>
> The same as what happens when you do in userspace:
> ---
> asm ("mov $0,%%fs\n");
> prctl(ARCH_SET_FS, my_tls_base);
> ---
>
> This was the trick I did before gcc started to use FS in prolog,
> now I have to do this in asm.
> But how simpler for the kernel is to do the same?
>
>> I think that making this work fully in the kernel would require a
>> full-blown FS equivalent of sigaltstack, and that seems like overkill.
>
> Setting selector and base is what you call an "equivalent of sigaltstack"?
Yes. sigaltstack says "hey, kernel! here's my SP for signal
handling." I think we'd need something similar to tell the kernel
what my_tls_base is. Using the most recent thing passed to
ARCH_SET_FS is no good because WRFSBASE systems might not use
ARCH_SET_FS, and we can't break DOSEMU on Ivy Bridge and newer as soon
as we enable WRFSBASE.
--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