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

[Stas Sergeev]

13.08.2015 17:58, Andy Lutomirski ÐÐÑÐÑ:
> 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)?
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.
--
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/