Message-ID: <CALCETrWdC9PHQ0OfZrk4zbTM3G8hNnk+wWjFxTdTFgRcBbD4Tw@mail.gmail.com>
Date:	Wed, 2 Sep 2015 11:17:51 -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 Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev <stsp@...t.ru> wrote:
> 02.09.2015 17:21, Andy Lutomirski пишет:
>>>> This should work for old DOSEMU.  It's a bit gross, but it has the
>>>> nice benefit that everyone (even things that aren't DOSEMU) gain the
>>>> ability to catch signals thrown from bogus SS contexts, which probably
>>>> improves debugability.  It's also nice to not have the SA flag.
>>>
>>> Pros:
>>> - No new SA flag
>>> - May improve debugability in some unknown scenario where people
>>> do not want to just use the new flag to get their things improved
>>>
>>> Cons:
>>> - Does not allow to cleanly use siglongjmp(), as then there is a risk
>>> to jump to 64bit code with bad SS
>>
>> What's the issue here?  I don't understand.
>>
>> On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it
>> won't be affected.  AFAIK all implementations of siglongjmp are likely
>> to call sigprocmask or similar, and that will clobber SS.  I'm not
>> aware of an implementation of siglongjmp that uses sigreturn.
> I am not saying siglongjmp() will be affected.
> Quite the opposite: it won't, which is bad. :)
> If you have always correct SS, you can use siglongjmp(). If you have
> broken SS at times, siglongjmp() will be an asking for troubles, as
> it exactly does not restore SS.
> dosemu could do a good use of siglongjmp() to get back to 64bit code
> from its sighandler.

This seems like it would be relying unpleasantly heavily on libc internals.

What *does* work is to raise a signal and stash away the entire signal
context.  Then raise another signal and restore the old context.  Of
course, this needs SS support in sigcontext, and may still need to
handle DS and ES manually.

>
>>> - Async signals can silently "validate" SS behind your back
>>
>> True, and that's unfortunate.  But async signals without SA_SAVE_SS
>> set with the other approach have exactly the same problem.
> Yes, and as such, they should be blocked.
> You could improve on that and on siglongjmp().
> And on TLS in the future.

*I* can't do anything to siglongjmp because that's almost entirely
outside the kernel. :-/

>
>>> Is the new SA flag such a big deal here to even bother?
>>
>> Not really, but given that the new behavior seems clearly better
>> behaved than the old, it would be nice to be able to have the good
>> behavior, or at least most of it, be the default.
> Surely, but how about then having the heuristics you suggest,
> only if the new SA_hyz is not set? And when it is set, have a
> properly defined and predictable behaviour. Then it seems like
> we'll get all the possible wishes covered.

That could work.  The result is quite similar to explicitly setting
UC_STRICT_RESTORE_SS.

I'll draft up an implementation and we can go from there.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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