From: Stas Sergeev <stsp@list.ru>
To: Andy Lutomirski <luto@amacapital.net>, X86 ML <x86@kernel.org>
Cc: Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu
Date: Wed, 12 Aug 2015 11:02:39 +0300 [thread overview]
Message-ID: <55CAFD9F.2070001@list.ru> (raw)
In-Reply-To: <CALCETrVosDi8eTYpH+Z-PA30PdyR6-zM51Rrb-eDXo3WaGqZXg@mail.gmail.com>
12.08.2015 03:38, Andy Lutomirski пишет:
> On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev <stsp@list.ru> wrote:
>> Hi guys, I wonder how easily the include/uapi/* is being
>> changed these days.
>> The patch:
>> http://lkml.kernel.org/r/405594361340a2ec32f8e2b115c142df0e180d8e.1426193719.git.luto@kernel.org
>> breaks dosemu (and perhaps everyone else who used
>> to restore the segregs by hands). And the fix involves
>> both autoconf magic and run-time magic, so it is not even
>> trivial.
>> I realize this patch may be good to have in general, but
>> breaking userspace without a single warning is a bit
>> discouraging. Seems like the old "we don't break userspace"
>> rule have gone.
> I didn't anticipate any breakage. I could have been wrong.
You changed include/uapi/*, which is obviously an asking
for problems. I applied the following changes to my local
git tree to get dosemu working again:
https://github.com/stsp/dosemu2/commit/48b2a13a49a9fe1a456cd77df6b9a1feec675a01
https://github.com/stsp/dosemu2/commit/7898ac60d5e569964127d6cc48f592caecd20b81
> Do you know what the actual breakage is? I'm curious how this ever
> worked for DOSEMU, given that, before this patch, it appeared to be
> impossible to return to any nonstandard SS from a 64-bit signal
> handler.
This is not the point.
What dosemu wants is to simply save the DOS SS somewhere.
After your patch, it saves the Linux SS instead, then crashes.
> FWIW, DOSEMU seems to work for me on recent kernels.
Do you have any protected mode DOS program to test?
I'll send you one in a private e-mail just about now.
> We might still be able to require a new sigcontext flag to be set and
> to forcibly return to __USER_DS if the flag is set regardless of the
> ss value in sigcontext when sigreturn is called, if that is indeed the
> problem with DOSEMU. But I'm not actually sure that that's the
> problem.
Well, the flag would be an ideal solution in an ideal world,
but in our world I don't know the current relevance of dosemu,
and whether or not it worth a new flag to add.
> In fact, DOSEMU contains this:
>
> /* set up a frame to get back to DPMI via iret. The kernel does not save
> %ss, and the SYSCALL instruction in sigreturn() destroys it.
>
> IRET pops off everything in 64-bit mode even if the privilege
> does not change which is nice, but clobbers the high 48 bits
> of rsp if the DPMI client uses a 16-bit stack which is not so
> nice (see EMUfailure.txt). Setting %rsp to 0x100000000 so that
> bits 16-31 are zero works around this problem, as DPMI code
> can't see bits 32-63 anyway.
> */
>
> So, if DOSEMU were to realize that both sigreturnissues it's
> complaining about are fixed in recent kernels, it could sigreturn
> directly back to any state.
Good, but have you added any flag for dosemu to even know
it can do this? Unless I am mistaken, you didn't. So the fix you
suggest, is not easy to detect and make portable with the older
kernels. Any suggestions?
> I don't actually see any code in DOSEMU that generates a sigcontext
It doesn't. But it manually pops the kernel-generated
sigcontext, see dpmisel.S:DPMI_direct_transfer.
This part didn't broke though, so no need to look there in fact.
> from scratch (as opposed to copying one and modifying it), so I'm not
> entirely sure what the problem is.
Now you have the changes I did to get it working, and I'll
also mail you a simple test-case. Let me know if you need
something else.
The more important question is whether we ignore dosemu
or some actions should be taken. Since you changed uapi/*,
my initial guess was that you opt for ignoring it, but maybe
this was not the point.
next prev parent reply other threads:[~2015-08-12 8:28 UTC|newest]
Thread overview: 121+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-12 0:17 [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev
2015-08-12 0:38 ` Andy Lutomirski
2015-08-12 8:02 ` Stas Sergeev [this message]
2015-08-12 16:19 ` Andy Lutomirski
2015-08-12 17:00 ` Stas Sergeev
2015-08-12 18:25 ` Andy Lutomirski
2015-08-12 18:55 ` Stas Sergeev
2015-08-12 19:20 ` Andy Lutomirski
2015-08-12 19:55 ` Stas Sergeev
2015-08-12 20:01 ` Andy Lutomirski
2015-08-12 20:14 ` Stas Sergeev
2015-08-12 20:28 ` Andy Lutomirski
2015-08-12 20:45 ` Stas Sergeev
2015-08-12 20:47 ` Andy Lutomirski
2015-08-12 20:55 ` Stas Sergeev
2015-08-12 21:37 ` Andy Lutomirski
2015-08-12 21:50 ` Stas Sergeev
2015-08-12 22:00 ` Andy Lutomirski
2015-08-13 8:39 ` Ingo Molnar
2015-08-13 10:14 ` Stas Sergeev
2015-08-13 12:44 ` Stas Sergeev
2015-08-13 14:58 ` Andy Lutomirski
2015-08-13 15:22 ` Stas Sergeev
2015-08-13 15:38 ` Andy Lutomirski
2015-08-13 16:03 ` Stas Sergeev
2015-08-13 16:09 ` Andy Lutomirski
2015-08-13 16:20 ` Stas Sergeev
2015-08-13 16:24 ` Andy Lutomirski
2015-08-13 16:38 ` Stas Sergeev
2015-08-13 16:42 ` Andy Lutomirski
2015-08-13 16:48 ` Stas Sergeev
2015-08-13 16:59 ` Andy Lutomirski
2015-08-13 17:13 ` Stas Sergeev
2015-08-13 17:17 ` Andy Lutomirski
2015-08-13 18:00 ` Stas Sergeev
2015-08-13 18:05 ` Andy Lutomirski
2015-08-13 18:19 ` Stas Sergeev
2015-08-13 18:25 ` Andy Lutomirski
2015-08-13 18:35 ` Stas Sergeev
2015-08-22 12:38 ` Ingo Molnar
2015-08-22 14:19 ` Stas Sergeev
2015-08-23 6:25 ` Ingo Molnar
2015-08-13 11:08 ` Stas Sergeev
2015-08-13 15:37 ` Linus Torvalds
2015-08-13 15:43 ` Andy Lutomirski
2015-08-13 16:19 ` Linus Torvalds
2015-08-13 16:23 ` Andy Lutomirski
2015-08-13 16:34 ` Linus Torvalds
2015-08-13 16:43 ` Linus Torvalds
2015-08-13 16:44 ` Andy Lutomirski
2015-08-13 17:00 ` Brian Gerst
2015-08-18 6:29 ` Stas Sergeev
2015-08-18 22:42 ` Andy Lutomirski
2015-08-18 22:47 ` Andy Lutomirski
2015-08-19 9:35 ` Stas Sergeev
2015-08-19 15:46 ` Andy Lutomirski
2015-08-19 16:30 ` Stas Sergeev
2015-09-02 5:12 ` Andy Lutomirski
2015-09-02 9:17 ` Stas Sergeev
2015-09-02 14:21 ` Andy Lutomirski
2015-09-02 15:02 ` Andy Lutomirski
2015-09-02 17:46 ` Stas Sergeev
2015-09-02 18:17 ` Andy Lutomirski
2015-09-02 18:23 ` Stas Sergeev
2015-09-02 19:06 ` Andy Lutomirski
2015-09-02 21:01 ` Stas Sergeev
2015-09-02 21:39 ` Andy Lutomirski
2015-09-02 22:25 ` Stas Sergeev
2015-09-02 22:25 ` Andy Lutomirski
2015-09-02 23:01 ` Stas Sergeev
2015-08-19 10:10 ` Stas Sergeev
2015-08-19 15:35 ` Andy Lutomirski
2015-08-14 8:10 ` Cyrill Gorcunov
2015-08-13 17:51 ` Stas Sergeev
2015-08-13 18:35 ` Linus Torvalds
2015-08-13 18:41 ` Andy Lutomirski
2015-08-13 19:05 ` Stas Sergeev
2015-08-13 19:49 ` Andy Lutomirski
2015-08-13 20:09 ` Stas Sergeev
2015-08-13 19:53 ` Linus Torvalds
2015-08-13 20:08 ` Cyrill Gorcunov
2015-08-13 20:09 ` Linus Torvalds
2015-08-13 21:42 ` Raymond Jennings
2015-08-13 21:46 ` Linus Torvalds
2015-08-13 22:01 ` Raymond Jennings
2015-08-13 22:05 ` Stas Sergeev
2015-08-13 23:05 ` Linus Torvalds
2015-08-13 23:18 ` Linus Torvalds
2015-08-13 23:35 ` Raymond Jennings
2015-08-13 23:43 ` Stas Sergeev
2015-08-14 0:02 ` Linus Torvalds
2015-08-13 22:02 ` Stas Sergeev
2015-08-13 22:11 ` Andy Lutomirski
2015-08-13 22:25 ` Stas Sergeev
2015-08-13 22:29 ` Andy Lutomirski
2015-08-13 22:51 ` Stas Sergeev
2015-08-13 23:00 ` Andy Lutomirski
2015-08-13 23:17 ` Stas Sergeev
2015-08-14 0:00 ` Stas Sergeev
2015-08-14 0:05 ` Andy Lutomirski
2015-08-14 0:17 ` Stas Sergeev
2015-08-14 0:27 ` Linus Torvalds
2015-08-14 0:50 ` Stas Sergeev
2015-08-14 1:21 ` Andy Lutomirski
2015-08-14 1:32 ` Stas Sergeev
2015-08-14 1:37 ` Andy Lutomirski
2015-08-14 2:03 ` Stas Sergeev
2015-08-18 6:19 ` Stas Sergeev
2015-08-14 0:08 ` Linus Torvalds
2015-08-14 0:24 ` Andy Lutomirski
2015-08-14 0:40 ` Linus Torvalds
2015-08-14 7:22 ` Cyrill Gorcunov
2015-08-14 10:02 ` Pavel Emelyanov
2015-08-14 10:53 ` Cyrill Gorcunov
2015-08-13 18:57 ` Stas Sergeev
2015-08-13 19:01 ` Andy Lutomirski
2015-08-13 19:13 ` Stas Sergeev
2015-08-13 19:37 ` Linus Torvalds
2015-08-13 19:59 ` Stas Sergeev
2015-08-13 20:07 ` Linus Torvalds
2015-08-18 6:40 ` Stas Sergeev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55CAFD9F.2070001@list.ru \
--to=stsp@list.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.