Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu
From: Stas Sergeev
Date: Thu Aug 13 2015 - 13:14:17 EST
13.08.2015 19:59, Andy Lutomirski ÐÐÑÐÑ:
On Thu, Aug 13, 2015 at 9:48 AM, Stas Sergeev <stsp@xxxxxxx> wrote:
13.08.2015 19:42, Andy Lutomirski ÐÐÑÐÑ:
On Thu, Aug 13, 2015 at 9:38 AM, Stas Sergeev <stsp@xxxxxxx> wrote:
13.08.2015 19:24, Andy Lutomirski ÐÐÑÐÑ:
On Thu, Aug 13, 2015 at 9:20 AM, Stas Sergeev <stsp@xxxxxxx> wrote:
13.08.2015 19:09, Andy Lutomirski ÐÐÑÐÑ:
On Thu, Aug 13, 2015 at 9:03 AM, Stas Sergeev <stsp@xxxxxxx> wrote:
13.08.2015 18:38, Andy Lutomirski ÐÐÑÐÑ:
So... what do we do about it? We could revert the whole mess. We
could tell everyone to fix their DOSEMU, which violates policy and
is
especially annoying given how much effort we've put into keeping
16-bit mode fully functional lately. We could add yet more
heuristics
and teach sigreturn to ignore the saved SS value in sigcontext if
the
saved CS is 64-bit and the saved SS is unusable.
Andy, why do you constantly ignore the proposal to make
new behaviour explicitly controlable? You don't have to agree
with it, but you could at least comment on that possibility
and/or mention it with the ones you listed above.
I'm not sure what the proposal is exactly.
We could add a new uc_flags flag. If set, it means that
sigcontext->ss is valid and should be used by sigreturn. If clear,
then we ignore sigcontext->ss and just restore __USER_DS.
The problem is that, by itself, this won't fix old DOSEMU. We somehow
need to either detect that something funny is going on or just leave
the flag clear by default.
We could do this: always save SS to sigcontext->ss, but only restore
sigcontext->ss if userspace explicitly sets the flag before sigreturn.
If we do that, we'd need to also add my patch to preserve the actual
HW SS selector if possible so that old DOSEMU knows what SS to program
into its trampoline.
This at least lets *new* DOSEMU set the flag and get the improved
behavior. I still don't know what effect it'll have on Wine and CRIU.
Stas, is that what you were thinking, or were you thinking of
something
else?
Not quite.
I mean the flag that will control not only sigreturn, but
the signal delivery as well. This may probably be a sigaction()
flag or some other. If not set - ss is ignored by both signal
delivery and sigreturn(). If set - ss is saved/restored (and in
the future - also fs/gs).
Is such a flag possible?
Maybe. I think I'm more nervous about adding new flags in sigaction
than I am in uc_flags.
Isn't uc_flags read-only for the user?
I look into setup_rt_frame
<http://lxr.free-electrons.com/ident?v=2.4.37;i=setup_rt_frame>() and see
---
/* Create the ucontext. */
err |= __put_user(0, &frame->uc.uc_flags);
---
so it doesn't look like the flag that user can use to _request_
something from the kernel. And I am talking about exactly
the flag to request the new behaviour, as only that can remove
the regression completely without patching dosemu.
User code could rewrite it in the signal handler to request something.
But that's too late to affect the signal _delivery_ anyhow, no?
Any idea about the flag that can control both delivery and return?
I think my LAR patch should cover the signal delivery part.
Ah, I see your point now.
But that's not what I mean, as it doesn't cover fs/gs, which
is what Linus is looking to revert now too (I am building the
testing kernels now).
So you obviously don't want the flag that will control all 3
things together without any lar heuristics, but I don't understand why...
Yes, your heuristic+uc_flag may work, but IMHO far from
perfection and TLS problem is not covered. I can test such
a patch but I don't understand why you don't want the flag
that will just control all things together.
--
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/