Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context

[Stas Sergeev]

14.10.2015 21:52, Andy Lutomirski ÐÐÑÐÑ:
> On Wed, Oct 14, 2015 at 11:34 AM, Stas Sergeev <stsp@xxxxxxx> wrote:
> > 14.10.2015 21:06, Andy Lutomirski ÐÐÑÐÑ:
> > > > Also it doesn't seem to be saying what happens if CS is 32-bit
> > > > and SS is invalid (the flag is not set).
> > > A new signal will be delivered.  sigreturn doesn't modify its behavior
> > > in this case -- it does the default thing, which is to honor the SS in
> > > the saved context.
> > Hmm, no, it didn't do this in the past for sure.
> > It simply ignored SS, no matter to what mode it returns.
> What I mean is: it has the behavior it would have normally on a new
> kernel, which is to honor the saved SS.  I'll try to improve the
> comment.
>
> > >   So it will actually try to use that saved SS
> > > value, which will fail, causing SIGSEGV.
> > So it seems this logic assumes that when dosemu returns to 32bit,
> > the previous SS is always still valid, am I right with the understanding?
> > I.e. the one that kernel have saved on a signal delivery (because
> > old dosemu does not overwrite it).
> > If it is so, I'd say this assumption is very risky and will likely
> > not hold. But maybe I am missing the point.
> That's the assumption.  If I understand correctly, though, old DOSEMU
> never actually returns to 32-bit using sigreturn in the first place,
> since old kernels gave no control over SS.  Doesn't old DOSEMU always
> return to the 64-bit IRET trampoline?
Ah, so the old progs simply never return to 32bit, so you
implement the "Right Thing" (tm) for them, thanks. So the whole
point of UC_STRICT_RESTORE_SS flag is not for the software to
control it, but just for the kernel itself, so that it knows from
whether 32 or 64 bit the signal came. This is probably quite
undocumented in both the comments and the patch description,
and I was confused because the approaches we discussed before,
were targeted on the flag that is written by user-space. If this my
understanding is correct and the flag is just an indication rather
than a requested action, perhaps the name should be different,
e.g. UC_SIG_FROM_32BIT or the like?
Anyway, this is minor. :)
I'll try to test the patch within a few days, thanks for you time!
--
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/