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 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-08-14 01:10 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX9Nf-QH-21@gated-at.bofh.it> |
| In reply to | #1207216 |
On Thu, Aug 13, 2015 at 3:51 PM, Stas Sergeev <stsp@list.ru> wrote:
> 14.08.2015 01:29, Andy Lutomirski пишет:
>>
>> On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>
>>> 14.08.2015 01:11, Andy Lutomirski пишет:
>>>
>>>> Now suppose you set some magic flag and jump (via sigreturn,
>>>> trampoline, whatever) into DOS code. The DOS code loads 0x7 into FS
>>>> and then gets #GP. You land in a signal handler. As far as the
>>>> kernel's concerned, the FS base register is whatever the base of LDT
>>>> entry 0 is. What else is the kernel supposed to shove in there?
>>>
>>> The same as what happens when you do in userspace:
>>> ---
>>> asm ("mov $0,%%fs\n");
>>> prctl(ARCH_SET_FS, my_tls_base);
>>> ---
>>>
>>> This was the trick I did before gcc started to use FS in prolog,
>>> now I have to do this in asm.
>>> But how simpler for the kernel is to do the same?
>>>
>>>> I think that making this work fully in the kernel would require a
>>>> full-blown FS equivalent of sigaltstack, and that seems like overkill.
>>>
>>> Setting selector and base is what you call an "equivalent of
>>> sigaltstack"?
>>
>> Yes. sigaltstack says "hey, kernel! here's my SP for signal
>> handling." I think we'd need something similar to tell the kernel
>> what my_tls_base is. Using the most recent thing passed to
>> ARCH_SET_FS is no good because WRFSBASE systems might not use
>> ARCH_SET_FS, and we can't break DOSEMU on Ivy Bridge and newer as soon
>> as we enable WRFSBASE.
>
> If someone uses WRFSBASE and wants things to be preserved
> in a sighandler, he'll just not set the aforementioned flag. No regression.
> Whoever wants to use that flag properly, will not use WRFSBASE,
> and will use ARCH_SET_FS or set_thread_area().
> What exactly breakage do you have in mind?
DOSEMU, when you set that flag, WRFSBASE gets enabled, and glibc's
threading library starts using WRFSBASE instead of arch_prctl.
--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-14 01:20 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX9WW-11U-7@gated-at.bofh.it> |
| In reply to | #1207228 |
14.08.2015 02:00, Andy Lutomirski пишет:
> On Thu, Aug 13, 2015 at 3:51 PM, Stas Sergeev <stsp@list.ru> wrote:
>> 14.08.2015 01:29, Andy Lutomirski пишет:
>>> On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>> 14.08.2015 01:11, Andy Lutomirski пишет:
>>>>
>>>>> Now suppose you set some magic flag and jump (via sigreturn,
>>>>> trampoline, whatever) into DOS code. The DOS code loads 0x7 into FS
>>>>> and then gets #GP. You land in a signal handler. As far as the
>>>>> kernel's concerned, the FS base register is whatever the base of LDT
>>>>> entry 0 is. What else is the kernel supposed to shove in there?
>>>> The same as what happens when you do in userspace:
>>>> ---
>>>> asm ("mov $0,%%fs\n");
>>>> prctl(ARCH_SET_FS, my_tls_base);
>>>> ---
>>>>
>>>> This was the trick I did before gcc started to use FS in prolog,
>>>> now I have to do this in asm.
>>>> But how simpler for the kernel is to do the same?
>>>>
>>>>> I think that making this work fully in the kernel would require a
>>>>> full-blown FS equivalent of sigaltstack, and that seems like overkill.
>>>> Setting selector and base is what you call an "equivalent of
>>>> sigaltstack"?
>>> Yes. sigaltstack says "hey, kernel! here's my SP for signal
>>> handling." I think we'd need something similar to tell the kernel
>>> what my_tls_base is. Using the most recent thing passed to
>>> ARCH_SET_FS is no good because WRFSBASE systems might not use
>>> ARCH_SET_FS, and we can't break DOSEMU on Ivy Bridge and newer as soon
>>> as we enable WRFSBASE.
>> If someone uses WRFSBASE and wants things to be preserved
>> in a sighandler, he'll just not set the aforementioned flag. No regression.
>> Whoever wants to use that flag properly, will not use WRFSBASE,
>> and will use ARCH_SET_FS or set_thread_area().
>> What exactly breakage do you have in mind?
> DOSEMU, when you set that flag, WRFSBASE gets enabled, and glibc's
> threading library starts using WRFSBASE instead of arch_prctl.
Whoever wants to use the new flag, will need to call
prctl(ARCH_SET_FS, needed_tls) or the like, before altering FS.
"needed_tls" will be the current TLS in most cases.
This will make kernel to know what TLS should be restored in
sighandler. Yes, that's resembles sigaltstack to some degree,
but is simple? Nothing special on kernel side, and not a big
deal for the user to call prctl().
--
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-14 02:10 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pXaJj-2bP-1@gated-at.bofh.it> |
| In reply to | #1207228 |
On Thu, Aug 13, 2015 at 5:00 PM, Stas Sergeev <stsp@list.ru> wrote:
> 14.08.2015 02:00, Andy Lutomirski пишет:
>
>> On Thu, Aug 13, 2015 at 3:51 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>
>>> 14.08.2015 01:29, Andy Lutomirski пишет:
>>>>
>>>> On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>
>>>>> 14.08.2015 01:11, Andy Lutomirski пишет:
>>>>>
>>>>>> Now suppose you set some magic flag and jump (via sigreturn,
>>>>>> trampoline, whatever) into DOS code. The DOS code loads 0x7 into FS
>>>>>> and then gets #GP. You land in a signal handler. As far as the
>>>>>> kernel's concerned, the FS base register is whatever the base of LDT
>>>>>> entry 0 is. What else is the kernel supposed to shove in there?
>>>>>
>>>>> The same as what happens when you do in userspace:
>>>>> ---
>>>>> asm ("mov $0,%%fs\n");
>>>>> prctl(ARCH_SET_FS, my_tls_base);
>>>>> ---
>>>>>
>>>>> This was the trick I did before gcc started to use FS in prolog,
>>>>> now I have to do this in asm.
>>>>> But how simpler for the kernel is to do the same?
>>>>>
>>>>>> I think that making this work fully in the kernel would require a
>>>>>> full-blown FS equivalent of sigaltstack, and that seems like overkill.
>>>>>
>>>>> Setting selector and base is what you call an "equivalent of
>>>>> sigaltstack"?
>>>>
>>>> Yes. sigaltstack says "hey, kernel! here's my SP for signal
>>>> handling." I think we'd need something similar to tell the kernel
>>>> what my_tls_base is. Using the most recent thing passed to
>>>> ARCH_SET_FS is no good because WRFSBASE systems might not use
>>>> ARCH_SET_FS, and we can't break DOSEMU on Ivy Bridge and newer as soon
>>>> as we enable WRFSBASE.
>>>
>>> If someone uses WRFSBASE and wants things to be preserved
>>> in a sighandler, he'll just not set the aforementioned flag. No
>>> regression.
>>> Whoever wants to use that flag properly, will not use WRFSBASE,
>>> and will use ARCH_SET_FS or set_thread_area().
>>> What exactly breakage do you have in mind?
>>
>> DOSEMU, when you set that flag, WRFSBASE gets enabled, and glibc's
>> threading library starts using WRFSBASE instead of arch_prctl.
>
> Hmm, how about the following:
>
> prctl(ARCH_SET_SIGNAL_FS, my_tls)
> If my_tls==NULL - use current fsbase (including one of WRFSBASE).
> If my_tls==(void)-1 - don't restore.
>
> Can this work?
Certainly, but why? ISTM user code should do this itself with a
little bit of asm unless there's a good reason it wouldn't work. A
good reason it wouldn't work is that high-performance applications
need this and an extra syscall is too slow, but IMO that would need
evidence.
--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-14 02:20 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pXaT1-2nu-27@gated-at.bofh.it> |
| In reply to | #1207253 |
14.08.2015 03:05, Andy Lutomirski пишет:
> On Thu, Aug 13, 2015 at 5:00 PM, Stas Sergeev <stsp@list.ru> wrote:
>> 14.08.2015 02:00, Andy Lutomirski пишет:
>>
>>> On Thu, Aug 13, 2015 at 3:51 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>> 14.08.2015 01:29, Andy Lutomirski пишет:
>>>>> On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>> 14.08.2015 01:11, Andy Lutomirski пишет:
>>>>>>
>>>>>>> Now suppose you set some magic flag and jump (via sigreturn,
>>>>>>> trampoline, whatever) into DOS code. The DOS code loads 0x7 into FS
>>>>>>> and then gets #GP. You land in a signal handler. As far as the
>>>>>>> kernel's concerned, the FS base register is whatever the base of LDT
>>>>>>> entry 0 is. What else is the kernel supposed to shove in there?
>>>>>> The same as what happens when you do in userspace:
>>>>>> ---
>>>>>> asm ("mov $0,%%fs\n");
>>>>>> prctl(ARCH_SET_FS, my_tls_base);
>>>>>> ---
>>>>>>
>>>>>> This was the trick I did before gcc started to use FS in prolog,
>>>>>> now I have to do this in asm.
>>>>>> But how simpler for the kernel is to do the same?
>>>>>>
>>>>>>> I think that making this work fully in the kernel would require a
>>>>>>> full-blown FS equivalent of sigaltstack, and that seems like overkill.
>>>>>> Setting selector and base is what you call an "equivalent of
>>>>>> sigaltstack"?
>>>>> Yes. sigaltstack says "hey, kernel! here's my SP for signal
>>>>> handling." I think we'd need something similar to tell the kernel
>>>>> what my_tls_base is. Using the most recent thing passed to
>>>>> ARCH_SET_FS is no good because WRFSBASE systems might not use
>>>>> ARCH_SET_FS, and we can't break DOSEMU on Ivy Bridge and newer as soon
>>>>> as we enable WRFSBASE.
>>>> If someone uses WRFSBASE and wants things to be preserved
>>>> in a sighandler, he'll just not set the aforementioned flag. No
>>>> regression.
>>>> Whoever wants to use that flag properly, will not use WRFSBASE,
>>>> and will use ARCH_SET_FS or set_thread_area().
>>>> What exactly breakage do you have in mind?
>>> DOSEMU, when you set that flag, WRFSBASE gets enabled, and glibc's
>>> threading library starts using WRFSBASE instead of arch_prctl.
>> Hmm, how about the following:
>>
>> prctl(ARCH_SET_SIGNAL_FS, my_tls)
>> If my_tls==NULL - use current fsbase (including one of WRFSBASE).
>> If my_tls==(void)-1 - don't restore.
>>
>> Can this work?
> Certainly, but why?
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",
and this will fix the regression right here right now, without
any lar heuristic, and will keep the correct behaviour of always
restoring ss for those who need that.
> ISTM user code should do this itself with a
> little bit of asm unless there's a good reason it wouldn't work.
Any example of that asm?
I can even code up the ARCH_SET_SIGNAL_SS patch if you want,
it seems absolutely trivial, much simpler than the aforementioned asm,
much simpler than the patches you propose.
So my question is more like "why not", rather than "why".
Just because it is simple and clean, IMHO.
--
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-14 02:30 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pXb2G-2yG-3@gated-at.bofh.it> |
| In reply to | #1207261 |
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
etc). And off by default because of the obvious compatibility issues.
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 | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-08-14 03:00 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pXbvH-36r-3@gated-at.bofh.it> |
| In reply to | #1207263 |
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. -- 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-14 03:30 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pXbYJ-3Tm-11@gated-at.bofh.it> |
| In reply to | #1207268 |
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. Using a sigaction flag is a bit less weird than using uc_flags. It's also kind of nice that it's more composable -- you can install a SIGUSR1 handler that's just normal code and set SA_SAVE_SS and it'll work, whereas with uc_flags you need to explicitly twiddle uc_flags in the handler. Unfortunately, I don't think we were clever enough to allow this to be probed easily -- we silently ignore unrecognized sa_flags bits. --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-14 03:40 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pXc8p-44A-1@gated-at.bofh.it> |
| In reply to | #1207276 |
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. Sure, we could gate the "regs->ss = __USER_DS" line on a flag, but why? > >> Unfortunately, I don't think we were clever enough to allow this to be >> probed easily -- we silently ignore unrecognized sa_flags bits. > > Big deal, check the kversion. :) Not so good. For example, if you made your DOSEMU patch to use the saved SS check the version, then the backported revert would break you. --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-14 04:10 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pXcBr-4RB-1@gated-at.bofh.it> |
| In reply to | #1207277 |
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. Sure, we could gate the "regs->ss = > __USER_DS" line on a flag, but why? Speed? I'll let others decide on that. My vote is to no heuristic if possible, and keeping the FS problem in mind if possible (obviously, both are possible). >>> Unfortunately, I don't think we were clever enough to allow this to be >>> probed easily -- we silently ignore unrecognized sa_flags bits. >> Big deal, check the kversion. :) > Not so good. For example, if you made your DOSEMU patch to use the > saved SS check the version, then the backported revert would break > you. I would be scared to imagine the program that probes for everything, adding more and more probes with years, instead of just saying "you need kernel version at least x.y.z". If some functionality is reverted, another kversion check can be added. This all is not new: dosemu's protected mode implementation doesn't work on many kernels selectively. IIRC it didn't work on 3.14 because the 16bit LDTs were disallowed, and other versions had problems too. It is easier to ban such kernels by versions instead of adding a run-time probes, because you don't know beforehand what will break in the next kernel to add a probe in advance, and when you react to an existing breakage, it already doesn't matter. The possibly of reverting a new functionality is similar to getting a breakage in an existing functionality (or even have lower probability), so I see no reason to choose different treatments for these two. But of course every author has own habits. -- 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:30 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pYIzg-6pW-7@gated-at.bofh.it> |
| In reply to | #1207277 |
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) - 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? -- 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-14 03:40 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pXc8p-44A-3@gated-at.bofh.it> |
| In reply to | #1207276 |
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. > Unfortunately, I don't think we were clever enough to allow this to be > probed easily -- we silently ignore unrecognized sa_flags bits. Big deal, check the kversion. :) Unforunately, in my eyes SA_xyz doesn't help with FS, so whether it is better than uc_flags or not, is not what I care about. -- 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-14 02:10 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pXaJk-2bP-27@gated-at.bofh.it> |
| In reply to | #1207228 |
On Thu, Aug 13, 2015 at 5:00 PM, Stas Sergeev <stsp@list.ru> wrote:
> 14.08.2015 02:00, Andy Lutomirski пишет:
>>
>> DOSEMU, when you set that flag, WRFSBASE gets enabled, and glibc's
>> threading library starts using WRFSBASE instead of arch_prctl.
>
> Hmm, how about the following:
>
> prctl(ARCH_SET_SIGNAL_FS, my_tls)
> If my_tls==NULL - use current fsbase (including one of WRFSBASE).
> If my_tls==(void)-1 - don't restore.
>
> Can this work?
I'm really inclined to wonder whether we need the change and such a flag at all.
Basically, no _normal_ application will ever play with segments at all
on x86-64. So our current behavior of not touching any segments at all
for signal handling would seem to be the right thing to do - because
it handles all the sane cases optimally.
And applications that *do* play with segments very much know they do
so, and we already put the onus on *them* to save/restore segments.
That's how dosemu clearly works today.
So why not just keep to that policy? It has worked fairly well so
far. Only when we tried to change that policy did we hit these
problems, because existing applications obviously already live with
what we do (or rather, what we _don't_ do) right 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-14 02:30 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pXb2G-2yG-9@gated-at.bofh.it> |
| In reply to | #1207258 |
On Thu, Aug 13, 2015 at 5:08 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Thu, Aug 13, 2015 at 5:00 PM, Stas Sergeev <stsp@list.ru> wrote: >> 14.08.2015 02:00, Andy Lutomirski пишет: >>> >>> DOSEMU, when you set that flag, WRFSBASE gets enabled, and glibc's >>> threading library starts using WRFSBASE instead of arch_prctl. >> >> Hmm, how about the following: >> >> prctl(ARCH_SET_SIGNAL_FS, my_tls) >> If my_tls==NULL - use current fsbase (including one of WRFSBASE). >> If my_tls==(void)-1 - don't restore. >> >> Can this work? > > I'm really inclined to wonder whether we need the change and such a flag at all. > > Basically, no _normal_ application will ever play with segments at all > on x86-64. So our current behavior of not touching any segments at all > for signal handling would seem to be the right thing to do - because > it handles all the sane cases optimally. > > And applications that *do* play with segments very much know they do > so, and we already put the onus on *them* to save/restore segments. > That's how dosemu clearly works today. I agree for all but CS and SS, which are special. CS is fine already. The way that DOSEMU works around SS it is hideous: it just gives up on sigreturn working and fixes the segments with IRET. (Also, if DOSEMU ever wants to get ESP[31:16] right, it *can't*: only the kernel can usefully do espfix64, and DOSEMU can't get the kernel to return from 64-bit code to 16-bit code, because we zap SS. DOSEMU fudges it by forcibly zeroing ESP[31:16]), but that's not a full solution and I wouldn't be surprised if something breaks as a result. So yes, it mostly works. It also sucks, and it makes it extremely unpleasant for any other program to do this. I'd argue that keeping things like the sigreturn_64 test working is quite valuable, because it's a royal PITA to exercise this code cleanly without proper control of SS. Unfortunately, making it hard for sigreturn_64 to exercise this stuff doesn't mean that the bad guys can't do it, because they'll use malformed ELF files, or ptrace, or stupid modify_ldt races (except I hopefully fixed those), or x32, or compat, or some other hack I haven't thought of yet, and they'll hit the same bugs. I've lost count of the number of bugs of various severities that the sigreturn tests have shaken out *and* caught in patches that were emailed in. We could say "forget sigreturn_64, use sigreturn_32 instead", but that can't exercise !IA32_EMULATION kernels, and that code is a bit different. (BadIRET, for example, is nominally unreachable from 64-bit code without modify_ldt and the sigreturn fix, except that I think know of one really nasty way to do it. I have no intention of implementing that, so keeping selftests working nicely makes me *much* more confident.) Obviously, if we reintroduce SS restoration, we need to do it much more carefully. My RFC patches are an attempt to do that, but it needs a lot of care to make sure all the bases are covered. --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-14 02:50 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pXbm1-2Vb-9@gated-at.bofh.it> |
| In reply to | #1207264 |
On Thu, Aug 13, 2015 at 5:24 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>
> So yes, it mostly works. It also sucks, and it makes it extremely
> unpleasant for any other program to do this.
Well, I'd argue that
(a) we don't really _want_ any other programs to do that
(b) but yeah, we might want to make it easier to do cleanly and
explicitly for dosemu (and any other possible programs that do want to
do it)
so if this is for just things like dosemu and for test applications
etc, let's just introduce something like SA_RESTORE_SS for those to
explicitly opt in to "I want this signal handler to save and restore
SS".
That's how we have handled these kinds of things in the past (ie
SA_SIGINFO extends the stack frame with siginfo, sa_restorer says that
user space will use its own sigrestore function, etc etc).
Yeah, the SA_xyzzy flags aren't exactly _common_, but it's how we've
handled these kinds of compat issues in the past (SA_ONESHOT, SA_MASK,
and SA_NOCLDWAIT are obviously about the traditional BSD/SysV
differences, and SA_RESTORER is a Linux internal compatibility thing
etc)
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 | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-08-14 02:10 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pXaJj-2bP-3@gated-at.bofh.it> |
| In reply to | #1207228 |
14.08.2015 02:00, Andy Lutomirski пишет:
> On Thu, Aug 13, 2015 at 3:51 PM, Stas Sergeev <stsp@list.ru> wrote:
>> 14.08.2015 01:29, Andy Lutomirski пишет:
>>> On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>> 14.08.2015 01:11, Andy Lutomirski пишет:
>>>>
>>>>> Now suppose you set some magic flag and jump (via sigreturn,
>>>>> trampoline, whatever) into DOS code. The DOS code loads 0x7 into FS
>>>>> and then gets #GP. You land in a signal handler. As far as the
>>>>> kernel's concerned, the FS base register is whatever the base of LDT
>>>>> entry 0 is. What else is the kernel supposed to shove in there?
>>>> The same as what happens when you do in userspace:
>>>> ---
>>>> asm ("mov $0,%%fs\n");
>>>> prctl(ARCH_SET_FS, my_tls_base);
>>>> ---
>>>>
>>>> This was the trick I did before gcc started to use FS in prolog,
>>>> now I have to do this in asm.
>>>> But how simpler for the kernel is to do the same?
>>>>
>>>>> I think that making this work fully in the kernel would require a
>>>>> full-blown FS equivalent of sigaltstack, and that seems like overkill.
>>>> Setting selector and base is what you call an "equivalent of
>>>> sigaltstack"?
>>> Yes. sigaltstack says "hey, kernel! here's my SP for signal
>>> handling." I think we'd need something similar to tell the kernel
>>> what my_tls_base is. Using the most recent thing passed to
>>> ARCH_SET_FS is no good because WRFSBASE systems might not use
>>> ARCH_SET_FS, and we can't break DOSEMU on Ivy Bridge and newer as soon
>>> as we enable WRFSBASE.
>> If someone uses WRFSBASE and wants things to be preserved
>> in a sighandler, he'll just not set the aforementioned flag. No regression.
>> Whoever wants to use that flag properly, will not use WRFSBASE,
>> and will use ARCH_SET_FS or set_thread_area().
>> What exactly breakage do you have in mind?
> DOSEMU, when you set that flag, WRFSBASE gets enabled, and glibc's
> threading library starts using WRFSBASE instead of arch_prctl.
Hmm, how about the following:
prctl(ARCH_SET_SIGNAL_FS, my_tls)
If my_tls==NULL - use current fsbase (including one of WRFSBASE).
If my_tls==(void)-1 - don't restore.
Can this work?
--
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 | Cyrill Gorcunov <gorcunov@gmail.com> |
|---|---|
| Date | 2015-08-14 09:30 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pXhB7-3Ho-3@gated-at.bofh.it> |
| In reply to | #1207142 |
On Thu, Aug 13, 2015 at 01:09:47PM -0700, Linus Torvalds wrote:
> On Thu, Aug 13, 2015 at 1:08 PM, Cyrill Gorcunov <gorcunov@gmail.com> wrote:
> >
> > If only I'm not missin something obvious this should not hurt us.
> > But I gonna build test kernel and check to be sure tomorrow, ok?
Managed to test it. And criu works fine with the revert as expected.
Actually it's because of commit c6f2062935c8 Oleg made us a patch:
| commit 07dcf0dbb6ff97c255bc6b06569255a9479bccdd
| Author: Oleg Nesterov <oleg@redhat.com>
| Date: Thu Mar 19 19:14:00 2015 +0300
|
| restore/x86: restore_gpregs() needs to initialize ->ss as well
|
| Before the recent "x86_64,signal: Fix SS handling for signals delivered
| to 64-bit programs" kernel patch, sigreturn paths forgot to restore ->ss
| after return from the signal handler.
|
| Now that the kernel was fixed, restore_gpregs() has to initialize ->ss
| too, it is no longer ignored.
| ...
|
| +++ b/arch/x86/include/asm/restorer.h
| @@ -53,7 +53,7 @@ struct rt_sigcontext {
| unsigned short cs;
| unsigned short gs;
| unsigned short fs;
| - unsigned short __pad0;
| + unsigned short ss;
| unsigned long err;
| unsigned long trapno;
| unsigned long oldmask;
IOW we've been not setting up __pad0 which became ss
inside the kernel (in result we've been passing 0 here,
which caused the problem).
fwiw, we declare that new criu versions may require new
kernels to work but never promised that new criu gonna
be compatible with old kernels. That said if something
get changed inside sigcontext structure in future
we may update criu code as well.
--
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 | Pavel Emelyanov <xemul@parallels.com> |
|---|---|
| Date | 2015-08-14 12:10 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pXk5Y-7mp-27@gated-at.bofh.it> |
| In reply to | #1207376 |
On 08/14/2015 10:22 AM, Cyrill Gorcunov wrote:
> On Thu, Aug 13, 2015 at 01:09:47PM -0700, Linus Torvalds wrote:
>> On Thu, Aug 13, 2015 at 1:08 PM, Cyrill Gorcunov <gorcunov@gmail.com> wrote:
>>>
>>> If only I'm not missin something obvious this should not hurt us.
>>> But I gonna build test kernel and check to be sure tomorrow, ok?
>
> Managed to test it. And criu works fine with the revert as expected.
> Actually it's because of commit c6f2062935c8 Oleg made us a patch:
>
> | commit 07dcf0dbb6ff97c255bc6b06569255a9479bccdd
> | Author: Oleg Nesterov <oleg@redhat.com>
> | Date: Thu Mar 19 19:14:00 2015 +0300
> |
> | restore/x86: restore_gpregs() needs to initialize ->ss as well
> |
> | Before the recent "x86_64,signal: Fix SS handling for signals delivered
> | to 64-bit programs" kernel patch, sigreturn paths forgot to restore ->ss
> | after return from the signal handler.
> |
> | Now that the kernel was fixed, restore_gpregs() has to initialize ->ss
> | too, it is no longer ignored.
> | ...
> |
> | +++ b/arch/x86/include/asm/restorer.h
> | @@ -53,7 +53,7 @@ struct rt_sigcontext {
> | unsigned short cs;
> | unsigned short gs;
> | unsigned short fs;
> | - unsigned short __pad0;
> | + unsigned short ss;
> | unsigned long err;
> | unsigned long trapno;
> | unsigned long oldmask;
>
> IOW we've been not setting up __pad0 which became ss
> inside the kernel (in result we've been passing 0 here,
> which caused the problem).
>
> fwiw, we declare that new criu versions may require new
> kernels to work but never promised that new criu gonna
> be compatible with old kernels.
We did. Kernel 3.11 is still declared as supported (modulo new stuff
we added after 1.0 might not work, but basic sigframe mgmt is not one
of those "new" things).
> That said if something
> get changed inside sigcontext structure in future
> we may update criu code as well.
> .
>
--
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 | Cyrill Gorcunov <gorcunov@gmail.com> |
|---|---|
| Date | 2015-08-14 13:00 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pXkSm-8h8-19@gated-at.bofh.it> |
| In reply to | #1207464 |
On Fri, Aug 14, 2015 at 01:02:14PM +0300, Pavel Emelyanov wrote: ... > > IOW we've been not setting up __pad0 which became ss > > inside the kernel (in result we've been passing 0 here, > > which caused the problem). > > > > fwiw, we declare that new criu versions may require new > > kernels to work but never promised that new criu gonna > > be compatible with old kernels. > > We did. Kernel 3.11 is still declared as supported (modulo new stuff > we added after 1.0 might not work, but basic sigframe mgmt is not one > of those "new" things). This won't last forever. And I think it's pretty normal to require a new criu version for new kernel. Cyrill -- 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 21:00 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX5Tk-3pd-13@gated-at.bofh.it> |
| In reply to | #1207059 |
13.08.2015 21:35, Linus Torvalds пишет: > On Thu, Aug 13, 2015 at 10:51 AM, Stas Sergeev <stsp@list.ru> wrote: >> Hello Linus, I verified that patch-minimal.diff is enough >> to fix the problem, BUT! dosemu is in fact using the .fs and >> .gs fields of sigcontext as a placeholders. Why the minimal >> patch alone helps is simply because the kernel headers >> installed in a system do not yet represent the newer kernel >> developments and have the .fs and .gs fields in. > Ok. So I'm inclined to do the bigger revert, just to fix the compile > issue. It would be crazy to force some silly autoconf script for > random header info. But OTOH these fields already lost their meaning. It may make sense to force people to stop using them, in case you ever want to re-use them again in the future. From what Andy says, it seems there are the distant plans to start restoring FS again. If people still use sigcontext.fs by that time, you'll get problems. If you force everyone to stop using them - you'll be safe. Also, at least in the past, resolving the compile-time problems was up to the distributions: they always provided the "sanitized up" version of kernel headers. Not sure what the current policy is... In fact, here in Fedora-22, I have /usr/include/asm/sigcontext.h that is straight from the kernel, but signal.h is instead using a "sanitized up" version in /usr/include/bits/sigcontext.h so the userspace compiles fine. In fact, I think the "silly autoconf script" you mentioned above, should indeed be reverted, and instead I should use sigcontext.reserved1[8] array to store FS/GS? Is this safer against ever re-using this space? Not sure... -- 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 21:10 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX62Z-3Qo-3@gated-at.bofh.it> |
| In reply to | #1207069 |
On Thu, Aug 13, 2015 at 11:57 AM, Stas Sergeev <stsp@list.ru> wrote: > 13.08.2015 21:35, Linus Torvalds пишет: >> >> On Thu, Aug 13, 2015 at 10:51 AM, Stas Sergeev <stsp@list.ru> wrote: >>> >>> Hello Linus, I verified that patch-minimal.diff is enough >>> to fix the problem, BUT! dosemu is in fact using the .fs and >>> .gs fields of sigcontext as a placeholders. Why the minimal >>> patch alone helps is simply because the kernel headers >>> installed in a system do not yet represent the newer kernel >>> developments and have the .fs and .gs fields in. >> >> Ok. So I'm inclined to do the bigger revert, just to fix the compile >> issue. It would be crazy to force some silly autoconf script for >> random header info. > > But OTOH these fields already lost their meaning. > It may make sense to force people to stop using them, > in case you ever want to re-use them again in the future. > From what Andy says, it seems there are the distant plans > to start restoring FS again. If people still use sigcontext.fs > by that time, you'll get problems. If you force everyone to > stop using them - you'll be safe. There are distant plans to think about restoring them, at least. But it's not just FS -- it's FSBASE as well, and that's not going to fit in the same slot. And we still don't get to break old DOSEMU versions (knowingly, anyway). > > In fact, I think the "silly autoconf script" you mentioned above, > should indeed be reverted, and instead I should use > sigcontext.reserved1[8] array to store FS/GS? Is this > safer against ever re-using this space? Not sure... Honestly, I'd just save it somewhere outside sigcontext. If it's application data, treat it as such. OTOH, if you've already been saving it in the old FS/GS slots, I see no great reason to change it. --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]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | linux.kernel
csiph-web