Message-ID: <55E73EB5.5040204@list.ru>
Date:	Wed, 2 Sep 2015 21:23:49 +0300
From:	Stas Sergeev <stsp@...t.ru>
To:	Andy Lutomirski <luto@...capital.net>
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

02.09.2015 21:17, Andy Lutomirski пишет:
> 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.
Could you please clarify?
If kernel always passes the right SS to the sighandler, then what's
the problem?

>>>> - 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. :-/
Except for passing the SS=__USER_DS to the sighandler, for which we
discussed the new SA_hyz?

>>>> 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 am much more bothered with delivering the right SS than with
restoring it on sigreturn().
--
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