Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1205516 > unrolled thread
| Started by | Stas Sergeev <stsp@list.ru> |
|---|---|
| First post | 2015-08-12 02:20 +0200 |
| Last post | 2015-08-13 22:10 +0200 |
| Articles | 20 on this page of 105 — 8 participants |
Back to article view | Back to linux.kernel
[regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-12 02:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-12 02:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-12 10:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-12 18:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-12 19:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-12 20:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-12 21:00 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-12 21:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-12 22:00 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-12 22:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-12 22:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-12 22:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-12 22:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-12 23:00 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-12 23:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 00:00 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 00:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Ingo Molnar <mingo@kernel.org> - 2015-08-13 10:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 12:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 14:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 17:00 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 17:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 17:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 18:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 18:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 18:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 18:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 18:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 18:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 19:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 19:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 19:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 20:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 20:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 20:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 20:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 20:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 18:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 13:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-12 22:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-13 17:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 17:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-13 18:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 18:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-13 18:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 18:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-13 18:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Brian Gerst <brgerst@gmail.com> - 2015-08-13 19:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-18 08:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-19 00:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-19 11:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-19 17:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-19 18:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-19 00:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-19 12:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-19 17:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Cyrill Gorcunov <gorcunov@gmail.com> - 2015-08-14 10:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 20:00 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-13 20:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 20:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 21:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 21:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 22:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-13 22:00 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Cyrill Gorcunov <gorcunov@gmail.com> - 2015-08-13 22:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-13 22:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Raymond Jennings <shentino@gmail.com> - 2015-08-13 23:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-13 23:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Raymond Jennings <shentino@gmail.com> - 2015-08-14 00:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-14 00:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-14 01:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-14 01:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Raymond Jennings <shentino@gmail.com> - 2015-08-14 01:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-14 01:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-14 02:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-14 00:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-14 00:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-14 00:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-14 00:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-14 01:00 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-14 01:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-14 01:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-14 02:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-14 02:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-14 02:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-14 03:00 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-14 03:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-14 03:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-14 04:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-18 08:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-14 03:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-14 02:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-14 02:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-14 02:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-14 02:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Cyrill Gorcunov <gorcunov@gmail.com> - 2015-08-14 09:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Pavel Emelyanov <xemul@parallels.com> - 2015-08-14 12:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Cyrill Gorcunov <gorcunov@gmail.com> - 2015-08-14 13:00 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 21:00 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 21:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 21:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-13 21:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-13 22:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-18 08:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 22:10 +0200
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-08-13 17:00 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX294-6rZ-23@gated-at.bofh.it> |
| In reply to | #1206790 |
On Thu, Aug 13, 2015 at 5:44 AM, Stas Sergeev <stsp@list.ru> wrote:
> 13.08.2015 11:39, Ingo Molnar пишет:
>>
>> * Andy Lutomirski <luto@amacapital.net> 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)?
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-08-13 17:30 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX2C6-7ft-23@gated-at.bofh.it> |
| In reply to | #1206891 |
13.08.2015 17:58, Andy Lutomirski пишет:
> On Thu, Aug 13, 2015 at 5:44 AM, Stas Sergeev <stsp@list.ru> wrote:
>> 13.08.2015 11:39, Ingo Molnar пишет:
>>> * Andy Lutomirski <luto@amacapital.net> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-08-13 17:40 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX2LM-7qM-25@gated-at.bofh.it> |
| In reply to | #1206917 |
On Thu, Aug 13, 2015 at 8:22 AM, Stas Sergeev <stsp@list.ru> wrote:
> 13.08.2015 17:58, Andy Lutomirski пишет:
>
>> On Thu, Aug 13, 2015 at 5:44 AM, Stas Sergeev <stsp@list.ru> wrote:
>>>
>>> 13.08.2015 11:39, Ingo Molnar пишет:
>>>>
>>>> * Andy Lutomirski <luto@amacapital.net> 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.
That's unfortunate.
I don't really know what to do about this. My stupid heuristic for
signal delivery seems unlikely to cause problems, but I'm not coming
up with a great heuristic for detecting when a program that *modifies*
sigcontext hasn't set all the fields. Even adding a flag won't really
help here, since DOSEMU won't know to manipulate the flag.
Ingo, here's the situation, assuming I remember the versions right:
v4.0 and before: If we try to deliver a signal while SS is bad, we
fail and the process dies. If SS is good but nonstandard, we end up
in the signal handler with whatever SS value was loaded when the
signal was sent. We do *not* put SS anywhere in the sigcontext, so
the only way for a program to figure out what SS was is to look at the
HW state before making any syscalls. We also don't even try to
restore SS, so SS is unconditionally set to __USER_DS, necessitating
nasty workarounds (and breaking all kinds of test cases).
v4.1 and current -linus: We always set SS to __USER_DS when delivering
a signal. We save the old SS in the sigcontext and restore it, just
like 32-bit signals.
My patch: We leave SS alone when delivering a signal, unless it's
invalid, in which case we replace it with __USER_DS. We still save
the old SS in the sigcontext and restore it on return.
Apparently the remaining regression is that DOSEMU doesn't realize
that SS is saved so, when it tries to return to full 64-bit mode after
a signal that hit in 16-bit mode, it fails because it's invalidated
the old SS descriptor in the mean time.
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
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-08-13 18:10 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX3eO-8ec-17@gated-at.bofh.it> |
| In reply to | #1206925 |
13.08.2015 18:38, Andy Lutomirski пишет:
> On Thu, Aug 13, 2015 at 8:22 AM, Stas Sergeev <stsp@list.ru> wrote:
>> 13.08.2015 17:58, Andy Lutomirski пишет:
>>
>>> On Thu, Aug 13, 2015 at 5:44 AM, Stas Sergeev <stsp@list.ru> wrote:
>>>> 13.08.2015 11:39, Ingo Molnar пишет:
>>>>> * Andy Lutomirski <luto@amacapital.net> 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.
> That's unfortunate.
>
> I don't really know what to do about this. My stupid heuristic for
> signal delivery seems unlikely to cause problems, but I'm not coming
> up with a great heuristic for detecting when a program that *modifies*
> sigcontext hasn't set all the fields. Even adding a flag won't really
> help here, since DOSEMU won't know to manipulate the flag.
>
> Ingo, here's the situation, assuming I remember the versions right:
>
> v4.0 and before: If we try to deliver a signal while SS is bad, we
> fail and the process dies. If SS is good but nonstandard, we end up
> in the signal handler with whatever SS value was loaded when the
> signal was sent. We do *not* put SS anywhere in the sigcontext, so
> the only way for a program to figure out what SS was is to look at the
> HW state before making any syscalls. We also don't even try to
> restore SS, so SS is unconditionally set to __USER_DS, necessitating
> nasty workarounds (and breaking all kinds of test cases).
>
> v4.1 and current -linus: We always set SS to __USER_DS when delivering
> a signal. We save the old SS in the sigcontext and restore it, just
> like 32-bit signals.
>
> My patch: We leave SS alone when delivering a signal, unless it's
> invalid, in which case we replace it with __USER_DS. We still save
> the old SS in the sigcontext and restore it on return.
>
> Apparently the remaining regression is that DOSEMU doesn't realize
> that SS is saved so, when it tries to return to full 64-bit mode after
> a signal that hit in 16-bit mode, it fails because it's invalidated
> the old SS descriptor in the mean time.
>
>
> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-08-13 18:20 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX3ou-8pv-13@gated-at.bofh.it> |
| In reply to | #1206935 |
On Thu, Aug 13, 2015 at 9:03 AM, Stas Sergeev <stsp@list.ru> 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? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-08-13 18:30 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX3y9-92-3@gated-at.bofh.it> |
| In reply to | #1206940 |
On Thu, Aug 13, 2015 at 9:20 AM, Stas Sergeev <stsp@list.ru> wrote: > 13.08.2015 19:09, Andy Lutomirski пишет: > >> On Thu, Aug 13, 2015 at 9:03 AM, Stas Sergeev <stsp@list.ru> 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. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-08-13 18:40 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX3HQ-kx-39@gated-at.bofh.it> |
| In reply to | #1206944 |
13.08.2015 19:24, Andy Lutomirski пишет: > On Thu, Aug 13, 2015 at 9:20 AM, Stas Sergeev <stsp@list.ru> wrote: >> 13.08.2015 19:09, Andy Lutomirski пишет: >> >>> On Thu, Aug 13, 2015 at 9:03 AM, Stas Sergeev <stsp@list.ru> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-08-13 18:50 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX3Rw-w6-1@gated-at.bofh.it> |
| In reply to | #1206957 |
On Thu, Aug 13, 2015 at 9:38 AM, Stas Sergeev <stsp@list.ru> wrote: > 13.08.2015 19:24, Andy Lutomirski пишет: > >> On Thu, Aug 13, 2015 at 9:20 AM, Stas Sergeev <stsp@list.ru> wrote: >>> >>> 13.08.2015 19:09, Andy Lutomirski пишет: >>> >>>> On Thu, Aug 13, 2015 at 9:03 AM, Stas Sergeev <stsp@list.ru> 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. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-08-13 18:50 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX3Rw-w6-11@gated-at.bofh.it> |
| In reply to | #1206958 |
13.08.2015 19:42, Andy Lutomirski пишет: > On Thu, Aug 13, 2015 at 9:38 AM, Stas Sergeev <stsp@list.ru> wrote: >> 13.08.2015 19:24, Andy Lutomirski пишет: >> >>> On Thu, Aug 13, 2015 at 9:20 AM, Stas Sergeev <stsp@list.ru> wrote: >>>> 13.08.2015 19:09, Andy Lutomirski пишет: >>>> >>>>> On Thu, Aug 13, 2015 at 9:03 AM, Stas Sergeev <stsp@list.ru> 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? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-08-13 19:10 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX4aS-18m-5@gated-at.bofh.it> |
| In reply to | #1206961 |
On Thu, Aug 13, 2015 at 9:48 AM, Stas Sergeev <stsp@list.ru> wrote: > 13.08.2015 19:42, Andy Lutomirski пишет: > >> On Thu, Aug 13, 2015 at 9:38 AM, Stas Sergeev <stsp@list.ru> wrote: >>> >>> 13.08.2015 19:24, Andy Lutomirski пишет: >>> >>>> On Thu, Aug 13, 2015 at 9:20 AM, Stas Sergeev <stsp@list.ru> wrote: >>>>> >>>>> 13.08.2015 19:09, Andy Lutomirski пишет: >>>>> >>>>>> On Thu, Aug 13, 2015 at 9:03 AM, Stas Sergeev <stsp@list.ru> 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. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-08-13 19:20 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX4kx-1jL-5@gated-at.bofh.it> |
| In reply to | #1206992 |
13.08.2015 19:59, Andy Lutomirski пишет: > On Thu, Aug 13, 2015 at 9:48 AM, Stas Sergeev <stsp@list.ru> wrote: >> 13.08.2015 19:42, Andy Lutomirski пишет: >> >>> On Thu, Aug 13, 2015 at 9:38 AM, Stas Sergeev <stsp@list.ru> wrote: >>>> 13.08.2015 19:24, Andy Lutomirski пишет: >>>> >>>>> On Thu, Aug 13, 2015 at 9:20 AM, Stas Sergeev <stsp@list.ru> wrote: >>>>>> 13.08.2015 19:09, Andy Lutomirski пишет: >>>>>> >>>>>>> On Thu, Aug 13, 2015 at 9:03 AM, Stas Sergeev <stsp@list.ru> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-08-13 19:20 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX4ky-1jL-35@gated-at.bofh.it> |
| In reply to | #1206998 |
On Thu, Aug 13, 2015 at 10:13 AM, Stas Sergeev <stsp@list.ru> wrote: > 13.08.2015 19:59, Andy Lutomirski пишет: > >> On Thu, Aug 13, 2015 at 9:48 AM, Stas Sergeev <stsp@list.ru> wrote: >>> >>> 13.08.2015 19:42, Andy Lutomirski пишет: >>> >>>> On Thu, Aug 13, 2015 at 9:38 AM, Stas Sergeev <stsp@list.ru> wrote: >>>>> >>>>> 13.08.2015 19:24, Andy Lutomirski пишет: >>>>> >>>>>> On Thu, Aug 13, 2015 at 9:20 AM, Stas Sergeev <stsp@list.ru> wrote: >>>>>>> >>>>>>> 13.08.2015 19:09, Andy Lutomirski пишет: >>>>>>> >>>>>>>> On Thu, Aug 13, 2015 at 9:03 AM, Stas Sergeev <stsp@list.ru> 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. The fs/gs patch doesn't change anything, so there's nothing to control. It just renamed fields that did nothing. (It turns out they did something back before arch_prctl existed, but there's only a narrow range of kernels like that, and I'm not at all convinced that those kernels are ABI-compatible with modern kernels at all. This is all pre-git.) Sure, it might make sense to change TLS behavior in signals at some point, but I don't think we're there yet. We need to deal with fsgsbase first, and that's a *huge* can of worms. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-08-13 20:10 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX56W-2ug-41@gated-at.bofh.it> |
| In reply to | #1207003 |
13.08.2015 20:17, Andy Lutomirski пишет: > On Thu, Aug 13, 2015 at 10:13 AM, Stas Sergeev <stsp@list.ru> wrote: > >> 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. > The fs/gs patch doesn't change anything, so there's nothing to > control. It just renamed fields that did nothing. (It turns out they > did something back before arch_prctl existed, but there's only a > narrow range of kernels like that, and I'm not at all convinced that > those kernels are ABI-compatible with modern kernels at all. This is > all pre-git.) The problem is that dosemu existed back then too. It still uses these fields as a place-holders. Well, this is a compile-time breakage only, so perhaps not as important as the run-time one, but still, you broke it in yet another way. > Sure, it might make sense to change TLS behavior in signals at some > point, but I don't think we're there yet. We need to deal with > fsgsbase first, and that's a *huge* can of worms. My point is not when to fix TLS or how. But you can get the flag ready, for now controlling only SS and fixing the regression, but it will define the course of the further developments. When the time will come, it will cover also TLS, but why not to get such a flag ready now, without yet fixing TLS? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-08-13 20:10 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX56X-2ug-57@gated-at.bofh.it> |
| In reply to | #1207037 |
On Thu, Aug 13, 2015 at 11:00 AM, Stas Sergeev <stsp@list.ru> wrote: > 13.08.2015 20:17, Andy Lutomirski пишет: >> >> On Thu, Aug 13, 2015 at 10:13 AM, Stas Sergeev <stsp@list.ru> wrote: >> >>> 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. >> >> The fs/gs patch doesn't change anything, so there's nothing to >> control. It just renamed fields that did nothing. (It turns out they >> did something back before arch_prctl existed, but there's only a >> narrow range of kernels like that, and I'm not at all convinced that >> those kernels are ABI-compatible with modern kernels at all. This is >> all pre-git.) > > The problem is that dosemu existed back then too. > It still uses these fields as a place-holders. Well, this is a > compile-time breakage only, so perhaps not as important > as the run-time one, but still, you broke it in yet another way. Great. What exactly is DOSEMU sticking in those fields? Are we now stuck ignoring the contents in sigreturn because DOSEMU coopts them for its own purposes? > >> Sure, it might make sense to change TLS behavior in signals at some >> point, but I don't think we're there yet. We need to deal with >> fsgsbase first, and that's a *huge* can of worms. > > My point is not when to fix TLS or how. > But you can get the flag ready, for now controlling only SS > and fixing the regression, but it will define the course of the > further developments. When the time will come, it will cover > also TLS, but why not to get such a flag ready now, without > yet fixing TLS? I think that if we create a flag to change semantics, we shouldn't introduce the flag and make it look like it works without actually changing the semantics. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-08-13 20:30 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX5qi-2R4-13@gated-at.bofh.it> |
| In reply to | #1207040 |
On Thu, Aug 13, 2015 at 11:19 AM, Stas Sergeev <stsp@list.ru> wrote: > It is more about selecting the right field for such a flag. > You can select the right field now, and introduce some flag > to it, like SIG_SAVE_SS or whatever. This will fix a regression. > Then, when the TLS time will code, you'll just add SIG_SAVE_FS > flag to the same field, so that they can be ORed. Oh. I think the field is obvious: uc_flags. I also thing that all of the saving should happen automatically, since I still don't see how anything will break if the kernel starts saving more things. It's the restore part that's problematic. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-08-13 20:40 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX5zY-32e-17@gated-at.bofh.it> |
| In reply to | #1207054 |
13.08.2015 21:25, Andy Lutomirski пишет: > On Thu, Aug 13, 2015 at 11:19 AM, Stas Sergeev <stsp@list.ru> wrote: > >> It is more about selecting the right field for such a flag. >> You can select the right field now, and introduce some flag >> to it, like SIG_SAVE_SS or whatever. This will fix a regression. >> Then, when the TLS time will code, you'll just add SIG_SAVE_FS >> flag to the same field, so that they can be ORed. > Oh. > > I think the field is obvious: uc_flags. But Andy, I don't understand... If we are talking about the field that will in the future also cover TLS, how can this be uc_flags? By using uc_flags, how will you control the restoring of FS on signal delivery? > I also thing that all of the > saving should happen automatically, since I still don't see how > anything will break if the kernel starts saving more things. It's the > restore part that's problematic. OK, so SIG_RESTORE_SS and SIG_RESTORE_FS. How can those be the part of uc_flags, if we want to control the restoring _on a signal delivery_? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-08-13 20:30 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX5qi-2R4-15@gated-at.bofh.it> |
| In reply to | #1207040 |
13.08.2015 21:05, Andy Lutomirski пишет: > On Thu, Aug 13, 2015 at 11:00 AM, Stas Sergeev <stsp@list.ru> wrote: >> 13.08.2015 20:17, Andy Lutomirski пишет: >>> On Thu, Aug 13, 2015 at 10:13 AM, Stas Sergeev <stsp@list.ru> wrote: >>> >>>> 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. >>> The fs/gs patch doesn't change anything, so there's nothing to >>> control. It just renamed fields that did nothing. (It turns out they >>> did something back before arch_prctl existed, but there's only a >>> narrow range of kernels like that, and I'm not at all convinced that >>> those kernels are ABI-compatible with modern kernels at all. This is >>> all pre-git.) >> The problem is that dosemu existed back then too. >> It still uses these fields as a place-holders. Well, this is a >> compile-time breakage only, so perhaps not as important >> as the run-time one, but still, you broke it in yet another way. > Great. What exactly is DOSEMU sticking in those fields? FS and GS of course. Saves by hands in a sighandler. > Are we now > stuck ignoring the contents in sigreturn because DOSEMU coopts them > for its own purposes? No, its just that these fields _were_ valid in times, and so, when kernel stopped using them, dosemu authors opted not to change their locations but just save things by hands. What else do you suppose could they do? Well, compile-time breakage is another thing, it can safely be ignored on your side I guess. Something like this should do: https://github.com/stsp/dosemu2/commit/4e16d83b9c7b1f9155ec0c0c125fe6f755eb719c >>> Sure, it might make sense to change TLS behavior in signals at some >>> point, but I don't think we're there yet. We need to deal with >>> fsgsbase first, and that's a *huge* can of worms. >> My point is not when to fix TLS or how. >> But you can get the flag ready, for now controlling only SS >> and fixing the regression, but it will define the course of the >> further developments. When the time will come, it will cover >> also TLS, but why not to get such a flag ready now, without >> yet fixing TLS? > I think that if we create a flag to change semantics, we shouldn't > introduce the flag and make it look like it works without actually > changing the semantics. It is more about selecting the right field for such a flag. You can select the right field now, and introduce some flag to it, like SIG_SAVE_SS or whatever. This will fix a regression. Then, when the TLS time will code, you'll just add SIG_SAVE_FS flag to the same field, so that they can be ORed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-08-13 18:30 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX3y9-92-5@gated-at.bofh.it> |
| In reply to | #1206940 |
13.08.2015 19:09, Andy Lutomirski пишет: > On Thu, Aug 13, 2015 at 9:03 AM, Stas Sergeev <stsp@list.ru> 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? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-08-13 13:10 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pWYyu-1um-35@gated-at.bofh.it> |
| In reply to | #1206390 |
13.08.2015 01:00, Andy Lutomirski пишет:
> On Wed, Aug 12, 2015 at 2:50 PM, Stas Sergeev <stsp@list.ru> wrote:
>> 13.08.2015 00:37, Andy Lutomirski пишет:
>>
>>> On Wed, Aug 12, 2015 at 1:55 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>> 12.08.2015 23:47, Andy Lutomirski пишет:
>>>>
>>>>> On Wed, Aug 12, 2015 at 1:45 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>> 12.08.2015 23:28, Andy Lutomirski пишет:
>>>>>>
>>>>>>> On Wed, Aug 12, 2015 at 1:14 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>>>> 12.08.2015 23:01, Andy Lutomirski пишет:
>>>>>>>>> On Wed, Aug 12, 2015 at 12:55 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>>>>>> 12.08.2015 22:20, Andy Lutomirski пишет:
>>>>>>>>>>> current kernels, it stays switched. If we change this, it won't
>>>>>>>>>>> stay
>>>>>>>>>>> switched. Even ignoring old ABI, it's not really clear to me what
>>>>>>>>>>> the
>>>>>>>>>>> right thing to do is.
>>>>>>>>>> There can be the following cases:
>>>>>>>>>> - switch_userspace_thread() switches fs to non-zero selector
>>>>>>>>>> - switch_userspace_thread() switches the fs base via syscall
>>>>>>>>>> - switch_userspace_thread() switches fs in sigcontext
>>>>>>>>>> - switch_userspace_thread() switches fs_base in sigcontext (???)
>>>>>>>>>> What exactly case do you have in mind?
>>>>>>>>>> I'd say, the way x86_32 is doing things - is good, but the
>>>>>>>>>> bases... perhaps, in ideal world, they should be a part of
>>>>>>>>>> the sigcontext as well?
>>>>>>>>> Any of the above. What do you want the kernel to do, and how does
>>>>>>>>> the
>>>>>>>>> kernel know you want to do that? The kernel has to pick *some*
>>>>>>>>> semantics here.
>>>>>>>> Assuming the bases are made the part of a sigcontext,
>>>>>>>> I'd say there would be no ambiguities remained at all:
>>>>>>>> whatever you change in a sigcontext, will be "applied" by
>>>>>>>> the sigreturn(). Whatever you put in the registers
>>>>>>>> (either segregs or MSRs), is valid until sigreturn(), then
>>>>>>>> forgotten forever.
>>>>>>>> The mess only comes in when some things are part of
>>>>>>>> sigcontext and some are not. But if you have _all_ things
>>>>>>>> accessable in sigcontext, then the user has a way of expressing
>>>>>>>> his needs very clearly: he'll either touch sigcontext or direct
>>>>>>>> values, depending on what he need.
>>>>>>>>
>>>>>>>> Is this right?
>>>>>>> Maybe, except that doing this might break existing code (Wine and Java
>>>>>>> come to mind). I'm not really sure.
>>>>>> Yes, but that's why I was talking about some new
>>>>>> flag. Maybe a new sigaction() flag? Or something else that
>>>>>> will allow the user to request explicitly the new handling
>>>>>> where the things are all switched by the kernel. Then
>>>>>> the old programs that don't use that flag, will remain
>>>>>> unaffected. I realize this may be a lot of work... But please
>>>>>> note that there will be no more a chance like this one,
>>>>>> when things are already badly broken. :)
>>>>> I think that, with my patch, we get the best of both worlds. We keep
>>>>> the old behavior in cases where it would work, and we switch to the
>>>>> new behavior in cases where the old behavior would result in killing
>>>>> the task.
>>>> But I mean also fs/TLS.
>>>> There is a chance now to fix things for good, all at once. :)
>>>> With such an ss patch applied to stable, there will be no more
>>>> such a chance ever. What's your opinion on the possibility of
>>>> fixing the TLS problem?
>>>> Also I am not sure about the sigreturn()'s detection: is it
>>>> a subject of the subsequent patch, or you dropped an idea?
>>> I think these things shouldn't be conflated. If we can fix it
>>> transparently (i.e. if my patch works), then I think we should do
>>> something like my patch.
>> 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.
Unfortunately, this doesn't help.
I made a simple patch that checks the kernel version:
https://github.com/stsp/dosemu2/commit/098413ef8de98972ca795e078351ae9f3cc07ffe
but iret is still used when switching to DOS code from dosemu
code, rather than from signal handler. So espfix64 doesn't help
much.
I guess the only real solution to this would be to "rewrite" dosemu
so that the DOS code is run in a clone(CLONE_VM) separate process...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-08-12 22:50 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pWL8e-71C-9@gated-at.bofh.it> |
| In reply to | #1206364 |
12.08.2015 23:28, Andy Lutomirski пишет: > On Wed, Aug 12, 2015 at 1:14 PM, Stas Sergeev <stsp@list.ru> wrote: >> 12.08.2015 23:01, Andy Lutomirski пишет: >>> On Wed, Aug 12, 2015 at 12:55 PM, Stas Sergeev <stsp@list.ru> wrote: >>>> 12.08.2015 22:20, Andy Lutomirski пишет: >>>>> current kernels, it stays switched. If we change this, it won't stay >>>>> switched. Even ignoring old ABI, it's not really clear to me what the >>>>> right thing to do is. >>>> There can be the following cases: >>>> - switch_userspace_thread() switches fs to non-zero selector >>>> - switch_userspace_thread() switches the fs base via syscall >>>> - switch_userspace_thread() switches fs in sigcontext >>>> - switch_userspace_thread() switches fs_base in sigcontext (???) >>>> What exactly case do you have in mind? >>>> I'd say, the way x86_32 is doing things - is good, but the >>>> bases... perhaps, in ideal world, they should be a part of >>>> the sigcontext as well? >>> Any of the above. What do you want the kernel to do, and how does the >>> kernel know you want to do that? The kernel has to pick *some* >>> semantics here. >> Assuming the bases are made the part of a sigcontext, >> I'd say there would be no ambiguities remained at all: >> whatever you change in a sigcontext, will be "applied" by >> the sigreturn(). Whatever you put in the registers >> (either segregs or MSRs), is valid until sigreturn(), then >> forgotten forever. >> The mess only comes in when some things are part of >> sigcontext and some are not. But if you have _all_ things >> accessable in sigcontext, then the user has a way of expressing >> his needs very clearly: he'll either touch sigcontext or direct >> values, depending on what he need. >> >> Is this right? > Maybe, except that doing this might break existing code (Wine and Java > come to mind). I'm not really sure. Yes, but that's why I was talking about some new flag. Maybe a new sigaction() flag? Or something else that will allow the user to request explicitly the new handling where the things are all switched by the kernel. Then the old programs that don't use that flag, will remain unaffected. I realize this may be a lot of work... But please note that there will be no more a chance like this one, when things are already badly broken. :) > Anyway, can you give this and its parent a try: > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/sigcontext&id=83a08d8c3f43c5524ffc0d88c0eff747716696f5 > > If they fix the problem for you, I'll improve the test cases and send > them to -stable. :( Doesn't look pretty at all. Of course I'll test it if you can't think of any alternative, but do you really think explicitly requesting a new interface will not be possible, and we'll have to live with work-arounds and new problems like in the gcc tracker popping up once in a while? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | linux.kernel
csiph-web