Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu
From: Linus Torvalds
Date: Thu Aug 13 2015 - 12:34:43 EST
On Thu, Aug 13, 2015 at 9:23 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
> On Thu, Aug 13, 2015 at 9:19 AM, Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>> So how about this "alternate" minimal patch instead. The difference is:
>> - we actually leave the
>> regs->ss = __USER_DS;
>> in __setup_rt_frame, to guarantee that when we take a signal, we do
>> take it with a valid SS
> That by itself is enough to break DOSEMU. I think we may be stuck
> with my hack to only replace regs->ss if the old one was invalid.
Are you sure? From the description by Stas, the problem is literally
the *restoring* action of the sigcontext, and trying to restore a SS
value that is no longer valid.
"The crash happens when DOS program terminates.
At that point dosemu subverts the execution flow by
replacing segregs and cs/ip ss/sp in sigcontext with its own.
But __pad0 still has DOS SS, which crash because (presumably)
the DOS LDT have been just removed"
and my "truly-minimal" patch removes all of the sigcontext games.
> You mean that we always set ss to __USER_DS on sigreturn?
No. We never touch SS at sigreturn time at all. Only when entering the
signal *handler* do we reset things to a known state. The signal
handler can do anything it wants, and sigreturn won't touch it (which
will obviously _leave_ it as __USER_DS, but avoids the problem with
sigreturn trying to load an SS that is no longer valid)
> If this regression were new in 4.2-rc, then I'd say revert first and
> ask questions later, but the regression is in 4.1 as well :(
Big deal. That's why we have the "cc stable". Distributions that ship
with 4.1 are still fairly few (but it's a LTS release so it will grow)
but they all pick up stable kernels.
And even if they temporarily have a broken situation, it's still
better to make sure that broken situation gets fixed, rather than say
"oh well, too late to do anything about it now".
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/