Message-ID: <CALCETrUsG85721akK=6wqHhwEzObc_CyCT55HNRyDqjVdXZ-0g@mail.gmail.com>
Date:	Wed, 8 Jul 2015 11:47:01 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Arjan van de Ven <arjan@...ux.intel.com>,
	Andy Lutomirski <luto@...nel.org>,
	"the arch/x86 maintainers" <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Kees Cook <keescook@...omium.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN

On Wed, Jul 8, 2015 at 10:55 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Wed, Jul 8, 2015 at 10:49 AM, Andy Lutomirski <luto@...capital.net> wrote:
>>
>> I don't know how to tell whether something is trying to use real mode,
>> but I can play this just fine in DOSEMU on my 64-bit laptop:
>
> So a 64-bit distro obviously will never have used vm86 mode - it
> doesn't work there. Never has. There's no sane way to get to vm86 mode
> from long mode, that's just how the 64-bit extensions worked.
>
> (64-bit hardware obviously does support vm86 mode, but you have to
> play games with mixing long mode and CPL0 32-bit protected mode to get
> there, and we never did that).

Eww.  My sanity hurts just thinking about that.  We used to switch in
and out of long mode for EFI mixed mode support, but that's gone now,
since it produced lovely triple faults if perf was running.  As far as
I can tell, those triple faults are basically unfixable without
disabling all NMI sources across long mode switches, and 32-bit EFI
works just fine (i.e. as well as it ever did) in CPL0 compat mode.

So exiting long mode to enter v8086 mode is nuts.  Entering v8086 mode
via VMX would be *much* better, but just not implementing it would be
better still.

>
> It's the 32-bit distros I would worry about. The ones that may have
> well disabled emulation, because they have vm86 mode enabled.
>

Fedora doesn't package dosemu at all, and Ubuntu turns off CONFIG_VM86
AFAIK.  RPMFusion does package dosemu.

Dosemu has a --disable-cpuemu configure option.  A quick check
suggests that neither RPMFusion, Gentoo, nor Arch sets that option
(why would they?).

So maybe there's a couple people with home-built --disable-cpuemu
DOSEMU versions on 32-bit kernels who have syscall auditing and
context tracking off.  It's even plausible that some nonzero number of
them use new kernels, but I'd be kind of surprised.

Weighed against the fact that sys_vm86 under ptrace is probably a
minor security bug* in some circumstances, I don't think the case for
preserving vm86 support looks all that good.  OTOH, if someone were to
actually complain, that would be a different story.  That's why I
suggested marking it BROKEN instead of deleting it outright.

* I'm planning on fixing that particular issue regardless on whether
CONFIG_VM86 is marked BROKEN.**

** I don't know enough about the mm innards to know whether
vm86_32.c's mark_screen_rdonly is a security bug, but poking at PTEs
belonging to user addresses without even trying to see what VMAs back
them doesn't look like a good thing...  And I have no clue how to fix
that without an ABI break, even if that particular ABI break might not
affect dosemu.

--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