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

[Andy Lutomirski]

On Wed, Sep 2, 2015 at 11:23 AM, Stas Sergeev <stsp@xxxxxxx> wrote:
> 02.09.2015 21:17, Andy Lutomirski ÐÐÑÐÑ:
>> On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev <stsp@xxxxxxx> 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?

What's the exact siglongjmp usage you have in mind?  Signal context
isn't normally involved AFAIK.

>
>>>>> - 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?

I'm still not understanding what you're looking for.  If you
siglongjmp out of a signal handler, the hardware SS value is
irrelevant, at least on 64-bit binaries, because siglongjmp is just
going to replace it.

>
>>>>> 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().

For 64-bit delivery, ignoring backwards compatibility, delivering
signals with ss = __USER_DS would be the right solution, I think: it's
trivial and it works.  Because of backwards compatibility, we need to
deliver signals with ss preserved when possible unless the program
opts out.  But I don't see why new programs would care what SS is,
since it has no effect during 64-bit code execution unless you read it
directly or long jmp/long ret to non-64-bit mode.

--Andy
--
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/