Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1217446 > unrolled thread
| Started by | Stas Sergeev <stsp@list.ru> |
|---|---|
| First post | 2015-09-02 11:40 +0200 |
| Last post | 2015-09-02 22:30 +0200 |
| Articles | 20 on this page of 40 — 8 participants |
Back to article view | Back to linux.kernel
stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-02 11:40 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Andy Lutomirski <luto@amacapital.net> - 2015-09-02 16:10 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Kees Cook <keescook@chromium.org> - 2015-09-02 17:40 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-02 19:40 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Josh Boyer <jwboyer@fedoraproject.org> - 2015-09-02 19:50 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-02 20:00 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Josh Boyer <jwboyer@fedoraproject.org> - 2015-09-02 22:30 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-02 22:50 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Andy Lutomirski <luto@amacapital.net> - 2015-09-02 23:00 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Josh Boyer <jwboyer@fedoraproject.org> - 2015-09-02 23:00 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-02 23:10 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Andy Lutomirski <luto@amacapital.net> - 2015-09-02 23:50 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-02 23:50 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-03 14:20 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-03 14:20 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-03 17:50 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-03 18:40 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-03 21:00 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-03 23:30 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Chuck Ebbert <cebbert.lkml@gmail.com> - 2015-09-04 12:10 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-04 12:50 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-04 14:40 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-04 15:10 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-04 22:00 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-04 23:20 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-04 23:30 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Raymond Jennings <shentino@gmail.com> - 2015-09-05 00:50 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-05 01:20 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-04 00:40 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Linus Torvalds <torvalds@linux-foundation.org> - 2015-09-03 19:00 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Andy Lutomirski <luto@amacapital.net> - 2015-09-03 19:30 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-03 19:40 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-03 19:30 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-03 19:20 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev <stsp@list.ru> - 2015-09-03 14:10 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-03 14:10 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Kees Cook <keescook@chromium.org> - 2015-09-02 20:00 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Josh Boyer <jwboyer@fedoraproject.org> - 2015-09-02 22:30 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Andy Lutomirski <luto@amacapital.net> - 2015-09-02 20:20 +0200
Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Josh Boyer <jwboyer@fedoraproject.org> - 2015-09-02 22:30 +0200
Page 1 of 2 [1] 2 Next page →
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-09-02 11:40 +0200 |
| Subject | stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') |
| Message-ID | <q4cGm-17b-15@gated-at.bofh.it> |
https://lkml.org/lkml/2015/7/21/208 Guys, you gonna be kidding. Is this a new trend of breaking dosemu, or what? > VM86 is entirely broken if ptrace, syscall auditing, or > NOHZ_FULL is in use. The code is a big undocumented mess, it's > a real PITA to test, and it looks like a big chunk of vm86_32.c It is a CPU feature that kernel should support, and always did without any problems. If it started to have problems because of your actions, then you can as well fix your code. > No one should be using it anyway. Use DOSBOX or KVM instead. Have you done the benchmarks between dosbox and dosemu before saying that? Please do, thanks. (don't forget to include dosemu2 in your benchmarks too, as it outperforms both) > Let's accelerate its slow death. > + Enabling this option adds considerable attack surface to the > + kernel and slows down system calls and exception handling. Yes, I realize that threatening people with the "considerable attack surface" is a good way to "accelerate its slow death", but please care to explain that attack surface, thankyou. -- 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] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-09-02 16:10 +0200 |
| Message-ID | <q4gTD-7hJ-1@gated-at.bofh.it> |
| In reply to | #1217446 |
On Sep 2, 2015 2:51 AM, "Stas Sergeev" <stsp@list.ru> wrote: > > https://lkml.org/lkml/2015/7/21/208 > > Guys, you gonna be kidding. > Is this a new trend of breaking dosemu, or what? > >> VM86 is entirely broken if ptrace, syscall auditing, or >> NOHZ_FULL is in use. The code is a big undocumented mess, it's >> a real PITA to test, and it looks like a big chunk of vm86_32.c > > > It is a CPU feature that kernel should support, and always > did without any problems. If it started to have problems because > of your actions, then you can as well fix your code. > > > No one should be using it anyway. Use DOSBOX or KVM instead. > > Have you done the benchmarks between dosbox and dosemu > before saying that? Please do, thanks. (don't forget to include > dosemu2 in your benchmarks too, as it outperforms both) I wasn't aware of your dosemu variant at the time, and I incorrectly thought that dosemu was unmaintained. Does real mode performance matter any more? > >> Let's accelerate its slow death. > > Dosemu is much less dead than I thought it was when I wrote that patch. Sorry :( > > > + Enabling this option adds considerable attack surface to the > > + kernel and slows down system calls and exception handling. > > Yes, I realize that threatening people with the "considerable attack surface" > is a good way to "accelerate its slow death", but please care to explain > that attack surface, thankyou. The user_mode vs user_mode_vm thing was scary and contained at least one real bug. That particular issue is gone now, though. Before Brian's cleanups, vm86 did horrible things to the entry asm, the stack layout, and signal handling, and that scared me. That's hopefully in much better shape now, though. The mark_screen_rdonly thing is still kind of scary. It changes PTEs on arbitrary mappings behind the vm's back. I'd be amenable to switching the default back to y and perhaps adding a sysctl to make the distros more comfortable. Ingo, Kees, Brian, what do you think? --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 | Kees Cook <keescook@chromium.org> |
|---|---|
| Date | 2015-09-02 17:40 +0200 |
| Message-ID | <q4iiK-JG-9@gated-at.bofh.it> |
| In reply to | #1217617 |
On Wed, Sep 2, 2015 at 7:08 AM, Andy Lutomirski <luto@amacapital.net> wrote: > On Sep 2, 2015 2:51 AM, "Stas Sergeev" <stsp@list.ru> wrote: >> >> https://lkml.org/lkml/2015/7/21/208 >> >> Guys, you gonna be kidding. >> Is this a new trend of breaking dosemu, or what? >> >>> VM86 is entirely broken if ptrace, syscall auditing, or >>> NOHZ_FULL is in use. The code is a big undocumented mess, it's >>> a real PITA to test, and it looks like a big chunk of vm86_32.c >> >> >> It is a CPU feature that kernel should support, and always >> did without any problems. If it started to have problems because >> of your actions, then you can as well fix your code. >> >> > No one should be using it anyway. Use DOSBOX or KVM instead. >> >> Have you done the benchmarks between dosbox and dosemu >> before saying that? Please do, thanks. (don't forget to include >> dosemu2 in your benchmarks too, as it outperforms both) > > I wasn't aware of your dosemu variant at the time, and I incorrectly > thought that dosemu was unmaintained. > > Does real mode performance matter any more? > >> >>> Let's accelerate its slow death. >> >> > > Dosemu is much less dead than I thought it was when I wrote that > patch. Sorry :( > >> >> > + Enabling this option adds considerable attack surface to the >> > + kernel and slows down system calls and exception handling. >> >> Yes, I realize that threatening people with the "considerable attack surface" >> is a good way to "accelerate its slow death", but please care to explain >> that attack surface, thankyou. > > The user_mode vs user_mode_vm thing was scary and contained at least > one real bug. That particular issue is gone now, though. > > Before Brian's cleanups, vm86 did horrible things to the entry asm, > the stack layout, and signal handling, and that scared me. That's > hopefully in much better shape now, though. > > The mark_screen_rdonly thing is still kind of scary. It changes PTEs > on arbitrary mappings behind the vm's back. > > I'd be amenable to switching the default back to y and perhaps adding > a sysctl to make the distros more comfortable. Ingo, Kees, Brian, > what do you think? Yeah, I think putting this under distro control (and user control) is the best option here. -Kees -- Kees Cook Chrome OS Security -- 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 19:40 +0200 |
| Message-ID | <q4kaS-3pO-23@gated-at.bofh.it> |
| In reply to | #1217617 |
02.09.2015 17:08, Andy Lutomirski пишет: > On Sep 2, 2015 2:51 AM, "Stas Sergeev" <stsp@list.ru> wrote: >> >> https://lkml.org/lkml/2015/7/21/208 >> >> Guys, you gonna be kidding. >> Is this a new trend of breaking dosemu, or what? >> >>> VM86 is entirely broken if ptrace, syscall auditing, or >>> NOHZ_FULL is in use. The code is a big undocumented mess, it's >>> a real PITA to test, and it looks like a big chunk of vm86_32.c >> >> >> It is a CPU feature that kernel should support, and always >> did without any problems. If it started to have problems because >> of your actions, then you can as well fix your code. >> >>> No one should be using it anyway. Use DOSBOX or KVM instead. >> >> Have you done the benchmarks between dosbox and dosemu >> before saying that? Please do, thanks. (don't forget to include >> dosemu2 in your benchmarks too, as it outperforms both) > > I wasn't aware of your dosemu variant at the time, and I incorrectly > thought that dosemu was unmaintained. This is roughly true to my knowledge, hence the forks. > Does real mode performance matter any more? People that control their legacy HW with DOS program wants the real-time performance. They even run dosemu with non-default scheduling policies sometimes (although I doubt it really helps). > The mark_screen_rdonly thing is still kind of scary. It changes PTEs > on arbitrary mappings behind the vm's back. Then you can start removing things step-by-step. mark_screen_rdonly is likely a bad interface, I wonder if someone uses it. There are indeed too many legacy things in vm86(), but there is no point to disable it completely. > I'd be amenable to switching the default back to y and perhaps adding > a sysctl to make the distros more comfortable. Ingo, Kees, Brian, > what do you think? I'd say you can just remove what looks bad and fix the rest. Then disabling it can be done under "if EMBEDDED" only. Eg, the BIOSSEG stuff looks like a candidate for removal, return_for_pic, screen_rdonly and many other absolutely useless things. If it is reduced to the bare minimum, I wonder if there will still be the desire to make it configurable under non-if-EMBEDDED. -- 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 | Josh Boyer <jwboyer@fedoraproject.org> |
|---|---|
| Date | 2015-09-02 19:50 +0200 |
| Message-ID | <q4kky-3Dm-9@gated-at.bofh.it> |
| In reply to | #1217617 |
On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net> wrote: > I'd be amenable to switching the default back to y and perhaps adding > a sysctl to make the distros more comfortable. Ingo, Kees, Brian, > what do you think? Can you please leave the default as N, and have a sysctl option to enable it instead? While dosemu might still be in use, it isn't going to be the common case at all. So from a distro perspective, I think we'd probably rather have the default match the common case. As an aside, the "distros can use a sysctl" thing is kind of misleading. The default should be the common case, and the sysctl knobs should be for end users that wish to differ. That might not sound like much of a difference from an upstream kernel perspective, but it is. Having to install sysctl config files to get a proper default set distro-wide, and then having the end users either remove them or edit them is a lot of hassle from a distro perspective. josh -- 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 20:00 +0200 |
| Message-ID | <q4kue-3Oz-9@gated-at.bofh.it> |
| In reply to | #1217776 |
02.09.2015 20:46, Josh Boyer пишет: > On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net> wrote: >> I'd be amenable to switching the default back to y and perhaps adding >> a sysctl to make the distros more comfortable. Ingo, Kees, Brian, >> what do you think? > > Can you please leave the default as N, and have a sysctl option to > enable it instead? While dosemu might still be in use, it isn't going > to be the common case at all. So from a distro perspective, I think > we'd probably rather have the default match the common case. The fact that fedora doesn't package dosemu, doesn't automatically mean all other distros do not too. Since when kernel defaults should match the ones of fedora? vm86() is a mess, but it can be cleaned up so much that it just won't be a big deal at all. -- 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 | Josh Boyer <jwboyer@fedoraproject.org> |
|---|---|
| Date | 2015-09-02 22:30 +0200 |
| Message-ID | <q4mPo-7io-9@gated-at.bofh.it> |
| In reply to | #1217777 |
On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote: > 02.09.2015 20:46, Josh Boyer пишет: >> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net> wrote: >>> I'd be amenable to switching the default back to y and perhaps adding >>> a sysctl to make the distros more comfortable. Ingo, Kees, Brian, >>> what do you think? >> >> Can you please leave the default as N, and have a sysctl option to >> enable it instead? While dosemu might still be in use, it isn't going >> to be the common case at all. So from a distro perspective, I think >> we'd probably rather have the default match the common case. > The fact that fedora doesn't package dosemu, doesn't automatically > mean all other distros do not too. Since when kernel defaults should > match the ones of fedora? I didn't say that. The default right now is N. I asked it be left that way. That's all. josh -- 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 22:50 +0200 |
| Message-ID | <q4n8J-7EF-5@gated-at.bofh.it> |
| In reply to | #1217841 |
02.09.2015 23:22, Josh Boyer пишет: > On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote: >> 02.09.2015 20:46, Josh Boyer пишет: >>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net> wrote: >>>> I'd be amenable to switching the default back to y and perhaps adding >>>> a sysctl to make the distros more comfortable. Ingo, Kees, Brian, >>>> what do you think? >>> Can you please leave the default as N, and have a sysctl option to >>> enable it instead? While dosemu might still be in use, it isn't going >>> to be the common case at all. So from a distro perspective, I think >>> we'd probably rather have the default match the common case. >> The fact that fedora doesn't package dosemu, doesn't automatically >> mean all other distros do not too. Since when kernel defaults should >> match the ones of fedora? > I didn't say that. What you said was: --- While dosemu might still be in use, it isn't going to be the common case at all. So from a distro perspective --- ... which is likely true only in fedora circe. > The default right now is N. In a not yet released kernel, unless I am mistaken. If fedora already provides that kernel, other distros likely not. > I asked it be left > that way. That's all. Lets assume its not yet N, unless there was a kernel release already. Its easy to get back if its not too late. -- 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 23:00 +0200 |
| Message-ID | <q4niq-7PZ-9@gated-at.bofh.it> |
| In reply to | #1217850 |
On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@list.ru> wrote: > 02.09.2015 23:22, Josh Boyer пишет: >> >> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote: >>> >>> 02.09.2015 20:46, Josh Boyer пишет: >>>> >>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net> >>>> wrote: >>>>> >>>>> I'd be amenable to switching the default back to y and perhaps adding >>>>> a sysctl to make the distros more comfortable. Ingo, Kees, Brian, >>>>> what do you think? >>>> >>>> Can you please leave the default as N, and have a sysctl option to >>>> enable it instead? While dosemu might still be in use, it isn't going >>>> to be the common case at all. So from a distro perspective, I think >>>> we'd probably rather have the default match the common case. >>> >>> The fact that fedora doesn't package dosemu, doesn't automatically >>> mean all other distros do not too. Since when kernel defaults should >>> match the ones of fedora? >> >> I didn't say that. > > What you said was: > --- > > While dosemu might still be in use, it isn't going > to be the common case at all. So from a distro perspective > > --- > ... which is likely true only in fedora circe. > >> The default right now is N. > > In a not yet released kernel, unless I am mistaken. > If fedora already provides that kernel, other distros likely not. > >> I asked it be left >> that way. That's all. > > Lets assume its not yet N, unless there was a kernel release already. > Its easy to get back if its not too late. How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y? Fedora could set it to N. --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 | Josh Boyer <jwboyer@fedoraproject.org> |
|---|---|
| Date | 2015-09-02 23:00 +0200 |
| Message-ID | <q4niq-7PZ-13@gated-at.bofh.it> |
| In reply to | #1217852 |
On Wed, Sep 2, 2015 at 4:55 PM, Andy Lutomirski <luto@amacapital.net> wrote: > On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@list.ru> wrote: >> 02.09.2015 23:22, Josh Boyer пишет: >>> >>> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote: >>>> >>>> 02.09.2015 20:46, Josh Boyer пишет: >>>>> >>>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net> >>>>> wrote: >>>>>> >>>>>> I'd be amenable to switching the default back to y and perhaps adding >>>>>> a sysctl to make the distros more comfortable. Ingo, Kees, Brian, >>>>>> what do you think? >>>>> >>>>> Can you please leave the default as N, and have a sysctl option to >>>>> enable it instead? While dosemu might still be in use, it isn't going >>>>> to be the common case at all. So from a distro perspective, I think >>>>> we'd probably rather have the default match the common case. >>>> >>>> The fact that fedora doesn't package dosemu, doesn't automatically >>>> mean all other distros do not too. Since when kernel defaults should >>>> match the ones of fedora? >>> >>> I didn't say that. >> >> What you said was: >> --- >> >> While dosemu might still be in use, it isn't going >> to be the common case at all. So from a distro perspective >> >> --- >> ... which is likely true only in fedora circe. >> >>> The default right now is N. >> >> In a not yet released kernel, unless I am mistaken. >> If fedora already provides that kernel, other distros likely not. We do. >>> I asked it be left >>> that way. That's all. >> >> Lets assume its not yet N, unless there was a kernel release already. >> Its easy to get back if its not too late. You are correct. > How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y? Fedora > could set it to N. Works for me. josh -- 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 23:10 +0200 |
| Message-ID | <q4ns6-8gJ-9@gated-at.bofh.it> |
| In reply to | #1217852 |
02.09.2015 23:55, Andy Lutomirski пишет: > On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@list.ru> wrote: >> 02.09.2015 23:22, Josh Boyer пишет: >>> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote: >>>> 02.09.2015 20:46, Josh Boyer пишет: >>>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net> >>>>> wrote: >>>>>> I'd be amenable to switching the default back to y and perhaps adding >>>>>> a sysctl to make the distros more comfortable. Ingo, Kees, Brian, >>>>>> what do you think? >>>>> Can you please leave the default as N, and have a sysctl option to >>>>> enable it instead? While dosemu might still be in use, it isn't going >>>>> to be the common case at all. So from a distro perspective, I think >>>>> we'd probably rather have the default match the common case. >>>> The fact that fedora doesn't package dosemu, doesn't automatically >>>> mean all other distros do not too. Since when kernel defaults should >>>> match the ones of fedora? >>> I didn't say that. >> What you said was: >> --- >> >> While dosemu might still be in use, it isn't going >> to be the common case at all. So from a distro perspective >> >> --- >> ... which is likely true only in fedora circe. >> >>> The default right now is N. >> In a not yet released kernel, unless I am mistaken. >> If fedora already provides that kernel, other distros likely not. >> >>> I asked it be left >>> that way. That's all. >> Lets assume its not yet N, unless there was a kernel release already. >> Its easy to get back if its not too late. > How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y? Fedora > could set it to N. Sorry, I don't understand this sysctl proposal. Could you please educate me what is it all about? This sysctl will disable or enable the vm86() syscall at run-time, right? What does it give us? If you disable something in the config, this gives you, say, smaller kernel image. If OTOH you add the run-time switch, it gives you a bigger image, regardless of its default value. I might be missing something, but I don't understand what problem will this solve? Have I missed some earlier message in this thread? -- 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 23:50 +0200 |
| Message-ID | <q4o4O-yd-3@gated-at.bofh.it> |
| In reply to | #1217859 |
On Wed, Sep 2, 2015 at 2:12 PM, Stas Sergeev <stsp@list.ru> wrote: > 02.09.2015 23:55, Andy Lutomirski пишет: > >> On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@list.ru> wrote: >>> >>> 02.09.2015 23:22, Josh Boyer пишет: >>>> >>>> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote: >>>>> >>>>> 02.09.2015 20:46, Josh Boyer пишет: >>>>>> >>>>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net> >>>>>> wrote: >>>>>>> >>>>>>> I'd be amenable to switching the default back to y and perhaps adding >>>>>>> a sysctl to make the distros more comfortable. Ingo, Kees, Brian, >>>>>>> what do you think? >>>>>> >>>>>> Can you please leave the default as N, and have a sysctl option to >>>>>> enable it instead? While dosemu might still be in use, it isn't going >>>>>> to be the common case at all. So from a distro perspective, I think >>>>>> we'd probably rather have the default match the common case. >>>>> >>>>> The fact that fedora doesn't package dosemu, doesn't automatically >>>>> mean all other distros do not too. Since when kernel defaults should >>>>> match the ones of fedora? >>>> >>>> I didn't say that. >>> >>> What you said was: >>> --- >>> >>> While dosemu might still be in use, it isn't going >>> to be the common case at all. So from a distro perspective >>> >>> --- >>> ... which is likely true only in fedora circe. >>> >>>> The default right now is N. >>> >>> In a not yet released kernel, unless I am mistaken. >>> If fedora already provides that kernel, other distros likely not. >>> >>>> I asked it be left >>>> that way. That's all. >>> >>> Lets assume its not yet N, unless there was a kernel release already. >>> Its easy to get back if its not too late. >> >> How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y? Fedora >> could set it to N. > > Sorry, I don't understand this sysctl proposal. > Could you please educate me what is it all about? > This sysctl will disable or enable the vm86() syscall at run-time, > right? What does it give us? If you disable something in the > config, this gives you, say, smaller kernel image. If OTOH you > add the run-time switch, it gives you a bigger image, regardless > of its default value. > I might be missing something, but I don't understand what > problem will this solve? Have I missed some earlier message > in this thread? For the 99%+ of users who don't use dosemu, it prevents exploits that target vm86 from attacking their kernel. --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-09-02 23:50 +0200 |
| Message-ID | <q4o4P-yd-23@gated-at.bofh.it> |
| In reply to | #1217869 |
03.09.2015 00:40, Andy Lutomirski пишет: > On Wed, Sep 2, 2015 at 2:12 PM, Stas Sergeev <stsp@list.ru> wrote: >> 02.09.2015 23:55, Andy Lutomirski пишет: >> >>> On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@list.ru> wrote: >>>> 02.09.2015 23:22, Josh Boyer пишет: >>>>> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote: >>>>>> 02.09.2015 20:46, Josh Boyer пишет: >>>>>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net> >>>>>>> wrote: >>>>>>>> I'd be amenable to switching the default back to y and perhaps adding >>>>>>>> a sysctl to make the distros more comfortable. Ingo, Kees, Brian, >>>>>>>> what do you think? >>>>>>> Can you please leave the default as N, and have a sysctl option to >>>>>>> enable it instead? While dosemu might still be in use, it isn't going >>>>>>> to be the common case at all. So from a distro perspective, I think >>>>>>> we'd probably rather have the default match the common case. >>>>>> The fact that fedora doesn't package dosemu, doesn't automatically >>>>>> mean all other distros do not too. Since when kernel defaults should >>>>>> match the ones of fedora? >>>>> I didn't say that. >>>> What you said was: >>>> --- >>>> >>>> While dosemu might still be in use, it isn't going >>>> to be the common case at all. So from a distro perspective >>>> >>>> --- >>>> ... which is likely true only in fedora circe. >>>> >>>>> The default right now is N. >>>> In a not yet released kernel, unless I am mistaken. >>>> If fedora already provides that kernel, other distros likely not. >>>> >>>>> I asked it be left >>>>> that way. That's all. >>>> Lets assume its not yet N, unless there was a kernel release already. >>>> Its easy to get back if its not too late. >>> How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y? Fedora >>> could set it to N. >> Sorry, I don't understand this sysctl proposal. >> Could you please educate me what is it all about? >> This sysctl will disable or enable the vm86() syscall at run-time, >> right? What does it give us? If you disable something in the >> config, this gives you, say, smaller kernel image. If OTOH you >> add the run-time switch, it gives you a bigger image, regardless >> of its default value. >> I might be missing something, but I don't understand what >> problem will this solve? Have I missed some earlier message >> in this thread? > For the 99%+ of users who don't use dosemu, it prevents exploits that > target vm86 from attacking their kernel. I don't think the attack scenario was satisfactory explained. IIRC you only said that --- The mark_screen_rdonly thing is still kind of scary. It changes PTEs on arbitrary mappings behind the vm's back. --- Just go ahead and remove mark_screen_rdonly, big deal. Is this all of the threat? Or do we treat _every_ syscall as the potential attack target? -- 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 | Austin S Hemmelgarn <ahferroin7@gmail.com> |
|---|---|
| Date | 2015-09-03 14:20 +0200 |
| Message-ID | <q4BEK-3hX-23@gated-at.bofh.it> |
| In reply to | #1217870 |
[Multipart message — attachments visible in raw view] — view raw
On 2015-09-02 17:53, Stas Sergeev wrote: > 03.09.2015 00:40, Andy Lutomirski пишет: >> On Wed, Sep 2, 2015 at 2:12 PM, Stas Sergeev <stsp@list.ru> wrote: >>> 02.09.2015 23:55, Andy Lutomirski пишет: >>> >>>> On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@list.ru> wrote: >>>>> 02.09.2015 23:22, Josh Boyer пишет: >>>>>> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote: >>>>>>> 02.09.2015 20:46, Josh Boyer пишет: >>>>>>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski >>>>>>>> <luto@amacapital.net> >>>>>>>> wrote: >>>>>>>>> I'd be amenable to switching the default back to y and perhaps >>>>>>>>> adding >>>>>>>>> a sysctl to make the distros more comfortable. Ingo, Kees, Brian, >>>>>>>>> what do you think? >>>>>>>> Can you please leave the default as N, and have a sysctl option to >>>>>>>> enable it instead? While dosemu might still be in use, it isn't >>>>>>>> going >>>>>>>> to be the common case at all. So from a distro perspective, I >>>>>>>> think >>>>>>>> we'd probably rather have the default match the common case. >>>>>>> The fact that fedora doesn't package dosemu, doesn't automatically >>>>>>> mean all other distros do not too. Since when kernel defaults should >>>>>>> match the ones of fedora? >>>>>> I didn't say that. >>>>> What you said was: >>>>> --- >>>>> >>>>> While dosemu might still be in use, it isn't going >>>>> to be the common case at all. So from a distro perspective >>>>> >>>>> --- >>>>> ... which is likely true only in fedora circe. >>>>> >>>>>> The default right now is N. >>>>> In a not yet released kernel, unless I am mistaken. >>>>> If fedora already provides that kernel, other distros likely not. >>>>> >>>>>> I asked it be left >>>>>> that way. That's all. >>>>> Lets assume its not yet N, unless there was a kernel release already. >>>>> Its easy to get back if its not too late. >>>> How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y? Fedora >>>> could set it to N. >>> Sorry, I don't understand this sysctl proposal. >>> Could you please educate me what is it all about? >>> This sysctl will disable or enable the vm86() syscall at run-time, >>> right? What does it give us? If you disable something in the >>> config, this gives you, say, smaller kernel image. If OTOH you >>> add the run-time switch, it gives you a bigger image, regardless >>> of its default value. >>> I might be missing something, but I don't understand what >>> problem will this solve? Have I missed some earlier message >>> in this thread? >> For the 99%+ of users who don't use dosemu, it prevents exploits that >> target vm86 from attacking their kernel. > I don't think the attack scenario was satisfactory explained. > IIRC you only said that > --- > > The mark_screen_rdonly thing is still kind of scary. It changes PTEs > on arbitrary mappings behind the vm's back. > > --- > Just go ahead and remove mark_screen_rdonly, big deal. > Is this all of the threat? > Or do we treat _every_ syscall as the potential attack target? Anything that messes with the VM subsystem (doubly if it does so without actually calling into the VM subsystem) is a potential target, as is anything that messes with execution mode or privilege level (as in, possibly messes with which ring (or whatevere equivalent metaphor other processors use) execution is happening in). This does potentially all three (depending on how it's called). Just because there are no known working exploits doesn't mean it's not possible, and in the case of this code, I'd say there is almost certainly some way to exploit it either to crash the system or gain root-equivalent privileges.
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-09-03 14:20 +0200 |
| Message-ID | <q4BEL-3hX-33@gated-at.bofh.it> |
| In reply to | #1218201 |
03.09.2015 15:11, Austin S Hemmelgarn пишет: > On 2015-09-02 17:53, Stas Sergeev wrote: >> 03.09.2015 00:40, Andy Lutomirski пишет: >>> On Wed, Sep 2, 2015 at 2:12 PM, Stas Sergeev <stsp@list.ru> wrote: >>>> 02.09.2015 23:55, Andy Lutomirski пишет: >>>> >>>>> On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@list.ru> wrote: >>>>>> 02.09.2015 23:22, Josh Boyer пишет: >>>>>>> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote: >>>>>>>> 02.09.2015 20:46, Josh Boyer пишет: >>>>>>>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski >>>>>>>>> <luto@amacapital.net> >>>>>>>>> wrote: >>>>>>>>>> I'd be amenable to switching the default back to y and perhaps >>>>>>>>>> adding >>>>>>>>>> a sysctl to make the distros more comfortable. Ingo, Kees, Brian, >>>>>>>>>> what do you think? >>>>>>>>> Can you please leave the default as N, and have a sysctl option to >>>>>>>>> enable it instead? While dosemu might still be in use, it isn't >>>>>>>>> going >>>>>>>>> to be the common case at all. So from a distro perspective, I >>>>>>>>> think >>>>>>>>> we'd probably rather have the default match the common case. >>>>>>>> The fact that fedora doesn't package dosemu, doesn't automatically >>>>>>>> mean all other distros do not too. Since when kernel defaults should >>>>>>>> match the ones of fedora? >>>>>>> I didn't say that. >>>>>> What you said was: >>>>>> --- >>>>>> >>>>>> While dosemu might still be in use, it isn't going >>>>>> to be the common case at all. So from a distro perspective >>>>>> >>>>>> --- >>>>>> ... which is likely true only in fedora circe. >>>>>> >>>>>>> The default right now is N. >>>>>> In a not yet released kernel, unless I am mistaken. >>>>>> If fedora already provides that kernel, other distros likely not. >>>>>> >>>>>>> I asked it be left >>>>>>> that way. That's all. >>>>>> Lets assume its not yet N, unless there was a kernel release already. >>>>>> Its easy to get back if its not too late. >>>>> How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y? Fedora >>>>> could set it to N. >>>> Sorry, I don't understand this sysctl proposal. >>>> Could you please educate me what is it all about? >>>> This sysctl will disable or enable the vm86() syscall at run-time, >>>> right? What does it give us? If you disable something in the >>>> config, this gives you, say, smaller kernel image. If OTOH you >>>> add the run-time switch, it gives you a bigger image, regardless >>>> of its default value. >>>> I might be missing something, but I don't understand what >>>> problem will this solve? Have I missed some earlier message >>>> in this thread? >>> For the 99%+ of users who don't use dosemu, it prevents exploits that >>> target vm86 from attacking their kernel. >> I don't think the attack scenario was satisfactory explained. >> IIRC you only said that >> --- >> >> The mark_screen_rdonly thing is still kind of scary. It changes PTEs >> on arbitrary mappings behind the vm's back. >> >> --- >> Just go ahead and remove mark_screen_rdonly, big deal. >> Is this all of the threat? >> Or do we treat _every_ syscall as the potential attack target? > Anything that messes with the VM subsystem (doubly if it does so without actually calling into the VM subsystem) is a potential target ... and should be removed. Remove mark_screen_rdonly hack. > as is anything that messes with execution mode or privilege > level (as in, possibly messes with which ring (or whatevere equivalent metaphor other processors use) execution is happening in). This does potentially all three (depending on how it's called). Just > because there are no known working exploits doesn't mean it's not possible, and in the case of this code, I'd say there is almost certainly some way to exploit it either to crash the system or gain > root-equivalent privileges. Please be specific, show the dangerous code, we'll then remove it or fix it. -- 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 | Austin S Hemmelgarn <ahferroin7@gmail.com> |
|---|---|
| Date | 2015-09-03 17:50 +0200 |
| Message-ID | <q4EVX-7Sc-1@gated-at.bofh.it> |
| In reply to | #1218207 |
[Multipart message — attachments visible in raw view] — view raw
On 2015-09-03 08:15, Stas Sergeev wrote:
> 03.09.2015 15:11, Austin S Hemmelgarn пишет:
>> On 2015-09-02 17:53, Stas Sergeev wrote:
>>> 03.09.2015 00:40, Andy Lutomirski пишет:
>>>> On Wed, Sep 2, 2015 at 2:12 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>> 02.09.2015 23:55, Andy Lutomirski пишет:
>>>>>
>>>>>> On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>>> 02.09.2015 23:22, Josh Boyer пишет:
>>>>>>>> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>>>>> 02.09.2015 20:46, Josh Boyer пишет:
>>>>>>>>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski
>>>>>>>>>> <luto@amacapital.net>
>>>>>>>>>> wrote:
>>>>>>>>>>> I'd be amenable to switching the default back to y and perhaps
>>>>>>>>>>> adding
>>>>>>>>>>> a sysctl to make the distros more comfortable. Ingo, Kees, Brian,
>>>>>>>>>>> what do you think?
>>>>>>>>>> Can you please leave the default as N, and have a sysctl option to
>>>>>>>>>> enable it instead? While dosemu might still be in use, it isn't
>>>>>>>>>> going
>>>>>>>>>> to be the common case at all. So from a distro perspective, I
>>>>>>>>>> think
>>>>>>>>>> we'd probably rather have the default match the common case.
>>>>>>>>> The fact that fedora doesn't package dosemu, doesn't automatically
>>>>>>>>> mean all other distros do not too. Since when kernel defaults should
>>>>>>>>> match the ones of fedora?
>>>>>>>> I didn't say that.
>>>>>>> What you said was:
>>>>>>> ---
>>>>>>>
>>>>>>> While dosemu might still be in use, it isn't going
>>>>>>> to be the common case at all. So from a distro perspective
>>>>>>>
>>>>>>> ---
>>>>>>> ... which is likely true only in fedora circe.
>>>>>>>
>>>>>>>> The default right now is N.
>>>>>>> In a not yet released kernel, unless I am mistaken.
>>>>>>> If fedora already provides that kernel, other distros likely not.
>>>>>>>
>>>>>>>> I asked it be left
>>>>>>>> that way. That's all.
>>>>>>> Lets assume its not yet N, unless there was a kernel release already.
>>>>>>> Its easy to get back if its not too late.
>>>>>> How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y? Fedora
>>>>>> could set it to N.
>>>>> Sorry, I don't understand this sysctl proposal.
>>>>> Could you please educate me what is it all about?
>>>>> This sysctl will disable or enable the vm86() syscall at run-time,
>>>>> right? What does it give us? If you disable something in the
>>>>> config, this gives you, say, smaller kernel image. If OTOH you
>>>>> add the run-time switch, it gives you a bigger image, regardless
>>>>> of its default value.
>>>>> I might be missing something, but I don't understand what
>>>>> problem will this solve? Have I missed some earlier message
>>>>> in this thread?
>>>> For the 99%+ of users who don't use dosemu, it prevents exploits that
>>>> target vm86 from attacking their kernel.
>>> I don't think the attack scenario was satisfactory explained.
>>> IIRC you only said that
>>> ---
>>>
>>> The mark_screen_rdonly thing is still kind of scary. It changes PTEs
>>> on arbitrary mappings behind the vm's back.
>>>
>>> ---
>>> Just go ahead and remove mark_screen_rdonly, big deal.
>>> Is this all of the threat?
>>> Or do we treat _every_ syscall as the potential attack target?
>> Anything that messes with the VM subsystem (doubly if it does so without actually calling into the VM subsystem) is a potential target
> ... and should be removed.
> Remove mark_screen_rdonly hack.
>
>> as is anything that messes with execution mode or privilege
>> level (as in, possibly messes with which ring (or whatevere equivalent metaphor other processors use) execution is happening in). This does potentially all three (depending on how it's called). Just
>> because there are no known working exploits doesn't mean it's not possible, and in the case of this code, I'd say there is almost certainly some way to exploit it either to crash the system or gain
>> root-equivalent privileges.
> Please be specific, show the dangerous code, we'll then remove it
> or fix it.
>
The problem is we don't _know_ what could be exploited in there. There
is no way to know for certain without a full audit of the code (and even
that wouldn't be certain to catch everything), which is almost certainly
not going to happen unless someone pays a very large amount of money for it.
We should not however, wait to disable something by default that
(probably) less than 1% of the people who are running Linux on systems
that can even use this are actually using until someone demonstrates a
workable exploit. Security is not just a reactionary endeavor, you need
to be proactive about it as well. This means minimizing the attack
surface whenever possible (and yes, this an potential attack vector,
regardless of whether there are known workable exploits or not).
What has been proposed follows the existing convention on Linux (don't
break userspace, and provide the option to people who actually care
about their systems being secure to turn it off), the current proposal
is to make it default to on in the defconfig, and have the sysctl
default to leaving it enabled.
On top of this, vm86 has a set of very specific niche use cases, most
syscalls like this (AIO, bpf(), seccomp(), {m,f}advise(), etc) can only
be turned on and off by completely rebuilding the kernel. This lets you
turn this on or off at runtime.
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-09-03 18:40 +0200 |
| Message-ID | <q4FIn-AC-31@gated-at.bofh.it> |
| In reply to | #1218384 |
03.09.2015 18:44, Austin S Hemmelgarn пишет:
> On 2015-09-03 08:15, Stas Sergeev wrote:
>> 03.09.2015 15:11, Austin S Hemmelgarn пишет:
>>> On 2015-09-02 17:53, Stas Sergeev wrote:
>>>> 03.09.2015 00:40, Andy Lutomirski пишет:
>>>>> On Wed, Sep 2, 2015 at 2:12 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>> 02.09.2015 23:55, Andy Lutomirski пишет:
>>>>>>
>>>>>>> On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>>>> 02.09.2015 23:22, Josh Boyer пишет:
>>>>>>>>> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>>>>>> 02.09.2015 20:46, Josh Boyer пишет:
>>>>>>>>>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski
>>>>>>>>>>> <luto@amacapital.net>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> I'd be amenable to switching the default back to y and perhaps
>>>>>>>>>>>> adding
>>>>>>>>>>>> a sysctl to make the distros more comfortable. Ingo, Kees, Brian,
>>>>>>>>>>>> what do you think?
>>>>>>>>>>> Can you please leave the default as N, and have a sysctl option to
>>>>>>>>>>> enable it instead? While dosemu might still be in use, it isn't
>>>>>>>>>>> going
>>>>>>>>>>> to be the common case at all. So from a distro perspective, I
>>>>>>>>>>> think
>>>>>>>>>>> we'd probably rather have the default match the common case.
>>>>>>>>>> The fact that fedora doesn't package dosemu, doesn't automatically
>>>>>>>>>> mean all other distros do not too. Since when kernel defaults should
>>>>>>>>>> match the ones of fedora?
>>>>>>>>> I didn't say that.
>>>>>>>> What you said was:
>>>>>>>> ---
>>>>>>>>
>>>>>>>> While dosemu might still be in use, it isn't going
>>>>>>>> to be the common case at all. So from a distro perspective
>>>>>>>>
>>>>>>>> ---
>>>>>>>> ... which is likely true only in fedora circe.
>>>>>>>>
>>>>>>>>> The default right now is N.
>>>>>>>> In a not yet released kernel, unless I am mistaken.
>>>>>>>> If fedora already provides that kernel, other distros likely not.
>>>>>>>>
>>>>>>>>> I asked it be left
>>>>>>>>> that way. That's all.
>>>>>>>> Lets assume its not yet N, unless there was a kernel release already.
>>>>>>>> Its easy to get back if its not too late.
>>>>>>> How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y? Fedora
>>>>>>> could set it to N.
>>>>>> Sorry, I don't understand this sysctl proposal.
>>>>>> Could you please educate me what is it all about?
>>>>>> This sysctl will disable or enable the vm86() syscall at run-time,
>>>>>> right? What does it give us? If you disable something in the
>>>>>> config, this gives you, say, smaller kernel image. If OTOH you
>>>>>> add the run-time switch, it gives you a bigger image, regardless
>>>>>> of its default value.
>>>>>> I might be missing something, but I don't understand what
>>>>>> problem will this solve? Have I missed some earlier message
>>>>>> in this thread?
>>>>> For the 99%+ of users who don't use dosemu, it prevents exploits that
>>>>> target vm86 from attacking their kernel.
>>>> I don't think the attack scenario was satisfactory explained.
>>>> IIRC you only said that
>>>> ---
>>>>
>>>> The mark_screen_rdonly thing is still kind of scary. It changes PTEs
>>>> on arbitrary mappings behind the vm's back.
>>>>
>>>> ---
>>>> Just go ahead and remove mark_screen_rdonly, big deal.
>>>> Is this all of the threat?
>>>> Or do we treat _every_ syscall as the potential attack target?
>>> Anything that messes with the VM subsystem (doubly if it does so without actually calling into the VM subsystem) is a potential target
>> ... and should be removed.
>> Remove mark_screen_rdonly hack.
>>
>>> as is anything that messes with execution mode or privilege
>>> level (as in, possibly messes with which ring (or whatevere equivalent metaphor other processors use) execution is happening in). This does potentially all three (depending on how it's called). Just
>>> because there are no known working exploits doesn't mean it's not possible, and in the case of this code, I'd say there is almost certainly some way to exploit it either to crash the system or gain
>>> root-equivalent privileges.
>> Please be specific, show the dangerous code, we'll then remove it
>> or fix it.
>>
> The problem is we don't _know_ what could be exploited in there. There is no way to know for certain without a full audit of the code
As was indicated in this thread already:
https://lkml.org/lkml/2015/9/2/317
Brian Gerst recently audited it:
---
That's
hopefully in much better shape now, though.
---
> We should not however, wait to disable something by default that (probably) less than 1% of the people who are running Linux on systems that can even use this are actually using
I am puzzled with this "probably".
Given that ubuntu and debian do provide it, and that (unmaintained)
SF page shows a few hundreds of downloads per week, how have you calculated
the probability of its user base being below 1% of all linux users?
Please provide more details so that I can double-check.
> until someone
> demonstrates a workable exploit. Security is not just a reactionary endeavor, you need to be proactive about it as well. This means minimizing the attack surface whenever possible (and yes, this an
> potential attack vector, regardless of whether there are known workable exploits or not).
There are ways to minimize the risk: just remove the bloat, then
see what remains.
If you leave the bloat and just call it "dangerous", people will
start disabling it, because _then_ it will really be an unmaintained
attack target. So what you propose, is the worst solution, not the best.
It will threaten the current vm86() users instead of doing them a
favour by cleaning and fixing the code, and they will start looking
into abandoning it.
> What has been proposed follows the existing convention on Linux (don't break userspace, and provide the option to people who actually care about their systems being secure to turn it off), the current
> proposal is to make it default to on in the defconfig, and have the sysctl default to leaving it enabled.
>
> On top of this, vm86 has a set of very specific niche use cases, most syscalls like this (AIO, bpf(), seccomp(), {m,f}advise(), etc) can only be turned on and off by completely rebuilding the kernel.
"on and off"? Nice, but they are On by default (except for bpf()).
So the fact that they have no runtime knob doesn't look like a big
surprise.
> This lets you turn this on or off at runtime.
With a big warning that "it is an attack surface and less than
1% of people use it, please don't touch"? No thankyou.
I'll be looking into testing and sending the patch that removes
mark_screen_rdonly. Maybe then this thread will shift a bit from
guesses and assumptions.
--
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 | Austin S Hemmelgarn <ahferroin7@gmail.com> |
|---|---|
| Date | 2015-09-03 21:00 +0200 |
| Message-ID | <q4HTQ-3EU-7@gated-at.bofh.it> |
| In reply to | #1218430 |
[Multipart message — attachments visible in raw view] — view raw
On 2015-09-03 12:34, Stas Sergeev wrote:
> 03.09.2015 18:44, Austin S Hemmelgarn пишет:
>> On 2015-09-03 08:15, Stas Sergeev wrote:
>>> 03.09.2015 15:11, Austin S Hemmelgarn пишет:
>>>> On 2015-09-02 17:53, Stas Sergeev wrote:
[... trimmed for brevity ...]
>>>>> I don't think the attack scenario was satisfactory explained.
>>>>> IIRC you only said that
>>>>> ---
>>>>>
>>>>> The mark_screen_rdonly thing is still kind of scary. It changes PTEs
>>>>> on arbitrary mappings behind the vm's back.
>>>>>
>>>>> ---
>>>>> Just go ahead and remove mark_screen_rdonly, big deal.
>>>>> Is this all of the threat?
>>>>> Or do we treat _every_ syscall as the potential attack target?
>>>> Anything that messes with the VM subsystem (doubly if it does so without actually calling into the VM subsystem) is a potential target
>>> ... and should be removed.
>>> Remove mark_screen_rdonly hack.
>>>
>>>> as is anything that messes with execution mode or privilege
>>>> level (as in, possibly messes with which ring (or whatevere equivalent metaphor other processors use) execution is happening in). This does potentially all three (depending on how it's called). Just
>>>> because there are no known working exploits doesn't mean it's not possible, and in the case of this code, I'd say there is almost certainly some way to exploit it either to crash the system or gain
>>>> root-equivalent privileges.
>>> Please be specific, show the dangerous code, we'll then remove it
>>> or fix it.
>>>
>> The problem is we don't _know_ what could be exploited in there. There is no way to know for certain without a full audit of the code
> As was indicated in this thread already:
> https://lkml.org/lkml/2015/9/2/317
> Brian Gerst recently audited it:
> ---
> That's
> hopefully in much better shape now, though.
> ---
By audit, I don't mean just one person trying to make it more
maintainable and fixing any bugs he found, I mean a team of people
actively trying to make it break in every way imaginable. I'd be
particularly interested to see how it reacts to being hit from multiple
cores concurrently with trinity.
>> We should not however, wait to disable something by default that (probably) less than 1% of the people who are running Linux on systems that can even use this are actually using
> I am puzzled with this "probably".
> Given that ubuntu and debian do provide it, and that (unmaintained)
> SF page shows a few hundreds of downloads per week, how have you calculated
> the probability of its user base being below 1% of all linux users?
> Please provide more details so that I can double-check.
A few hundred downloads per week, as compared to tens of millions of
people using Linux worldwide (rough guess, although probably
conservative), with 10% of the Linux users using 32-bit x86 (again,
another rough guess, although this one is more generous), still works
out to around 1%. It's not possible to get exact numbers for this, and
downloads from the SF page also happen for the automated build testing
that most modern distributions do these days and a number of reasons
other than people using it.
>> until someone
>> demonstrates a workable exploit. Security is not just a reactionary endeavor, you need to be proactive about it as well. This means minimizing the attack surface whenever possible (and yes, this an
>> potential attack vector, regardless of whether there are known workable exploits or not).
> There are ways to minimize the risk: just remove the bloat, then
> see what remains.
> If you leave the bloat and just call it "dangerous", people will
> start disabling it, because _then_ it will really be an unmaintained
> attack target. So what you propose, is the worst solution, not the best.
> It will threaten the current vm86() users instead of doing them a
> favour by cleaning and fixing the code, and they will start looking
> into abandoning it.
As of right now, the only open-source project that I know of that is
actually actively used by people on new kernels that uses vm86 is dosemu
(and the forked dosemu2). the only other open source user of vm86()
that I know of is v86d, which is no longer needed except on ancient
hardware with old kernels. And as far as proprietary code goes, they
need to pull their heads out of DOS, realize that sane people use
protected or long mode for modern software, and get on with their lives.
I'm not saying that we shouldn't improve the code, but that we need to
provide the option to turn this off at runtime. Just one program that
isn't used by a large segment of the community depending on something is
not a good reason to make everyone have it turned on.
There are servers out there that have this enabled and _never_ use it at
all, having a system call like this one usable but unused is a potential
security hole, period, irrespective of the quality of the code the
syscall executes.
As for abandoning it, that is happening already, 32-bit x86 systems are
becoming more and more difficult to find, and it's not supported at all
on 64-bit kernels.
>
>> What has been proposed follows the existing convention on Linux (don't break userspace, and provide the option to people who actually care about their systems being secure to turn it off), the current
>> proposal is to make it default to on in the defconfig, and have the sysctl default to leaving it enabled.
>>
>> On top of this, vm86 has a set of very specific niche use cases, most syscalls like this (AIO, bpf(), seccomp(), {m,f}advise(), etc) can only be turned on and off by completely rebuilding the kernel.
> "on and off"? Nice, but they are On by default (except for bpf()).
> So the fact that they have no runtime knob doesn't look like a big
> surprise.
Most of those (other than seccomp) are used almost exclusively in server
applications, and in the case of AIO, it is possible to prevent anything
from using it at runtime, but this can't be sanely relayed to any
applications that use it (bonus points if you can figure out how to stop
everyone from using it and why applications can't easily detect this).
>> This lets you turn this on or off at runtime.
> With a big warning that "it is an attack surface and less than
> 1% of people use it, please don't touch"? No thankyou.
I'm not saying that such a warning should be put in, and based on the
backlash that the original change that sparked this thread got, nothing
like that is going to be put in, but there is no reason to not be able
to enable/disable it at runtime. Most people who are using desktop
systems are not going to inherently know if they need it or not until
they do need it, and unlike many of the other syscalls that can be
disabled, many people who are likely to be using it aren't the type who
are comfortable compiling their own kernel.
> I'll be looking into testing and sending the patch that removes
> mark_screen_rdonly. Maybe then this thread will shift a bit from
> guesses and assumptions.
My statement that there is a potential security risk inherent in vm86 is
not a guess or assumption, it's a fact. Every single way that user code
can call into the kernel is a potential attack vector, period,
irrespective of what it does. You can't say with 100% certainty that
something is not a possible attack vector unless it isn't there to begin
with. While disabling it at runtime is not the best option from a
security standpoint, it makes it a much more difficult to even try to
exploit the code.
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-09-03 23:30 +0200 |
| Message-ID | <q4Kf0-77B-13@gated-at.bofh.it> |
| In reply to | #1218519 |
03.09.2015 21:51, Austin S Hemmelgarn пишет: > On 2015-09-03 12:34, Stas Sergeev wrote: >> https://lkml.org/lkml/2015/9/2/317 >> Brian Gerst recently audited it: >> --- >> That's >> hopefully in much better shape now, though. >> --- > By audit, I don't mean just one person trying to make it more > maintainable and fixing any bugs he found, I mean a team of people > actively trying to make it break in every way imaginable. I'd be > particularly interested to see how it reacts to being hit from > multiple cores concurrently with trinity. Well, without a good clean-up first, such a test makes no sense. If you know beforehand that the code is in a bad state and use test to prove that and disable (instead of fixing), then its not the best way to go. I'd like to see "how it reacts to being hit from multiple cores concurrently with trinity", but only after the already known bloat is stripped. >>> We should not however, wait to disable something by default that >>> (probably) less than 1% of the people who are running Linux on >>> systems that can even use this are actually using >> I am puzzled with this "probably". >> Given that ubuntu and debian do provide it, and that (unmaintained) >> SF page shows a few hundreds of downloads per week, how have you >> calculated >> the probability of its user base being below 1% of all linux users? >> Please provide more details so that I can double-check. > A few hundred downloads per week, as compared to tens of millions of > people using Linux worldwide Who cares about the absolute numbers of SF downloads? Ubuntu and debian do provide it - that gives the majority of users. SF download numbers should IMHO only be compared to the SF numbers of other SF-hosted projects. Getting some extrapolation from that is difficult but possible if you can find out the user base for a few of those "other" projects. I have never done such a research of course. > As of right now, the only open-source project that I know of that is > actually actively used by people on new kernels that uses vm86 is > dosemu (and the forked dosemu2). the only other open source user of > vm86() that I know of is v86d, svgalib too. Not sure how dead it is though (likely incompatible with KMS). > which is no longer needed except on ancient hardware with old kernels. > And as far as proprietary code goes, they need to pull their heads out > of DOS, realize that sane people use protected or long mode for modern > software, and get on with their lives. Software is usually not such a big deal as the hardware is. Some unsupported but expensive HW may be difficult to replace, and that's where dosemu helps. > I'm not saying that we shouldn't improve the code, but that we need to > provide the option to turn this off at runtime. With Linus's proposal there will be one. It is so because the option he proposed is meaningful: it disables the well-known attack scenario - NULL pointer deref in kernel. Facing with that option, user knows what risk does he accept (and that risk is known to be small). But having a meaningless knob with a strange "attack surface" threat is IMO absolutely unacceptable. > There are servers out there that have this enabled and _never_ use it > at all, Unless I am mistaken, servers usually use special flavour of the distro (different from desktop install), where of course this will be disabled _compile time_. > As for abandoning it, that is happening already, 32-bit x86 systems > are becoming more and more difficult to find, and it's not supported > at all on 64-bit kernels. Maybe, but please let users to abandon it themselves when they are ready to, rather than with the rude actions (disabling by default or threatening). >> This lets you turn this on or off at runtime. >> With a big warning that "it is an attack surface and less than >> 1% of people use it, please don't touch"? No thankyou. > I'm not saying that such a warning should be put in, and based on the > backlash that the original change that sparked this thread got, > nothing like that is going to be put in, + Enabling this option adds considerable attack surface to the + kernel and slows down system calls and exception handling. It is _already_ there. > but there is no reason to not be able to enable/disable it at > runtime. Most people who are using desktop systems are not going to > inherently know if they need it or not until they do need it, and > unlike many of the other syscalls that can be disabled, 1. How many syscalls can currently be disabled at run-time? 2. How many of them are called an "attack surface", forcing users to disable them? 3. For how many of the above, the attack scenario was not even outlined? (other than that any syscall is a potential threat) If, as you say, that action followed some existing practice, there should be some more to fit all 3 above criteries. >> I'll be looking into testing and sending the patch that removes >> mark_screen_rdonly. Maybe then this thread will shift a bit from >> guesses and assumptions. > My statement that there is a potential security risk inherent in vm86 > is not a guess or assumption, it's a fact. Every single way that user > code can call into the kernel is a potential attack vector, period, > irrespective of what it does. Maybe, but then, please mark every syscall with the above statement in Kconfig and provide a knob. So far only vm86() was marked as such, it seems. My question is simple: what makes vm86() so much different? If the answer is "the reluctance to fix it", then the treatment was likely not adequate. > You can't say with 100% certainty that something is not a possible > attack vector unless it isn't there to begin with. I am only asking to not make an exceptions for vm86(), unless the reason can be clearly stated. If it is not any worse than all other syscalls, then please treat it fairly. Linus recalled about the mmap_min_addr - now it can be treated fairly, in a light of a well-known low-risk threat. But the above Kconfig statement should IMHO be removed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Chuck Ebbert <cebbert.lkml@gmail.com> |
|---|---|
| Date | 2015-09-04 12:10 +0200 |
| Subject | Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') |
| Message-ID | <q4W6u-7nE-9@gated-at.bofh.it> |
| In reply to | #1218584 |
On Fri, 4 Sep 2015 00:28:04 +0300 Stas Sergeev <stsp@list.ru> wrote: > 03.09.2015 21:51, Austin S Hemmelgarn пишет: > > There are servers out there that have this enabled and _never_ use it > > at all, > Unless I am mistaken, servers usually use special flavour of the > distro (different from desktop install), where of course this will > be disabled _compile time_. > Many (most?) distros use just one kernel for everything, because it's just too much work to have a separate flavor for servers. -- 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 1 of 2 [1] 2 Next page →
Back to top | Article view | linux.kernel
csiph-web