linux-kernel - Re: [PATCH] x86/kconfig/32: Mark CONFIG

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMzpN2i6XAMkgLx+NR+Z5X9nq=5ATqc2VazCdzAMRVCKwvFKWQ@mail.gmail.com>
Date:	Wed, 8 Jul 2015 11:32:01 -0400
From:	Brian Gerst <brgerst@...il.com>
To:	Andy Lutomirski <luto@...nel.org>
Cc:	"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>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Borislav Petkov <bp@...en8.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN

On Tue, Jul 7, 2015 at 9:25 PM, Andy Lutomirski <luto@...nel.org> wrote:
> 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 is dead code.  It
> also plays awful games with the entry asm.
>
> No one should be using it anyway.  Use DOSBOX or KVM instead.
>
> Mark it BROKEN.  I want to remove some (obviously incorrect) exit
> asm that it depends on, and I don't want to figure out how to run
> severely obsolete programs just to test something that no one uses
> for anything other than exploits anyway.
>
> Signed-off-by: Andy Lutomirski <luto@...nel.org>
> ---
>
> I find it implausible that vm86_32.c isn't full or root holes.  It's
> also full of hilariously ugly code, it does terrible things to the
> kernel stack, and its interaction with the syscall slowpath is
> blatantly incorrect.
>
> It really shouldn't have any users, anyway.  It doesn't (and can't!)
> work on 64-bit kernels, and the only program that even knows how it
> works appears to be DOSEMU.  DOSEMU doesn't even need it for most
> programs (it uses modify_ldt instead if possible), and DOSBOX and
> KVM are better choices anyway.
>
> I think that even DOSEMU might be able to emulate vm86 (by emulating
> instruction-by-instruction) if the vm86 syscall isn't there.
>
> Want to be terrified?  Read copy_vm86_regs_from_user.  Or
> mark_screen_rdonly.  Or return_to_32bit.  Or VM86_REQUEST_IRQ.
>
> What do you all think?  This code is a maintenance disaster, and I'd
> love to see it go.  This would be a nice first step.
>
> This patch is intended for tip/x86/asm.  The 32-bit part of my big
> cleanup will interfere with vm86, and, while I think I fixed it up
> right, I'd rather not expose everyone to the high probability of
> crazy security bugs in this mess.

I have been working on some patches to fix the ugly hacks vm86 uses
and make it more easily maintainable.  The general idea is to make it
use the regular pt_regs area and save the 32-bit regs and other data
off-stack.  That would allow a normal kernel exit route instead of
jumping directly into the exit asm code.  It should also allow ptrace
to work with a few tweaks.

One other place to check for usage is Wine.  I recall there being some
DOS compatibility stuff in there.

--
Brian Gerst
--
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/