lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ