Date:	Thu, 3 Sep 2015 02:01:32 +0300
From:	Stas Sergeev <stsp@...t.ru>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Raymond Jennings <shentino@...il.com>,
	Cyrill Gorcunov <gorcunov@...il.com>,
	Pavel Emelyanov <xemul@...allels.com>,
	Linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: [regression] x86/signal/64: Fix SS handling for signals delivered
 to 64-bit programs breaks dosemu

03.09.2015 01:25, Andy Lutomirski пишет:
> On Wed, Sep 2, 2015 at 3:25 PM, Stas Sergeev <stsp@...t.ru> wrote:
>
>>>> How dosemu2 is supposed to do this:
>>>> 1. sigreturn() (to DOS)
>>>> 2. siglongjmp() (to 64bit C-coded)
>>> This should work fine on any kernel, right?
>> 1 - not.
>> 2 - maybe.
>> If, as you say, siglongjmp() restores SS, I need to try it out.
>> (there is also a problem that most siglongjmp() implementations
>> are incompatible with sigaltstack(), but this is not what you can fix).
>>
> 1 - definitely needs kernel changes.  I was referring to #2.
>
> 2 - siglongjmp probably varies in its behavior across different libc
> implementations.  My point is that siglongjmp isn't a kernel-provided
> thing.
So if siglongjmp() restores SS by the side-effect of doing a sigprocmask()
syscall, this admittedly weakens my point.
The unreliability then stays only with the async signals interrupting
the main one.

>>> For backwards compat, we either need the default behavior to be
>>> unchanged, or we need the default behavior to be something that works
>>> with existing dosemu.  For existing dosemu, the only interesting cases
>>> (I think) are signal delivery from *valid* 16-bit context, in which
>>> case we need to preserve SS so that the signal handler can read it out
>>> with mov ..., %ss, and sigreturn to 64-bit mode for the IRET
>>> trampoline.  For sigreturn, IIUC old dosemu will replace the saved CS
>>> with a 64-bit code segment selector and won't touch the saved SS
>>> because it doesn't know about the saved SS.  Those dosemu versions
>>> don't care what SS actually contains after sigreturn, because they're
>>> immediately going to change it again using IRET.  So we just need to
>>> make sure we return without faulting.
>>>
>>> New dosemu2 would like to sigreturn directly back to 16-bit mode, so
>>> it needs the kernel to honor the saved ss value and restore it,
>>> possibly changed by dosemu.
>>>
>>> We obviously can't require old dosemu to set an SA flag to keep
>>> working.  But, if we can get away with it, I think it's somewhat
>>> preferable not to require new DOSEMU to set an SA flag either.
>>>
>>> This has one major benefit at least: if new dosemu loads some random
>>> library that installs some async signal handler (SIGALRM for example),
>>> everything will work with regard to CS and SS.
>> This case is covered if we do both things together: use
>> your heuristic when SA_hyz is not set, and don't use it
>> when its set. In this case dosemu2 will be able to request
>> the proper SS delivery for its sighandlers, but the 3rd-party
>> sighandlers will work too.
>> I think we have never discussed the possibility of doing
>> both things together, even though I have proposed it many
>> times.
>> After discussing this full-blown solution, we can think about
>> reducing it, either by removing the heuristic or by removing
>> SA_hyz, but discussing the full one would be nice too.
>> Your opinion is likely that no one will use this SA_hyz in
>> presence of the heuristic that "seems to work anyway".
>> But in the light of extending it for TLS (with a new flag),
>> I wouldn't be so sure. You can also document it as a
>> needed flag when user code touches SS, and then it will
>> be used. dosemu1 code that doesn't use it, will eventually
>> be forgotten. So IMHO whether it will be used, is fully up
>> to how will you market it. :)
> I'll think about it.  I'll think about FS and GS, too,
OK, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists