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

From: Andy Lutomirski
Date: Thu Aug 13 2015 - 10:58:55 EST

On Thu, Aug 13, 2015 at 5:44 AM, Stas Sergeev <stsp@xxxxxxx> wrote:
> 13.08.2015 11:39, Ingo Molnar ÐÐÑÐÑ:
>> * Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>>>> OK.
>>>> I'll try to test the patch tomorrow, but I think the sigreturn()'s
>>>> capability detection is still needed to easily replace the iret
>>>> trampoline
>>>> in userspace (without generating a signal and testing by hands).
>>>> Can of course be done with a run-time kernel version check...
>>> That feature is so specialized that I think you should just probe it.
>>> void foo(...) {
>>> sigcontext->ss = 7;
>>> }
>>> modify_ldt(initialize descriptor 0);
>>> sigaction(SIGUSR1, foo, SA_SIGINFO);
>>> if (ss == 7)
>>> yay;
>>> Fortunately, all kernels that restore ss also have espfix64, so you
>>> don't need to worry about esp[31:16] corruption on those kernels
>>> either.
>>> I suppose we could add a new uc_flag to indicate that ss is saved and
>>> restored,
>>> though. Ingo, hpa: any thoughts on that? There will always be some
>>> kernel
>>> versions that save and restore ss but don't set the flag, though.
>> So this new flag would essentially be a 'the ss save/restore bug is fixed
>> for
>> sure' flag, not covering old kernels that happen to have the correct
>> behavior,
>> right?
>> Could you please map out the range of kernel versions involved - which
>> ones:
>> - 'never do the right thing'
>> - 'do the right thing sometimes'
>> - 'do the right thing always, but by accident'
>> - 'do the right thing always and intentionally'
>> ?
>> I'd hate to complicate a legacy ABI any more. My gut feeling is to let
>> apps either
>> assume that the kernel works right, or probe the actual behavior. Adding
>> the flag
>> just makes it easy to screw certain kernel versions that would still work
>> fine if
>> the app used actual probing. So I don't see the flag as an improvement.
>> If your patch fixes the regression that would be a good first step.
> I've tested the patch.
> It doesn't fix the problem.
> It allows dosemu to save the ss the old way, but,
> because dosemu doesn't save it to the sigreturn()'s-expected
> place (sigcontext.__pad0), it crashes on sigreturn().
> So the problem can't be fixed this way --> NACK to the patch.
> I may be unavailable for further testings till next week.

I'm still fighting with getting DOSEMU to run at all in my VM.

I must be missing something. What ends up in ss/__pad0? Wouldn't it
contain whatever signal delivery put there (i.e. some valid ss value)?

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