[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrX4rqttiZc1P5aVT3f2teg0iBzPytnJ=RRxNQaEMLGvKQ@mail.gmail.com>
Date: Wed, 2 Sep 2015 07:08:45 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Stas Sergeev <stsp@...t.ru>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Andrew Bird (Sphere Systems)" <ajb@...eresystems.co.uk>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...nel.org>,
Kees Cook <keescook@...omium.org>,
Brian Gerst <brgerst@...il.com>
Subject: Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and
default it to 'n')
On Sep 2, 2015 2:51 AM, "Stas Sergeev" <stsp@...t.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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists