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

From: Andy Lutomirski
Date: Wed Sep 02 2015 - 15:06:54 EST

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at