Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

14.08.2015 01:11, Andy Lutomirski ÐÐÑÐÑ:
> On Thu, Aug 13, 2015 at 3:02 PM, Stas Sergeev <stsp@xxxxxxx> wrote:
> > 14.08.2015 00:46, Linus Torvalds ÐÐÑÐÑ:
> > > On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings <shentino@xxxxxxxxx>
> > > 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?
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"?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/