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 121 — 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 Ingo Molnar <mingo@kernel.org> - 2015-08-22 14: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-22 16:20 +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-23 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-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-09-02 07: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-09-02 11: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-09-02 16: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-09-02 17: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-09-02 19: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-09-02 20: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-09-02 20: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-09-02 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-09-02 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-09-02 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-09-03 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-09-03 00: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-09-03 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-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 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | Ingo Molnar <mingo@kernel.org> |
|---|---|
| Date | 2015-08-23 08:30 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <q0wX0-166-7@gated-at.bofh.it> |
| In reply to | #1211471 |
* Stas Sergeev <stsp@list.ru> wrote: > Also, the fact that dosemu already have that functionality, > doesn't mean it will not use the new API - it actually will. So if dosemu makes use of the new facility then sure, I'm not against it at all! Thanks, Ingo -- 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]
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| 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 | <pX2LL-7qM-5@gated-at.bofh.it> |
| In reply to | #1205516 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev <stsp@list.ru> wrote:
>
> 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.
That rule hasn't gone anywhere.
Does a plain revert just fix everything? Because if so, that's the
right thing to do, and we can just re-visit this later.
I don't understand why Andy and Ingo are even discussing this. What
the f*ck, guys?
Stas, can you verify that this actually fixes it? There's two
different versions here: one that reverts *just* that one commit, and
one that reverts the fs/gs changes too. Can you test them both?
Linus
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-08-13 17:50 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX2Vs-7C5-5@gated-at.bofh.it> |
| In reply to | #1206920 |
On Thu, Aug 13, 2015 at 8:37 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev <stsp@list.ru> wrote: >> >> 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. > > That rule hasn't gone anywhere. > > Does a plain revert just fix everything? Because if so, that's the > right thing to do, and we can just re-visit this later. > > I don't understand why Andy and Ingo are even discussing this. What > the f*ck, guys? > I'm trying to fix it without reverting. If that doesn't work, then we revert. Yesterday, I thought I had a reasonably clean fix, but it turned out that it only solved half of the problem. If we revert, I think I need to check what will break due to the revert. I need to check at least Wine, and we'll have to do something about all the selftests that will start failing. I also need to check CRIU, and IIRC CRIU has started using the new sigcontext SS in new versions. And, damnit, those selftests are *useful*. They've smoked out all kinds of problems. That's part of the reason I'd prefer not to revert if there's a better option. --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 | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| 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-5@gated-at.bofh.it> |
| In reply to | #1206926 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Aug 13, 2015 at 8:43 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>
> I'm trying to fix it without reverting. If that doesn't work, then we
> revert. Yesterday, I thought I had a reasonably clean fix, but it
> turned out that it only solved half of the problem.
The thing is, I actually think that the current situation is crazy.
Especially given that we don't restore any of the other segment
registers on x86-64 (except CS, of course)
So how about this "alternate" minimal patch instead. The difference is:
- we actually leave the
regs->ss = __USER_DS;
in __setup_rt_frame, to guarantee that when we take a signal, we do
take it with a valid SS
- but it removes all the other games with SS (and treats it exactly
the same as FS/GS).
So now we don't play games with the actual sigcontext, and
hopefully dosemu is happier.
Hmm? That actually makes the code look better, and doesn't
re-introduce that annoying CONFIG_X86_32 case (because it now does it
in obviously the same place as fs/gs).
So the code is cleaner, and closer to what we used to do.
Stas, can you test this one too? I, like Luto, don't actually have a
dosemu test-case.
Linus
[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 | <pX3ya-92-13@gated-at.bofh.it> |
| In reply to | #1206939 |
On Thu, Aug 13, 2015 at 9:19 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Thu, Aug 13, 2015 at 8:43 AM, Andy Lutomirski <luto@amacapital.net> wrote: >> >> I'm trying to fix it without reverting. If that doesn't work, then we >> revert. Yesterday, I thought I had a reasonably clean fix, but it >> turned out that it only solved half of the problem. > > The thing is, I actually think that the current situation is crazy. > > Especially given that we don't restore any of the other segment > registers on x86-64 (except CS, of course) > > So how about this "alternate" minimal patch instead. The difference is: > > - we actually leave the > > regs->ss = __USER_DS; > > in __setup_rt_frame, to guarantee that when we take a signal, we do > take it with a valid SS That by itself is enough to break DOSEMU. I think we may be stuck with my hack to only replace regs->ss if the old one was invalid. > > - but it removes all the other games with SS (and treats it exactly > the same as FS/GS). > > So now we don't play games with the actual sigcontext, and > hopefully dosemu is happier. You mean that we always set ss to __USER_DS on sigreturn? The problem is that user code *can't* program SS when calling sigreturn because the SYSCALL instruction zaps it. I'll try to implement something. If this regression were new in 4.2-rc, then I'd say revert first and ask questions later, but the regression is in 4.1 as well :( --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 | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| 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-31@gated-at.bofh.it> |
| In reply to | #1206947 |
On Thu, Aug 13, 2015 at 9:23 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Thu, Aug 13, 2015 at 9:19 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> So how about this "alternate" minimal patch instead. The difference is:
>>
>> - we actually leave the
>>
>> regs->ss = __USER_DS;
>>
>> in __setup_rt_frame, to guarantee that when we take a signal, we do
>> take it with a valid SS
>
> That by itself is enough to break DOSEMU. I think we may be stuck
> with my hack to only replace regs->ss if the old one was invalid.
Are you sure? From the description by Stas, the problem is literally
the *restoring* action of the sigcontext, and trying to restore a SS
value that is no longer valid.
"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"
and my "truly-minimal" patch removes all of the sigcontext games.
> You mean that we always set ss to __USER_DS on sigreturn?
No. We never touch SS at sigreturn time at all. Only when entering the
signal *handler* do we reset things to a known state. The signal
handler can do anything it wants, and sigreturn won't touch it (which
will obviously _leave_ it as __USER_DS, but avoids the problem with
sigreturn trying to load an SS that is no longer valid)
> If this regression were new in 4.2-rc, then I'd say revert first and
> ask questions later, but the regression is in 4.1 as well :(
Big deal. That's why we have the "cc stable". Distributions that ship
with 4.1 are still fairly few (but it's a LTS release so it will grow)
but they all pick up stable kernels.
And even if they temporarily have a broken situation, it's still
better to make sure that broken situation gets fixed, rather than say
"oh well, too late to do anything about it now".
Linus
--
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-19@gated-at.bofh.it> |
| In reply to | #1206955 |
On Thu, Aug 13, 2015 at 9:43 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Thu, Aug 13, 2015 at 9:34 AM, Linus Torvalds > <torvalds@linux-foundation.org> wrote: >> >> Are you sure? From the description by Stas, the problem is literally >> the *restoring* action of the sigcontext, and trying to restore a SS >> value that is no longer valid. >> >> "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" > > Side note: if this is the main issue, and the problem is the "iret" > faulting when trying to restore SS (and causing an unexpected SIGSEGV > that dosemu crashes on), then an alternate model might be to keep the > save/restore SS code, but do a "VERW" on the SS descriptor in > restore_sigcontext(), and silently just replacing it with __USER_DS if > that fails. > I have a patch to do approximately that (using LAR instead of VERW to rule out DPL < 3. I'm 90% sure that the regs->ss = __USER_DS thing is a problem. Read farther up in the thread. I'm leaning toward saying we should revert, cc: stable, and fix it better for 4.3. --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 | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| 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-21@gated-at.bofh.it> |
| In reply to | #1206955 |
On Thu, Aug 13, 2015 at 9:34 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Are you sure? From the description by Stas, the problem is literally
> the *restoring* action of the sigcontext, and trying to restore a SS
> value that is no longer valid.
>
> "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"
Side note: if this is the main issue, and the problem is the "iret"
faulting when trying to restore SS (and causing an unexpected SIGSEGV
that dosemu crashes on), then an alternate model might be to keep the
save/restore SS code, but do a "VERW" on the SS descriptor in
restore_sigcontext(), and silently just replacing it with __USER_DS if
that fails.
Linus
--
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 | Brian Gerst <brgerst@gmail.com> |
|---|---|
| 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-17@gated-at.bofh.it> |
| In reply to | #1206926 |
On Thu, Aug 13, 2015 at 11:43 AM, Andy Lutomirski <luto@amacapital.net> wrote: > On Thu, Aug 13, 2015 at 8:37 AM, Linus Torvalds > <torvalds@linux-foundation.org> wrote: >> On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev <stsp@list.ru> wrote: >>> >>> 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. >> >> That rule hasn't gone anywhere. >> >> Does a plain revert just fix everything? Because if so, that's the >> right thing to do, and we can just re-visit this later. >> >> I don't understand why Andy and Ingo are even discussing this. What >> the f*ck, guys? >> > > I'm trying to fix it without reverting. If that doesn't work, then we > revert. Yesterday, I thought I had a reasonably clean fix, but it > turned out that it only solved half of the problem. > > If we revert, I think I need to check what will break due to the > revert. I need to check at least Wine, and we'll have to do something > about all the selftests that will start failing. I also need to check > CRIU, and IIRC CRIU has started using the new sigcontext SS in new > versions. I don't think Wine will be a problem, at least how it is currently set up. 16-bit support is only in the 32-bit build. The 64-bit build only supports Win64 apps, and will call the 32-bit version (installed in parallel) to run 32 and 16-bit apps. -- Brian Gerst -- 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-18 08:40 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pYIIW-6B0-3@gated-at.bofh.it> |
| In reply to | #1206994 |
13.08.2015 20:00, Brian Gerst пишет: > On Thu, Aug 13, 2015 at 11:43 AM, Andy Lutomirski <luto@amacapital.net> wrote: >> On Thu, Aug 13, 2015 at 8:37 AM, Linus Torvalds >> <torvalds@linux-foundation.org> wrote: >>> On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev <stsp@list.ru> wrote: >>>> 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. >>> That rule hasn't gone anywhere. >>> >>> Does a plain revert just fix everything? Because if so, that's the >>> right thing to do, and we can just re-visit this later. >>> >>> I don't understand why Andy and Ingo are even discussing this. What >>> the f*ck, guys? >>> >> I'm trying to fix it without reverting. If that doesn't work, then we >> revert. Yesterday, I thought I had a reasonably clean fix, but it >> turned out that it only solved half of the problem. >> >> If we revert, I think I need to check what will break due to the >> revert. I need to check at least Wine, and we'll have to do something >> about all the selftests that will start failing. I also need to check >> CRIU, and IIRC CRIU has started using the new sigcontext SS in new >> versions. > I don't think Wine will be a problem, at least how it is currently set > up. 16-bit support is only in the 32-bit build. The 64-bit build > only supports Win64 apps, and will call the 32-bit version (installed > in parallel) to run 32 and 16-bit apps. Is this also because of the lack of the proper 32/16bit support in a 64bit kernels? If so, dosemu's work-arounds do not look like the too bad thing compared to that. :) -- 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-19 00:50 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pYXRD-41k-1@gated-at.bofh.it> |
| In reply to | #1209070 |
On Mon, Aug 17, 2015 at 11:19 PM, Stas Sergeev <stsp@list.ru> wrote: > 14.08.2015 04:37, Andy Lutomirski пишет: > >> On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev <stsp@list.ru> wrote: >>> >>> 14.08.2015 04:21, Andy Lutomirski пишет: >>> >>>> On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev <stsp@list.ru> wrote: >>>>> >>>>> 14.08.2015 03:27, Linus Torvalds пишет: >>>>>> >>>>>> On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev <stsp@list.ru> wrote: >>>>>>> >>>>>>> For example because you can as well do: >>>>>>> prctl(ARCH_SET_SIGNAL_SS, 0) >>>>>>> which will mean "restore ss in sighandler to its current value", >>>>>> >>>>>> I really think a prctl() is the wrong thing to do. >>>>>> >>>>>> If you want a signal handler to save/restore segments, I think it >>>>>> should be a SA_xyz flag to sigaction() (the way we have SA_RESTART >>>>> >>>>> Yes, I was proposing the new sigaction() flag in this thread >>>>> already too. But at the end, prctl() looks better to me because >>>>> it allows to pass the TLS value to use when restoring FS. >>>>> The thing is that I am trying to find the similar treatment for >>>>> both the SS and FS problems. If you don't think they need a >>>>> similar treatment, then perhaps the Andy's patch is enough. >>>>> >>>>>> etc). And off by default because of the obvious compatibility issues. >>>>> >>>>> Of course. >>>>> >>>>> So, what we have right now (in the latest Andy's patch) is: >>>>> 1. lar heuristics >>>>> 2. new uc_flags flag >>>>> >>>>> What it solves: dosemu's regression. >>>>> >>>>> What prctl() can give: >>>>> - fix to dosemu's regression >>>>> - fix to the TLS problem in the future >>>>> - no hack and heuristics >>>>> >>>>> With SA_xyz you can only solve the SS problem, so it is >>>>> probably not any better than the uc_flags things coded >>>>> up by Andy. >>>> >>>> I'm leaning slightly toward LAR heuristic + SA_SAVE_SS. >>> >>> Stop right here, doesn't the SA_xyz allow to avoid the >>> lar heuristic? Why would you still need the lar heuristic then? >>> Just call it SA_RESTORE_SS instead of SA_SAVE_SS, and >>> the lar heuristic is gone. >> >> The LAR heuristic is about five lines of code, and it makes signal >> delivery more reliable. > > Why more reliable? In what case? > >> Sure, we could gate the "regs->ss = >> __USER_DS" line on a flag, but why? > > A few things I can think of why: > - nested signals (usual for dosemu) What's the issue with nested signals? > - using siglongjmp() to return to dosemu (rather than to DOS code) > Both cases look very scare when using SS from just freed LDT entry. > How would you even justify and changelog the patch that adds a lar > heuristic code that no one uses or wants? Since SA_hyz flag allows > you to do without, why not to just keep things safe and simple? The LAR heuristic is just for compatibility. ISTM what DOSEMU should want (on new kernels, anyway) is the ability to save and restore SS just like any other register, which is what my patch did. The issue is that it broke old DOSEMU. I want to find a way to keep old DOSEMU working while making things work better for new code that's aware of new behavior. That means we want some way (opt-in or magically compatible with old DOSEMU) to get SS saved and restored. Incidentally, I tried implementing the sigaction flag approach. I think it's no good. When we return from a signal, there's no concept of sigaction -- it's just sigreturn. Sigreturn can't look up the sigaction flags -- what if the signal handler calls sigaction itself. So we either need a per-task flag, a per-sighand flag, or a sigcontext flag indicating what we should do. (Yes, I suspect we really might want some way to get FS, GS, and their bases saved and restored, but I still think we should do that separately.) -- 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-19 11:40 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pZ80H-1Xp-33@gated-at.bofh.it> |
| In reply to | #1209525 |
19.08.2015 01:47, Andy Lutomirski пишет: > On Mon, Aug 17, 2015 at 11:19 PM, Stas Sergeev <stsp@list.ru> wrote: >> 14.08.2015 04:37, Andy Lutomirski пишет: >> >>> On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev <stsp@list.ru> wrote: >>>> >>>> 14.08.2015 04:21, Andy Lutomirski пишет: >>>> >>>>> On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev <stsp@list.ru> wrote: >>>>>> >>>>>> 14.08.2015 03:27, Linus Torvalds пишет: >>>>>>> >>>>>>> On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev <stsp@list.ru> wrote: >>>>>>>> >>>>>>>> For example because you can as well do: >>>>>>>> prctl(ARCH_SET_SIGNAL_SS, 0) >>>>>>>> which will mean "restore ss in sighandler to its current value", >>>>>>> >>>>>>> I really think a prctl() is the wrong thing to do. >>>>>>> >>>>>>> If you want a signal handler to save/restore segments, I think it >>>>>>> should be a SA_xyz flag to sigaction() (the way we have SA_RESTART >>>>>> >>>>>> Yes, I was proposing the new sigaction() flag in this thread >>>>>> already too. But at the end, prctl() looks better to me because >>>>>> it allows to pass the TLS value to use when restoring FS. >>>>>> The thing is that I am trying to find the similar treatment for >>>>>> both the SS and FS problems. If you don't think they need a >>>>>> similar treatment, then perhaps the Andy's patch is enough. >>>>>> >>>>>>> etc). And off by default because of the obvious compatibility issues. >>>>>> >>>>>> Of course. >>>>>> >>>>>> So, what we have right now (in the latest Andy's patch) is: >>>>>> 1. lar heuristics >>>>>> 2. new uc_flags flag >>>>>> >>>>>> What it solves: dosemu's regression. >>>>>> >>>>>> What prctl() can give: >>>>>> - fix to dosemu's regression >>>>>> - fix to the TLS problem in the future >>>>>> - no hack and heuristics >>>>>> >>>>>> With SA_xyz you can only solve the SS problem, so it is >>>>>> probably not any better than the uc_flags things coded >>>>>> up by Andy. >>>>> >>>>> I'm leaning slightly toward LAR heuristic + SA_SAVE_SS. >>>> >>>> Stop right here, doesn't the SA_xyz allow to avoid the >>>> lar heuristic? Why would you still need the lar heuristic then? >>>> Just call it SA_RESTORE_SS instead of SA_SAVE_SS, and >>>> the lar heuristic is gone. >>> >>> The LAR heuristic is about five lines of code, and it makes signal >>> delivery more reliable. >> >> Why more reliable? In what case? >> >>> Sure, we could gate the "regs->ss = >>> __USER_DS" line on a flag, but why? >> >> A few things I can think of why: >> - nested signals (usual for dosemu) > > What's the issue with nested signals? If nested signal is async and SS is from LDT just freed, then the nested signal will silently change the SS value. So if you are saving it somewhere, you'll save it by luck. Now this is unlikely to happen, as the async signals in dosemu are all blocked inside any sighandler. So the siglongjmp() case is more expressive: if dosemu jumped via siglongjmp() and as such unblocked the async signals, it will likely want to save its registers before doing a new switch. Now, since SS is invalid and will be therefore changed by a sighandler, what it will save depends on a luck. Not that dosemu uses siglongjmp() right now, but I am just asking to please not implement the unreliable interfaces _if possible_. >> - using siglongjmp() to return to dosemu (rather than to DOS code) >> Both cases look very scare when using SS from just freed LDT entry. >> How would you even justify and changelog the patch that adds a lar >> heuristic code that no one uses or wants? Since SA_hyz flag allows >> you to do without, why not to just keep things safe and simple? > > The LAR heuristic is just for compatibility. > > ISTM what DOSEMU should want (on new kernels, anyway) is the ability > to save and restore SS just like any other register, which is what my > patch did. The issue is that it broke old DOSEMU. I want to find a > way to keep old DOSEMU working while making things work better for new > code that's aware of new behavior. That means we want some way > (opt-in or magically compatible with old DOSEMU) to get SS saved and > restored. > > Incidentally, I tried implementing the sigaction flag approach. I > think it's no good. When we return from a signal, there's no concept > of sigaction -- it's just sigreturn. Sigreturn can't look up the > sigaction flags -- what if the signal handler calls sigaction itself. How about the SA_hyz flag that does the following: - Saves SS into sigcontext - Forces SS to USER_DS on signal delivery - Sets the uc_flags flag for sigreturn() to take care of the rest. You'll have both the control on every bit of action, and a simple detection logic: if SA_hyz didn't set the uc flag - it didn't work. You can even employ your lar heuristic here for the case when the aforementioned SA_hyz is not set. But please, please not when it is set! In fact, I wonder if you had in mind exactly that: using the lar heuristic only if the SA_hyz is not set. If so - I misunderstood. Just please don't add it when it is set. > So we either need a per-task flag, a per-sighand flag, or a sigcontext > flag indicating what we should do. > > (Yes, I suspect we really might want some way to get FS, GS, and their > bases saved and restored, but I still think we should do that > separately.) In fact, I have already convinced myself that SA_hyz can take care of both cases. :) Maybe you'll just need to extend the struct sigaction to pass the TLS address, but this doesn't look absolutely impossible... -- 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-19 17:50 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pZdMJ-1OT-9@gated-at.bofh.it> |
| In reply to | #1209748 |
On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev <stsp@list.ru> wrote: > 19.08.2015 01:47, Andy Lutomirski пишет: >> On Mon, Aug 17, 2015 at 11:19 PM, Stas Sergeev <stsp@list.ru> wrote: >>> 14.08.2015 04:37, Andy Lutomirski пишет: >>> >>>> On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev <stsp@list.ru> wrote: >>>>> >>>>> 14.08.2015 04:21, Andy Lutomirski пишет: >>>>> >>>>>> On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev <stsp@list.ru> wrote: >>>>>>> >>>>>>> 14.08.2015 03:27, Linus Torvalds пишет: >>>>>>>> >>>>>>>> On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev <stsp@list.ru> wrote: >>>>>>>>> >>>>>>>>> For example because you can as well do: >>>>>>>>> prctl(ARCH_SET_SIGNAL_SS, 0) >>>>>>>>> which will mean "restore ss in sighandler to its current value", >>>>>>>> >>>>>>>> I really think a prctl() is the wrong thing to do. >>>>>>>> >>>>>>>> If you want a signal handler to save/restore segments, I think it >>>>>>>> should be a SA_xyz flag to sigaction() (the way we have SA_RESTART >>>>>>> >>>>>>> Yes, I was proposing the new sigaction() flag in this thread >>>>>>> already too. But at the end, prctl() looks better to me because >>>>>>> it allows to pass the TLS value to use when restoring FS. >>>>>>> The thing is that I am trying to find the similar treatment for >>>>>>> both the SS and FS problems. If you don't think they need a >>>>>>> similar treatment, then perhaps the Andy's patch is enough. >>>>>>> >>>>>>>> etc). And off by default because of the obvious compatibility issues. >>>>>>> >>>>>>> Of course. >>>>>>> >>>>>>> So, what we have right now (in the latest Andy's patch) is: >>>>>>> 1. lar heuristics >>>>>>> 2. new uc_flags flag >>>>>>> >>>>>>> What it solves: dosemu's regression. >>>>>>> >>>>>>> What prctl() can give: >>>>>>> - fix to dosemu's regression >>>>>>> - fix to the TLS problem in the future >>>>>>> - no hack and heuristics >>>>>>> >>>>>>> With SA_xyz you can only solve the SS problem, so it is >>>>>>> probably not any better than the uc_flags things coded >>>>>>> up by Andy. >>>>>> >>>>>> I'm leaning slightly toward LAR heuristic + SA_SAVE_SS. >>>>> >>>>> Stop right here, doesn't the SA_xyz allow to avoid the >>>>> lar heuristic? Why would you still need the lar heuristic then? >>>>> Just call it SA_RESTORE_SS instead of SA_SAVE_SS, and >>>>> the lar heuristic is gone. >>>> >>>> The LAR heuristic is about five lines of code, and it makes signal >>>> delivery more reliable. >>> >>> Why more reliable? In what case? >>> >>>> Sure, we could gate the "regs->ss = >>>> __USER_DS" line on a flag, but why? >>> >>> A few things I can think of why: >>> - nested signals (usual for dosemu) >> >> What's the issue with nested signals? > If nested signal is async and SS is from LDT just freed, then > the nested signal will silently change the SS value. So if you > are saving it somewhere, you'll save it by luck. > Now this is unlikely to happen, as the async signals in dosemu > are all blocked inside any sighandler. So the siglongjmp() case > is more expressive: if dosemu jumped via siglongjmp() and as such > unblocked the async signals, it will likely want to save its > registers before doing a new switch. Now, since SS is invalid > and will be therefore changed by a sighandler, what it will save > depends on a luck. > Not that dosemu uses siglongjmp() right now, but I am just asking > to please not implement the unreliable interfaces _if possible_. Ok, I think I get it. I'm not proposing the LAR thing as something that anyone should intentionally use going forward. It would only be for compatbility with old code if needed. We certainly should save SS somewhere. >> Incidentally, I tried implementing the sigaction flag approach. I >> think it's no good. When we return from a signal, there's no concept >> of sigaction -- it's just sigreturn. Sigreturn can't look up the >> sigaction flags -- what if the signal handler calls sigaction itself. > How about the SA_hyz flag that does the following: > - Saves SS into sigcontext > - Forces SS to USER_DS on signal delivery > - Sets the uc_flags flag for sigreturn() to take care of the rest. > You'll have both the control on every bit of action, and a simple > detection logic: if SA_hyz didn't set the uc flag - it didn't work. > You can even employ your lar heuristic here for the case when the > aforementioned SA_hyz is not set. But please, please not when it is > set! In fact, I wonder if you had in mind exactly that: using the > lar heuristic only if the SA_hyz is not set. If so - I misunderstood. > Just please don't add it when it is set. Hmm, interesting. Maybe that would work for everything. How's this to make it concrete? Add a sigaction flag SA_RESTORE_SS. On signal delivery, always save SS into sigcontext->ss. if SA_RESTORE_SS is set, then unconditionally switch HW SS to __USER_DS and set UC_RESTORE_SS. If SA_RESTORE_SS is clear, then leave HW SS alone (i.e. preserve the old behavior). On signal return, if UC_RESTORE_SS is set, then restore sigcontext->ss. If not, then set SS to __USER_DS (as old kernels did). This should change nothing at all (except the initial value of sigcontext->ss / __pad0) on old kernels. > >> So we either need a per-task flag, a per-sighand flag, or a sigcontext >> flag indicating what we should do. >> >> (Yes, I suspect we really might want some way to get FS, GS, and their >> bases saved and restored, but I still think we should do that >> separately.) > In fact, I have already convinced myself that SA_hyz can take > care of both cases. :) Maybe you'll just need to extend the struct sigaction > to pass the TLS address, but this doesn't look absolutely impossible... I think that should be a separate SA_ flag down the road, if for no other reason than that the SS thing can be done more or less immediately, whereas getting FS and GS right needs to wait. Also, it occurs to me that FS and GS could become more complicated. There are some proposals to allow tasks to opt in to having a per-cpu GS. If that happens, then figuring out how it would interact with signals could be complicated. --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-19 18:40 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pZez9-2Yu-39@gated-at.bofh.it> |
| In reply to | #1209917 |
19.08.2015 18:46, Andy Lutomirski пишет: > On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev <stsp@list.ru> wrote: >>> Incidentally, I tried implementing the sigaction flag approach. I >>> think it's no good. When we return from a signal, there's no concept >>> of sigaction -- it's just sigreturn. Sigreturn can't look up the >>> sigaction flags -- what if the signal handler calls sigaction itself. >> How about the SA_hyz flag that does the following: >> - Saves SS into sigcontext >> - Forces SS to USER_DS on signal delivery >> - Sets the uc_flags flag for sigreturn() to take care of the rest. >> You'll have both the control on every bit of action, and a simple >> detection logic: if SA_hyz didn't set the uc flag - it didn't work. >> You can even employ your lar heuristic here for the case when the >> aforementioned SA_hyz is not set. But please, please not when it is >> set! In fact, I wonder if you had in mind exactly that: using the >> lar heuristic only if the SA_hyz is not set. If so - I misunderstood. >> Just please don't add it when it is set. > > Hmm, interesting. Maybe that would work for everything. How's this > to make it concrete? > > Add a sigaction flag SA_RESTORE_SS. > > On signal delivery, always save SS into sigcontext->ss. if > SA_RESTORE_SS is set, then unconditionally switch HW SS to __USER_DS > and set UC_RESTORE_SS. If SA_RESTORE_SS is clear, then leave HW SS > alone (i.e. preserve the old behavior). Either that, or employ the lar heuristic for the "not set" case (I think its not needed). > On signal return, if UC_RESTORE_SS is set, then restore > sigcontext->ss. If not, then set SS to __USER_DS (as old kernels > did). > > This should change nothing at all (except the initial value of > sigcontext->ss / __pad0) on old kernels. Agreed. >>> So we either need a per-task flag, a per-sighand flag, or a sigcontext >>> flag indicating what we should do. >>> >>> (Yes, I suspect we really might want some way to get FS, GS, and their >>> bases saved and restored, but I still think we should do that >>> separately.) >> In fact, I have already convinced myself that SA_hyz can take >> care of both cases. :) Maybe you'll just need to extend the struct sigaction >> to pass the TLS address, but this doesn't look absolutely impossible... > > I think that should be a separate SA_ flag down the road, Of course separate. I only wanted to get a "somewhat similar" solution, so if the TLS case can also be covered by the (different) SA_ flag (plus perhaps a struct sigaction extension), then its just excellent. What I was afraid of is to get an SS-specific fix, like your initial uc_flags+lar_heuristic solution. Such fix can't be extended to the TLS case, reducing the chances for the TLS case to be ever re-visited. > Also, it occurs to me that FS and GS could become more complicated. > There are some proposals to allow tasks to opt in to having a per-cpu > GS. If that happens, then figuring out how it would interact with > signals could be complicated. Is this a problem? At least on 86_64, according to this: http://wiki.osdev.org/Thread_Local_Storage#x86-64 we only need FS. In any case, since what you say about GS is optional and should be explicitly requested by the task, it can just disable the use of the new SA_TLS flag, making the sigaction() to return error for example. I think the amount of the supported combinations should be limited by the practical needs, and I don't think someone will need per-cpu GS with sighandler re-setting it to something non-per-cpu. -- 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-09-02 07:20 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <q48CJ-3QR-1@gated-at.bofh.it> |
| In reply to | #1209947 |
On Wed, Aug 19, 2015 at 9:30 AM, Stas Sergeev <stsp@list.ru> wrote: > 19.08.2015 18:46, Andy Lutomirski пишет: >> On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev <stsp@list.ru> wrote: >>>> Incidentally, I tried implementing the sigaction flag approach. I >>>> think it's no good. When we return from a signal, there's no concept >>>> of sigaction -- it's just sigreturn. Sigreturn can't look up the >>>> sigaction flags -- what if the signal handler calls sigaction itself. >>> How about the SA_hyz flag that does the following: >>> - Saves SS into sigcontext >>> - Forces SS to USER_DS on signal delivery >>> - Sets the uc_flags flag for sigreturn() to take care of the rest. >>> You'll have both the control on every bit of action, and a simple >>> detection logic: if SA_hyz didn't set the uc flag - it didn't work. >>> You can even employ your lar heuristic here for the case when the >>> aforementioned SA_hyz is not set. But please, please not when it is >>> set! In fact, I wonder if you had in mind exactly that: using the >>> lar heuristic only if the SA_hyz is not set. If so - I misunderstood. >>> Just please don't add it when it is set. >> >> Hmm, interesting. Maybe that would work for everything. How's this >> to make it concrete? >> >> Add a sigaction flag SA_RESTORE_SS. >> >> On signal delivery, always save SS into sigcontext->ss. if >> SA_RESTORE_SS is set, then unconditionally switch HW SS to __USER_DS >> and set UC_RESTORE_SS. If SA_RESTORE_SS is clear, then leave HW SS >> alone (i.e. preserve the old behavior). > Either that, or employ the lar heuristic for the "not set" case > (I think its not needed). > >> On signal return, if UC_RESTORE_SS is set, then restore >> sigcontext->ss. If not, then set SS to __USER_DS (as old kernels >> did). >> >> This should change nothing at all (except the initial value of >> sigcontext->ss / __pad0) on old kernels. > Agreed. > Let me throw out one more possibility, just for completeness: We don't add any SA_xyz flags. On signal delivery, we use the LAR heuristic. We always fill in sigcontext->ss, and we set a new UC_SIGCONTEXT_SS flag to indicate that we support the new behavior. On sigreturn, we honor the sigcontext's ss, *unless* CS is 64 bit and SS is invalid. In the latter case, we replace the saved ss with __USER_DS. This should work for old DOSEMU. It's a bit gross, but it has the nice benefit that everyone (even things that aren't DOSEMU) gain the ability to catch signals thrown from bogus SS contexts, which probably improves debugability. It's also nice to not have the SA flag. This is a big problematic for my sigreturn_64 test, but I can deal with that. We could optionally have another UC_RESTORE_EXACT_SS flag that you can set that means "no, really, restore the saved SS". --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-09-02 11:20 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <q4cmZ-KF-1@gated-at.bofh.it> |
| In reply to | #1217318 |
02.09.2015 08:12, Andy Lutomirski пишет: > On Wed, Aug 19, 2015 at 9:30 AM, Stas Sergeev <stsp@list.ru> wrote: >> 19.08.2015 18:46, Andy Lutomirski пишет: >>> On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev <stsp@list.ru> wrote: >>>>> Incidentally, I tried implementing the sigaction flag approach. I >>>>> think it's no good. When we return from a signal, there's no concept >>>>> of sigaction -- it's just sigreturn. Sigreturn can't look up the >>>>> sigaction flags -- what if the signal handler calls sigaction itself. >>>> How about the SA_hyz flag that does the following: >>>> - Saves SS into sigcontext >>>> - Forces SS to USER_DS on signal delivery >>>> - Sets the uc_flags flag for sigreturn() to take care of the rest. >>>> You'll have both the control on every bit of action, and a simple >>>> detection logic: if SA_hyz didn't set the uc flag - it didn't work. >>>> You can even employ your lar heuristic here for the case when the >>>> aforementioned SA_hyz is not set. But please, please not when it is >>>> set! In fact, I wonder if you had in mind exactly that: using the >>>> lar heuristic only if the SA_hyz is not set. If so - I misunderstood. >>>> Just please don't add it when it is set. >>> Hmm, interesting. Maybe that would work for everything. How's this >>> to make it concrete? >>> >>> Add a sigaction flag SA_RESTORE_SS. >>> >>> On signal delivery, always save SS into sigcontext->ss. if >>> SA_RESTORE_SS is set, then unconditionally switch HW SS to __USER_DS >>> and set UC_RESTORE_SS. If SA_RESTORE_SS is clear, then leave HW SS >>> alone (i.e. preserve the old behavior). >> Either that, or employ the lar heuristic for the "not set" case >> (I think its not needed). >> >>> On signal return, if UC_RESTORE_SS is set, then restore >>> sigcontext->ss. If not, then set SS to __USER_DS (as old kernels >>> did). >>> >>> This should change nothing at all (except the initial value of >>> sigcontext->ss / __pad0) on old kernels. >> Agreed. >> > Let me throw out one more possibility, just for completeness: > > We don't add any SA_xyz flags. On signal delivery, we use the LAR > heuristic. We always fill in sigcontext->ss, and we set a new > UC_SIGCONTEXT_SS flag to indicate that we support the new behavior. > > On sigreturn, we honor the sigcontext's ss, *unless* CS is 64 bit and > SS is invalid. In the latter case, we replace the saved ss with > __USER_DS. But this is not a new proposal, see here: https://lkml.org/lkml/2015/8/13/436 The very last sentence says exactly the same. I thought this is in the past. :) > This should work for old DOSEMU. It's a bit gross, but it has the > nice benefit that everyone (even things that aren't DOSEMU) gain the > ability to catch signals thrown from bogus SS contexts, which probably > improves debugability. It's also nice to not have the SA flag. Pros: - No new SA flag - May improve debugability in some unknown scenario where people do not want to just use the new flag to get their things improved Cons: - Does not allow to cleanly use siglongjmp(), as then there is a risk to jump to 64bit code with bad SS - Async signals can silently "validate" SS behind your back - No way to extend that solution to later fixing the TLS problem - Many ugly checks in the code, that are not always even obvious (eg you wanted to try verw instead, and there was a gotcha with NP bit) Is the new SA flag such a big deal here to even bother? -- 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-09-02 16:30 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <q4hd0-7Er-25@gated-at.bofh.it> |
| In reply to | #1217439 |
On Wed, Sep 2, 2015 at 2:17 AM, Stas Sergeev <stsp@list.ru> wrote: > 02.09.2015 08:12, Andy Lutomirski пишет: > >> On Wed, Aug 19, 2015 at 9:30 AM, Stas Sergeev <stsp@list.ru> wrote: >>> >>> 19.08.2015 18:46, Andy Lutomirski пишет: >>>> >>>> On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev <stsp@list.ru> wrote: >>>>>> >>>>>> Incidentally, I tried implementing the sigaction flag approach. I >>>>>> think it's no good. When we return from a signal, there's no concept >>>>>> of sigaction -- it's just sigreturn. Sigreturn can't look up the >>>>>> sigaction flags -- what if the signal handler calls sigaction itself. >>>>> >>>>> How about the SA_hyz flag that does the following: >>>>> - Saves SS into sigcontext >>>>> - Forces SS to USER_DS on signal delivery >>>>> - Sets the uc_flags flag for sigreturn() to take care of the rest. >>>>> You'll have both the control on every bit of action, and a simple >>>>> detection logic: if SA_hyz didn't set the uc flag - it didn't work. >>>>> You can even employ your lar heuristic here for the case when the >>>>> aforementioned SA_hyz is not set. But please, please not when it is >>>>> set! In fact, I wonder if you had in mind exactly that: using the >>>>> lar heuristic only if the SA_hyz is not set. If so - I misunderstood. >>>>> Just please don't add it when it is set. >>>> >>>> Hmm, interesting. Maybe that would work for everything. How's this >>>> to make it concrete? >>>> >>>> Add a sigaction flag SA_RESTORE_SS. >>>> >>>> On signal delivery, always save SS into sigcontext->ss. if >>>> SA_RESTORE_SS is set, then unconditionally switch HW SS to __USER_DS >>>> and set UC_RESTORE_SS. If SA_RESTORE_SS is clear, then leave HW SS >>>> alone (i.e. preserve the old behavior). >>> >>> Either that, or employ the lar heuristic for the "not set" case >>> (I think its not needed). >>> >>>> On signal return, if UC_RESTORE_SS is set, then restore >>>> sigcontext->ss. If not, then set SS to __USER_DS (as old kernels >>>> did). >>>> >>>> This should change nothing at all (except the initial value of >>>> sigcontext->ss / __pad0) on old kernels. >>> >>> Agreed. >>> >> Let me throw out one more possibility, just for completeness: >> >> We don't add any SA_xyz flags. On signal delivery, we use the LAR >> heuristic. We always fill in sigcontext->ss, and we set a new >> UC_SIGCONTEXT_SS flag to indicate that we support the new behavior. >> >> On sigreturn, we honor the sigcontext's ss, *unless* CS is 64 bit and >> SS is invalid. In the latter case, we replace the saved ss with >> __USER_DS. > > But this is not a new proposal, see here: > https://lkml.org/lkml/2015/8/13/436 > The very last sentence says exactly the same. > I thought this is in the past. :) > True, but I still want to make sure I understand the alternatives well, and we never really considered this approach. >> This should work for old DOSEMU. It's a bit gross, but it has the >> nice benefit that everyone (even things that aren't DOSEMU) gain the >> ability to catch signals thrown from bogus SS contexts, which probably >> improves debugability. It's also nice to not have the SA flag. > > Pros: > - No new SA flag > - May improve debugability in some unknown scenario where people > do not want to just use the new flag to get their things improved > > Cons: > - Does not allow to cleanly use siglongjmp(), as then there is a risk > to jump to 64bit code with bad SS What's the issue here? I don't understand. On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it won't be affected. AFAIK all implementations of siglongjmp are likely to call sigprocmask or similar, and that will clobber SS. I'm not aware of an implementation of siglongjmp that uses sigreturn. > - Async signals can silently "validate" SS behind your back True, and that's unfortunate. But async signals without SA_SAVE_SS set with the other approach have exactly the same problem. At least with the approach it won't happen in 32-bit or 16-bit code, as we'd only do the heuristic SS fix on sigreturn when returning to 64-bit code. > - No way to extend that solution to later fixing the TLS problem True. > - Many ugly checks in the code, that are not always even obvious > (eg you wanted to try verw instead, and there was a gotcha with > NP bit) Also true. OTOH, there'll be a unit test. > > Is the new SA flag such a big deal here to even bother? Not really, but given that the new behavior seems clearly better behaved than the old, it would be nice to be able to have the good behavior, or at least most of it, be the default. --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-09-02 17:10 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <q4hPI-bE-23@gated-at.bofh.it> |
| In reply to | #1217641 |
On Wed, Sep 2, 2015 at 7:21 AM, Andy Lutomirski <luto@amacapital.net> wrote: > On Wed, Sep 2, 2015 at 2:17 AM, Stas Sergeev <stsp@list.ru> wrote: >> 02.09.2015 08:12, Andy Lutomirski пишет: >> >>> On Wed, Aug 19, 2015 at 9:30 AM, Stas Sergeev <stsp@list.ru> wrote: >>>> >>>> 19.08.2015 18:46, Andy Lutomirski пишет: >>>>> >>>>> On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev <stsp@list.ru> wrote: >>>>>>> >>>>>>> Incidentally, I tried implementing the sigaction flag approach. I >>>>>>> think it's no good. When we return from a signal, there's no concept >>>>>>> of sigaction -- it's just sigreturn. Sigreturn can't look up the >>>>>>> sigaction flags -- what if the signal handler calls sigaction itself. >>>>>> >>>>>> How about the SA_hyz flag that does the following: >>>>>> - Saves SS into sigcontext >>>>>> - Forces SS to USER_DS on signal delivery >>>>>> - Sets the uc_flags flag for sigreturn() to take care of the rest. >>>>>> You'll have both the control on every bit of action, and a simple >>>>>> detection logic: if SA_hyz didn't set the uc flag - it didn't work. >>>>>> You can even employ your lar heuristic here for the case when the >>>>>> aforementioned SA_hyz is not set. But please, please not when it is >>>>>> set! In fact, I wonder if you had in mind exactly that: using the >>>>>> lar heuristic only if the SA_hyz is not set. If so - I misunderstood. >>>>>> Just please don't add it when it is set. >>>>> >>>>> Hmm, interesting. Maybe that would work for everything. How's this >>>>> to make it concrete? >>>>> >>>>> Add a sigaction flag SA_RESTORE_SS. >>>>> >>>>> On signal delivery, always save SS into sigcontext->ss. if >>>>> SA_RESTORE_SS is set, then unconditionally switch HW SS to __USER_DS >>>>> and set UC_RESTORE_SS. If SA_RESTORE_SS is clear, then leave HW SS >>>>> alone (i.e. preserve the old behavior). >>>> >>>> Either that, or employ the lar heuristic for the "not set" case >>>> (I think its not needed). >>>> >>>>> On signal return, if UC_RESTORE_SS is set, then restore >>>>> sigcontext->ss. If not, then set SS to __USER_DS (as old kernels >>>>> did). >>>>> >>>>> This should change nothing at all (except the initial value of >>>>> sigcontext->ss / __pad0) on old kernels. >>>> >>>> Agreed. >>>> >>> Let me throw out one more possibility, just for completeness: >>> >>> We don't add any SA_xyz flags. On signal delivery, we use the LAR >>> heuristic. We always fill in sigcontext->ss, and we set a new >>> UC_SIGCONTEXT_SS flag to indicate that we support the new behavior. >>> >>> On sigreturn, we honor the sigcontext's ss, *unless* CS is 64 bit and >>> SS is invalid. In the latter case, we replace the saved ss with >>> __USER_DS. >> >> But this is not a new proposal, see here: >> https://lkml.org/lkml/2015/8/13/436 >> The very last sentence says exactly the same. >> I thought this is in the past. :) >> > > True, but I still want to make sure I understand the alternatives > well, and we never really considered this approach. > >>> This should work for old DOSEMU. It's a bit gross, but it has the >>> nice benefit that everyone (even things that aren't DOSEMU) gain the >>> ability to catch signals thrown from bogus SS contexts, which probably >>> improves debugability. It's also nice to not have the SA flag. >> >> Pros: >> - No new SA flag >> - May improve debugability in some unknown scenario where people >> do not want to just use the new flag to get their things improved >> >> Cons: >> - Does not allow to cleanly use siglongjmp(), as then there is a risk >> to jump to 64bit code with bad SS > > What's the issue here? I don't understand. > > On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it > won't be affected. AFAIK all implementations of siglongjmp are likely > to call sigprocmask or similar, and that will clobber SS. I'm not > aware of an implementation of siglongjmp that uses sigreturn. > >> - Async signals can silently "validate" SS behind your back > > True, and that's unfortunate. But async signals without SA_SAVE_SS > set with the other approach have exactly the same problem. At least > with the approach it won't happen in 32-bit or 16-bit code, as we'd > only do the heuristic SS fix on sigreturn when returning to 64-bit > code. > >> - No way to extend that solution to later fixing the TLS problem > > True. > >> - Many ugly checks in the code, that are not always even obvious >> (eg you wanted to try verw instead, and there was a gotcha with >> NP bit) > > Also true. OTOH, there'll be a unit test. > >> >> Is the new SA flag such a big deal here to even bother? > > Not really, but given that the new behavior seems clearly better > behaved than the old, it would be nice to be able to have the good > behavior, or at least most of it, be the default. > In fact, I think we can do even better. On signal delivery: - Always set UC_SAVED_SS (for feature detection) - Always save SS into sigcontext - Use the LAR heuristic to fix SS - If the old CS was 64-bit, set UC_STRICT_RESTORE_SS On sigreturn: - Ignore UC_SAVED_SS. - Restore SS. - If the restored SS is bad, the new CS is 64-bit, and UC_STRICT_RESTORE_SS is *not* set, then replace SS with __USER_DS. In other words, we honor the sigcontext SS *unless* the original signal context was not 64-bit (or UC_STRICT_RESTORE_SS was otherwise cleared), the new context is 64-bit, and the new SS is bad. If I understand correctly, old dosemu will keep working: old dosemu never sigreturns back to anything other than 64-bit mode because it can't. (Unless there's a case where it does flat 32-bit mode using __USER_DS -- is there?) CRIU should be fine, since modern CRIU already saves and restore SS and since older CRIU presumably doesn't set UC_STRICT_RESTORE_SS. sigcontext_64 will work unmodified because it'll pick up UC_STRICT_RESTORE_SS automatically as it does its weird sigreturns directly from raise(). New DOSEMU can detect that the old workarounds aren't needed when it sees UC_SAVED_SS and, if it wants stricter behavior, it can manually mask off UC_STRICT_RESTORE_SS. Old Wine won't be affected because I don't think Wine ever does 32-bit emulation from a 64-bit binary in the first place. Faults due to bad SS will never be silently fixed up because the silent fixup only happens if the signal handler explicitly changes CS, and only things that are aware of segmentation will do that. (IOW some random SIGALRM handler isn't going to touch sigcontext->cs.) The new behavior is arguably not even insane. People who reset CS to some 64-bit value probably don't care what's in SS on return since SS has no effect in 64-bit mode except possibly causing IRET to fail. The only thing that seems to care is the DOSEMU IRET trampoline, and that reprograms SS anyway (unless I'm still missing something). Thoughts? --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]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | linux.kernel
csiph-web